Vice Admiral
Vice Admiral
329 views

What is difference between operation-data and driver-operation-data in IDM?

Hello

 

I have used "driver-operation-data" heavily in REST drivers but I have used operation-data in non REST drivers. I just wanted to know what is actually differences between these twos? any guide lines to use of these and in which scenarios they should be used ?

if there is no differences, why we have than  these two available?

 

operation-data:

https://www.netiq.com/documentation/identity-manager-developer/dtd-documentation/ndsdtd/operation-data.html

 

driver-operation-data:

https://www.netiq.com/documentation/identity-manager-developer/dtd-documentation/ndsdtd/driver-operation-data.html

 

Regards

Maqsood.

 

3 Replies
Micro Focus Expert
Micro Focus Expert

@maqsood , the difference comes down to what is passed to the driver shim and what is only carried with the event in the engine during event processing. As the references you point to state:

<operation-data> is used to allow policies to inject an additional custom data payload to be carried along with any event or command. It is stripped off of the event or command before it is submitted to the application shim and then reassociated with any corresponding response elements (as determined by matching event-id) after they are returned to the DirXML (ie. an application shim shouldn't ever have to deal with it.) The content of the <operation-data> can be any well formed XML but it is recommended that any elements and attributes used be placed in a custom namespace to avoid having them confused with standard DirXML operations.

<driver-operation-data> is used to allow policies to inject an additional custom data payload to be carried along with any event or command.  The content of the <driver-operation-data> can be any well formed XML but it is recommended that any elements and attributes used be placed in a custom namespace to avoid having them confused with standard DirXML operations. The typical use for <driver-operation-data> is to be able to create a policy that supplies additional data on an operation that may be needed by the drivershim

So of there is something that the driver shim needs, then you would use the <driver-operation-data> and where the driver shim should not see the extra information you are keeping for other uses, then you would use the <operation-data>

Cheers,

D

Knowledge Partner Knowledge Partner
Knowledge Partner

<operation-data> is stripped by the engine before the XDS is handed over to the shim, and restored to the return document (usually status or instance) before it is being processed by input transform policies. operation-data allows you to attach all kinds of data that you need to e.g. process a returned status document.

<driver-operation-data> on the other hand remains in the XDS so that the shim can make use of it, hence the "driver-" part of it's name - although "<shim-operation-data>" would've been a far better choice, as "driver" can mean a driver shim, a driver instance, a certain type driver config or the whole chain between Edir and App even including a remote loader, when used. I'm not sure if <driver-operation-data> will be returned with status/instance docs or not.

The first sentences in your linked doc pages explain it as well:

<operation-data> is used to allow policies to inject an additional custom data payload to be carried along with any event or command. It is stripped off of the event or command before it is submitted to the application shim and then reassociated with any corresponding response elements (as determined by matching event-id) after they are returned to the DirXML (ie. an application shim shouldn't ever have to deal with it.)

<driver-operation-data> is used to allow policies to inject an additional custom data payload to be carried along with any event or command. ... The typical use for <driver-operation-data> is to be able to create a policy that supplies additional data on an operation that may be needed by the drivershim

______________________________________________
https://www.is4it.de/identity-access-management
Vice Admiral
Vice Admiral

@dstagg @lhaeger Thank you for your good explanation!

-Maqsood

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.