Sending a XDS Message from one driver to another

4 Likes
over 11 years ago

Send Queue Event



This java class allows you to send a arbitary XDS message to another driver without needing to generate an event against eDirectory.

This is much the same as the sendDriverCommand with some subtle yet important difference.

When using sendDriverCommand the source driver waits until the destination driver processes the full event from the Subscriber and get the response back to the source driver as the resultant XDS.

The destination driver also needs to be running, if it 's stopped or disabled then the sendDriverCommand will fail.

When using the sendQueueEvent the event is queued up on the destination driver. The advantages of this is the source driver does not wait until the destination driver has completed. Plus if the driver is in a stopped state the event will still be queued up and processed when the driver next starts.

To use this you need to put the dxqueue.jar includined in the zip file into your dirxml\classes directory.

Then you can call the java class by including the "dxqueue.send" java method in your namespace. And then make the call: sendQueueEvent($DriverDN, $XDS/nds)

If you load the "SendQueueEvent.xml" Null Driver included in the zip into Designer you will see the single policy "Send Queue Event" On the subscriber. In there you will see I
am loading the namespace:


<policy xmlns:dxqueue="http://www.novell.com/nxsl/java/dxqueue.send">



Then setting a Nodeset Varaible to call that Java Class using the xpath call.


<do-set-local-variable name="CmdResult" scope="policy">
<arg-node-set>
<token-xpath expression="dxqueue:sendQueueEvent($DriverDN, $XDS/nds)"/>
</arg-node-set>
</do-set-local-variable>



This example creates a XDS message to then have it logged into a JDBC Database using a direct JDBC Insert statement. This is quite a handy way to log audit data into a database that you don't necessarily want to store in the Directory (such as Event Souce IP Address) but you do want to audit.

Labels:

How To-Best Practice
Collateral
Comment List
Anonymous
  •   Your LDAP version in ECMAScript gives error:

    https://github.com/lhaeger/dxqueue/blob/master/src/dxqueue-es/sendQueueEvent.js

    com.novell.xml.xpath.XPathEvaluationException: Can't find method com.novell.nds.dirxml.engine.NdsDtd.createStatusDocument(java.lang.Integer,com.novell.soa.script.mozilla.javascript.Undefined,com.novell.soa.script.mozilla.javascript.ConsString).

  •  Your use case would be best off handled by implementing the LDAP equivalent of dxqueue. That would avoid the issue of needing eDirectory on same server and keep with principle that IDM Apps does all it's magic via LDAP.

    This is accessible as an LDAP extended operation.

    https://www.novell.com/documentation/developer/dirxml/dirxmlbk/api/com/novell/nds/dirxml/ldap/QueueEventRequest.html

    Geoffrey's LDAPModify code can most likely be extended to support this. I have not personally done that though, so don't have any code to share.

  • Is there a version of dxqueue that can be used from within a workflow on userapp? Essentially looking to have a workflow send a dxqueue event to one or more drivers instead of toggling attributes in an entity activity.

    Currently, we have to create schema, add that attribute to filter(s), then add policy to transform the toggle of the attribute into the event we want to fire. I'd prefer to simply throw an NDS document into the driver shim directly from the workflow.

    I researched it a while back, but it appears as though we are missing some java libraries to make this happen. If I recall, my primary issue was that dxqueue is calling edirectory locally, in the case of userapp, edirectory will most likely be remote.

    Thoughts?

  • Great work, Lothar!

    Another thing that makes sense to check... 

  • An updated version, which fixes the above mentioned bug and adds tracing as well as a Designer project for easy evaluation can be found at https://github.com/lhaeger/dxqueue

  • Indeed an excellent helper class!

    One thing to point out: I ran into a rights issue recently. It seems that the Security Equivalence of the 'Driver User' needs supervisor rights to the Driver object. I'm not sure why, because I would expect write rights to the attribute DirXML-AccessSubmitCommand should be sufficient (am I missing something?). Without these rights a Throwable is not handled by the code (bug):

    com.novell.xml.xpath.XPathEvaluationException: function call to 'dxqueue:sendQueueEvent' resulted in an error: 'java.lang.NoSuchMethodError: com.novell.nds.dirxml.engine.NdsDtd.createStatusDocument(Ljava/lang/Throwable;Lcom/novell/nds/dirxml/engine/OperationData;)Lorg/w3c/dom/Document;
  • Great little tool, I had a use-case for this and found it fit the requirement perfectly. Far better than my prior approach.
Related Discussions
Recommended