Sending a XDS Message from one driver to another


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="">

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

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

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.


How To-Best Practice
Comment List
Parents Comment Children
No Data