One of the great features of NetIQ IDM is the possibility to run transactions at a later time – for example delete a user object after 10 years after deactivation.

Things like this can be accomplished by the help of the Workorder-Driver. The only thing which has to be customized is the creation of so called workorder-Objects. Beside other things those objects have a DueDate. The driver periodically searches for all workorders having a current or passed duedate and for every workorder found it creates a DirXML-WorkToDo Object on its publisher channel.

The future transaction(s) are defined by command transformation policies on the publisher channel waiting for the creation of those worktodo objects.

So far so good. At the end we can find those work to do objects in a certain container within the identity vault.

But what if we do not want those objects to be created? The short answer would be to issue a veto or do-strip-xpath action at the end of all other command transformation policies to get rid oft he XDS add command – but this is an bad idea since the outputXDS coming back because of this transaction would be recognized as an error. This would result in the workorder status to be set to „error“ instead of „configured“ even if the future transactions were applied without any errors.

A better solution would be to let the driver create those worktodo objects and set an action to be applied after the current transaction to delete the just created object. This is working as designed an the status oft he corresponding workorder object will eventually be set to „configured“

What I do not like with this approach is the fact that in certain scenarios we will create and delete thousands of objects within a very short timeframe.

So I was searching for a better way to solve the challenge – and I found one.

Instead simply removing the add transaction I set up an simple modify transaction before I did the strip-xpath. In this case we can receive an correct status XDS object after „pumping the data to nds“

This can be easily done by the following dirxml-script:

<policy>
    <rule>
        <description>Delete WTD after creation</description>
        <conditions>
           <and>
              <if-operation op="equal">add</if-operation>
              <if-class-name op="equal">DirXML-WorkToDo</if-class-name>
              <if-global-variable mode="nocase" name="gc.CreateWTD" op="equal">false</if-global-variable>
           </and>
        </conditions>
        <actions>
          <do-set-dest-attr-value name="Description">
                     <arg-dn>
                              <token-global-variable name="gcDs.WorkToDoOU"/>
                        </arg-dn>
<arg-value type="string">
<token-text xml:space="preserve">Last WO at: </token-text>
<token-time format="dd.MM.yyyy HH:mm"/>
</arg-value>
</do-set-dest-attr-value>
<do-strip-xpath expression="."/>
</actions>
</rule>
</policy>

With this code I update/modify the description of the container object to store the worktodo objects any time a worktodo object is added on the publisher channel. As long as this container exists - and the driver has the right to modify the description attribute - the status of the triggering workorder object will be "configured" at the end.