friedman16 Trusted Contributor.
Trusted Contributor.
803 views

SOAP driver and

Question: is it possible to connect to the IDM SOAP driver (which is in listen mode) and send to it multiple documents at once? Or, said another way, send multiple objects in one document?


For example, could I send the following document and have the soap driver process each of the three sections individually:


<input>
<modify class-name="User">
<add-attr attr-name="CN">
<value>IDM800435</value>
</add-attr>
<add-attr attr-name="Home_Phone_Number_Primary_CC">
<value>1</value>
</add-attr>
<add-attr attr-name="Home_Phone_Number_Primary_CN">
<value>USA</value>
</add-attr>
</modify>
<modify class-name="User">
<add-attr attr-name="CN">
<value>IDM800434</value>
</add-attr>
<add-attr attr-name="Home_Phone_Number_Primary_CC">
<value>1</value>
</add-attr>
<add-attr attr-name="Home_Phone_Number_Primary_CN">
<value>USA</value>
</add-attr>
</modify>
<add class-name="cProgram">
<add-attr attr-name="Program">
<value>WAYNE</value>
</add-attr>
<add-attr attr-name="ProgramDescription">
<value>College of Bats</value>
</add-attr>
</add>
</input>


As you can see, the first two "sections" are User objects while the third is an object that we created. From that I can tell, if we had to veto the second section, the entire document is lost, even if the first and third sections could be processed without any errors.
Labels (1)
Tags (2)
0 Likes
7 Replies
Knowledge Partner
Knowledge Partner

Re: SOAP driver and

On 12/18/2018 1:44 PM, friedman16 wrote:
>
> Question: is it possible to connect to the IDM SOAP driver (which is in
> listen mode) and send to it multiple documents at once? Or, said
> another way, send multiple objects in one document?
>
>
> For example, could I send the following document and have the soap
> driver process each of the three sections individually:
>
>
>
> Code:
> --------------------
> <input>
> <modify class-name="User">
> <add-attr attr-name="CN">
> <value>IDM800435</value>
> </add-attr>
> <add-attr attr-name="Home_Phone_Number_Primary_CC">
> <value>1</value>
> </add-attr>
> <add-attr attr-name="Home_Phone_Number_Primary_CN">
> <value>USA</value>
> </add-attr>
> </modify>
> <modify class-name="User">
> <add-attr attr-name="CN">
> <value>IDM800434</value>
> </add-attr>
> <add-attr attr-name="Home_Phone_Number_Primary_CC">
> <value>1</value>
> </add-attr>
> <add-attr attr-name="Home_Phone_Number_Primary_CN">
> <value>USA</value>
> </add-attr>
> </modify>
> <add class-name="cProgram">
> <add-attr attr-name="Program">
> <value>WAYNE</value>
> </add-attr>
> <add-attr attr-name="ProgramDescription">
> <value>College of Bats</value>
> </add-attr>
> </add>
> </input>
> --------------------
>
>
> As you can see, the first two "sections" are User objects while the
> third is an object that we created. From that I can tell, if we had to
> veto the second section, the entire document is lost, even if the first
> and third sections could be processed without any errors.


This is a problem in the SOAP shim, since you sort of convert one doc to
one doc. If there is a sequencing issue, do them in proper order, but
you can detect the first one, add destination attribute whatever, but do
it Direct instead of add to current event.

This will cause it to process as soon as the policy is done processing.

Then in that same policy detect the second, write direct.

Finally let the third one go, and process normally.

They will go through the OTP and convert as should be done.


0 Likes
friedman16 Trusted Contributor.
Trusted Contributor.

Re: SOAP driver and

Geoffc,

thanks for your reply. So what you are suggesting is to do the following

Set the destination DN
then loop through the updates on a per user basis setting
add destination attribute X

with my code above, it would turn out to be (for the first user object)

Set destination DN to IDM800435
add destination attribute "Home_Phone_Number_Primary_CC" = 1
add destination attribute "Home_Phone_Number_Primary_CN" = USA

then process the second User object much the same way, then do nothing for the 3rd object and let it go through the driver normally.

Would I want to remove the user objects from the document once I process these?
0 Likes
Knowledge Partner
Knowledge Partner

Re: SOAP driver and

On 12/21/2018 11:04 AM, friedman16 wrote:
>
> Geoffc,
>
> thanks for your reply. So what you are suggesting is to do the
> following
>
> Set the destination DN
> then loop through the updates on a per user basis setting
> add destination attribute X
>
> with my code above, it would turn out to be (for the first user object)
>
> Set destination DN to IDM800435
> add destination attribute "Home_Phone_Number_Primary_CC" = 1
> add destination attribute "Home_Phone_Number_Primary_CN" = USA


The key being, when=direct, so each generates its own event. If you use
the same info two in a row, it might consolidate the two modifies into
one doc. And you need 2 or 3 in total. That is the tricky bit.


> then process the second User object much the same way, then do nothing
> for the 3rd object and let it go through the driver normally.
>
> Would I want to remove the user objects from the document once I process
> these?
>
>


0 Likes
Knowledge Partner
Knowledge Partner

Re: SOAP driver and

Geoffrey Carman wrote:

> The key being, when=direct, so each generates its own event. If you use the
> same info two in a row, it might consolidate the two modifies into one doc.
> And you need 2 or 3 in total. That is the tricky bit.


That happens with current ops as well as direct writes when class, dest-dn
and/or association are equal:

test : Applying to trigger #1.
test : Evaluating selection criteria for rule 'test multiple direct writes'.
test : Rule selected.
test : Applying rule 'test multiple direct writes'.
test : Action: do-set-dest-attr-value("Given
Name",class-name="User",direct="true",arg-dn("data\users\bob"),"Bob").
test : arg-dn("data\users\bob")
test : token-text("data\users\bob")
test : Arg Value: "data\users\bob".
test : arg-string("Bob")
test : token-text("Bob")
test : Arg Value: "Bob".
test : Action:
do-set-dest-attr-value("Surname",class-name="User",direct="true",arg-dn("data\us
ers\bob"),"Builder").
test : arg-dn("data\users\bob")
test : token-text("data\users\bob")
test : Arg Value: "data\users\bob".
test : arg-string("Builder")
test : token-text("Builder")
test : Arg Value: "Builder".
test : Action: do-trace-message(token-xml-serialize(token-xpath("../*"))).
test : arg-string(token-xml-serialize(token-xpath("../*")))
test : token-xml-serialize(token-xpath("../*"))
test : token-xml-serialize(token-xpath("../*"))
test : token-xpath("../*")
test : Token Value: {<trigger>,<modify> @class-name = "User"
@dest-dn = "data\users\bob" @direct = "dest"}.
test : Arg Value: {<trigger>,<modify> @class-name = "User"
@dest-dn = "data\users\bob" @direct = "dest"}.
test : Token Value: "<trigger/>
<modify class-name="User" dest-dn="data\users\bob" direct="dest">
<modify-attr attr-name="Given Name">
<remove-all-values/>
<add-value>
<value type="string">Bob</value>
</add-value>
</modify-attr>
<modify-attr attr-name="Surname">
<remove-all-values/>
<add-value>
<value type="string">Builder</value>
</add-value>
</modify-attr>
</modify>".

You can avoid that by executing each direct write immediately as described in
Alex' really cool solution described at https://is.gd/9Z8nn4 (search for
"Generic validated direct-write").

Or you trick the engine by using different class names for each write (User1,
User2, User3...) and fix them once all ops have been created with something
like:

<do-set-xml-attr expression='../*[starts-with(@class-name,"User")]'
name="class-name">
<arg-string>
<token-text xml:space="preserve">User</token-text>
</arg-string>
</do-set-xml-attr>

so you get:

test : Applying to trigger #1.
test : Evaluating selection criteria for rule 'test multiple direct writes'.
test : Rule selected.
test : Applying rule 'test multiple direct writes'.
test : Action: do-set-dest-attr-value("Given
Name",class-name="User1",direct="true",arg-dn("data\users\bob"),"Bob").
test : arg-dn("data\users\bob")
test : token-text("data\users\bob")
test : Arg Value: "data\users\bob".
test : arg-string("Bob")
test : token-text("Bob")
test : Arg Value: "Bob".
test : Action:
do-set-dest-attr-value("Surname",class-name="User2",direct="true",arg-dn("data\u
sers\bob"),"Builder").
test : arg-dn("data\users\bob")
test : token-text("data\users\bob")
test : Arg Value: "data\users\bob".
test : arg-string("Builder")
test : token-text("Builder")
test : Arg Value: "Builder".
test : Action:
do-set-xml-attr("class-name","../*[starts-with(@class-name,"User")]","User").
test : arg-string("User")
test : token-text("User")
test : Arg Value: "User".
test : Action: do-trace-message(token-xml-serialize(token-xpath("../*"))).
test : arg-string(token-xml-serialize(token-xpath("../*")))
test : token-xml-serialize(token-xpath("../*"))
test : token-xml-serialize(token-xpath("../*"))
test : token-xpath("../*")
test : Token Value: {<trigger>,<modify> @class-name = "User"
@dest-dn = "data\users\bob" @direct = "dest",<modify> @class-name = "User"
@dest-dn = "data\users\bob" @direct = "dest"}.
test : Arg Value: {<trigger>,<modify> @class-name = "User"
@dest-dn = "data\users\bob" @direct = "dest",<modify> @class-name = "User"
@dest-dn = "data\users\bob" @direct = "dest"}.
test : Token Value: "<trigger/>
<modify class-name="User" dest-dn="data\users\bob" direct="dest">
<modify-attr attr-name="Given Name">
<remove-all-values/>
<add-value>
<value type="string">Bob</value>
</add-value>
</modify-attr>
</modify>
<modify class-name="User" dest-dn="data\users\bob" direct="dest">
<modify-attr attr-name="Surname">
<remove-all-values/>
<add-value>
<value type="string">Builder</value>
</add-value>
</modify-attr>
</modify>".

Another option would be to attach the second operation as op-data and execute
it in an input transform triggered by the status doc from the first (not
practical if you need 3 or more sequenced operations).

______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner
Knowledge Partner

Re: SOAP driver and

> Or you trick the engine by using different class names for each write (User1,
> User2, User3...) and fix them once all ops have been created with something
> like:
>
> <do-set-xml-attr expression='../*[starts-with(@class-name,"User")]'
> name="class-name">
> <arg-string>
> <token-text xml:space="preserve">User</token-text>
> </arg-string>
> </do-set-xml-attr>


That is a clever idea, using different object classes to cause different
events. However, depending on the SOAP API that might still give you one
<nds> document with multiple <modify> events in it. Trying to get
multiple seperate events I think.

0 Likes
Knowledge Partner
Knowledge Partner

Re: SOAP driver and

Geoffrey Carman wrote:

> that might still give you one <nds> document with multiple <modify> events in
> it. Trying to get multiple seperate events I think.


If I needed completely separate events even from the IDM engine's point of
view, I'd probably go with Alex' "validated direct write" approach.

But you could also clone the incoming event and reinsert copy(ies) via dxcmd
into the subscriber cache. Probably add some marker or couner, too, so you know
which iteration you work on when processing them.

Or flag the command with some op-data and change the returning status of step
#1 to level "retry" and set a driver-scoped variable as a step counter. Then,
when the engine processes the event another time do that over again. Big
drawback is the 30s delay until the retry gets processed, though you could
lower that with an ECV, IIRC.
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner
Knowledge Partner

Re: SOAP driver and

Lothar Haeger wrote:

> from the IDM engine's point of view


s/IDM engine/shim/
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.