In Identity Manager you can use the command line utility dxcmd to send your own custom XML documents to a driver that conform to the Identity Manager XDS DTD to the subscriber channel on a specific IDM driver.

This is documented in the IDM documentation, in the “Common Driver Administration Guide”, under the part “Using the DirXML Command Line Utility”.

As you can read in the documentation dxcmd has three options for sending the XML to the driver:

Submit XDS command document to driver
This option requires that the driver is running.
It will bypass the driver cache and start at the command transformation.
It can return a result response from the driver.

Submit XDS event document to driver
This option requires that the driver is running.
It will bypass the driver cache and start at the event transformation.
It can return a result response from the driver.

Queue event for driver
This option doesn't require that the driver is running but it must be enabled.
When using this option you will put the XDS in the driver queue after everything else that might be in the queue.
You can't get back a result response.

In dxcmd you point out a file that contains the correct XDS.

I have implemented basically the same functionality in a graphical Java application using the DirXML LDAP API with some minor adjustments.

This is a description on how you can use it.

First, download the latest Console2 version from the Cool Solution site, unpack it and launch the ldapmu_upc.jar file.



Connect to the IDM server on which the driver is running by filling in the username in LDAP format, the password, and the IP address or hostname, and the port.

Then click Connect.

After that click on the “Show IDM Drivers” button and select the driver that you will be sending the XDS to.

Then click on the IDM menu on the top of the window and select Send XDS to IDM engine.



This will give you a new window where you perform the actual work.



In the window there are several radio buttons, two buttons, a checkbox and a textarea.

The following will describe what each options means.

The three radio buttons describe clearly what they do and they are the same as the three options in dxcmd.

They decide if you want to send the XDS to command transformation, to event transformation or to the driver cache.

The check box is of use if you select submitting to the event transformation/command transformation, because they can produce result responses and they will be written to the Console 2 log file using Logback/SLF4J logging. You can't select the location of the logfile. The logfile is automatically created when C2 is started and is normally in the same directory as the main jar-file.

Then you have the option of writing your own XDS in the text area and submitting it directly by clicking on the “Send from textarea below to IDM”. It does exactly what it says. It will send the entire content at once even if the contains multiple operations (<add>, <modify>, <sync> etc.).

The button next to it is called “Send from XML file to IDM”. Clicking it will open a file browser where you can select an XML file containing valid XDS which will be sent to the IDM driver.

The entire file is not sent at once to IDM, instead each operation element in the file will be sent separately.

This means that if the fails contains something like this:

<nds>
<input>
<modify class-name=”User” src-dn=”xxx\yyy”>
<modify-attr attr-name=”Surname”>
<remove-value>
<value>BBB</value>
</remove-value>
</modify-attr>
</modify>
<modify class-name=”User” src-dn=”xxx\zzz”>
<modify-attr attr-name=”Surname”>
<add-value>
<value>AAA</value>
</add-value>
</modify-attr>
</modify>
<sync class-name=”User” src-dn=”ccc\www”>
<association>www</association>
</sync>
</input>
</nds>

 

First the first modify will be sent.

Then the second modify will be sent.

And lastly the sync event will be sent.

Any errors during the sending operation will be written to the C2 logfile.

You should have the latest version of IDM even it might work with IDM 3.6.x. I haven't tested it with any older version of IDM such as 3.5.x.

Known issues:
Depending on the eDirectory/IDM version, you might experience some problems.
I have noticed that the DirXML LDAP API:s don't work reliably on IDM 3.6.1 with eDirectory 8.8.6 on Linux if the ndsd process uses more than 2 GB memory, which it can if you are running 64-bit versions of the products and you have set a large cache size.