With the release of IDM 3.5, there is a new free driver included called the Work Order driver. The documentation tells you something about what it does, and there are a couple of excellent blogs on the topic by Aaron Burgemeister:

http://www.novell.com/coolblogs/?p=880

http://www.novell.com/coolblogs/?p=897

In this article, I want to discuss the following things at a higher level:

• What you can use this driver for

• What the driver shim does for you

• What you need to do for yourself

About the Work Order Driver

The driver itself is really a simple thing. It uses two object classes: DirXML-WorkOrder and DirXML-WorkOrderToDo. (Note: This is NOT DirXML-nwoWorkOrder; that is from the Avaya PBX driver, and it is apparently what this driver's notion is based upon, but that is not the object class to use). I am going to skip the DirXML- prefix when talking about the classes since that gets really tedious.

The driver triggers events on these two classes by default: Work Order and Work Order To Do. When it sees an event on a Work Order in the Subscriber channel, it checks a couple of attributes (discussed by Aaron and the docs) and passes the event on to the shim. The shim, in the most basic usage, copies some of the attributes from the Work Order and adds them to the Work Order To Do that it is about to create through the Publisher channel.

The other major thing it does is "heartbeat". This means that every X minutes (default is one, I think, but you can change it) it queries for any Work Orders with a DueDate (DirXML-nwoDueDate) that has passed since the last check. If it finds any, it passes them to the shim to return out the Publisher channel as a Work Order To Do.

Also, the driver checks the DirXML-nwoDeleteDueDate (which I really wish they would have renamed in schema as something like SelfDestructDate). The imagery makes me smile each time I think about it. But it really is a self-destruct date, as in "this message will self-destruct in 5 seconds." That is, the shim sees a nwoDeleteDueDate pass, and it
deletes the Work Order, thus cleaning up your tree for you.

If you are auditing eDirectory events, this information gets into your audit, so all is tracked.

Basically, that is about all the driver does: it watches for Work Orders to come due, it makes Work Order To Do's out of them, and it cleans up afterwards.

Using the Work Order Driver

So where do Work Orders come from? Well, that is your job. What does a Work Order To Do - what tasks does it perform? Again, that is your job. You have virtually unlimited options here.

You could set up a loopback driver so that when it sees a specific set of events (say a User delete, or a login disable, or a move to a disabled container), it creates a WorkOrder somewhere in the tree, with a DueDate of say 90 days from now. Then either in that same loopback driver or in the Work Order driver itself, you watch for that Work Order to come due.

If you process it in the loopback driver, then:

• You watch for WorkOrderToDo's to get created.

• If they are from that specific location, or the DirXML-nwoContent value is 'delete' or any other flag you decide upon, then you find the user it is referencing (which you had to have added to the payload yourself at some point in the first loopback driver) and delete it.

If you process it in the Work order driver itself, then:

• In the Publisher channel, probably in the Event transformation rule, watch for a WorkOrderToDo being created (add operation).

• Read the info that the shim is sending to create the ToDo.

• Use that information to decide what to do - in this case, delete the old user object. (This is the example Aaron uses in the blogs linked to above.)

What it comes down to is this: the Work Order driver, by itself, doesn't really do anything. For me, personally, it took a while to figure that out. I kept looking for the part that did something, anything! I mean, it has to do something, right? This can be slightly confusing in Aaron's blog posting, since he does the work in the Work Order driver itself. It's not clear that this is a choice, and what the other option is.

Once you come to grips with the notion that you have to generate the Work Order somewhere else, and probably operate on the WorkOrderToDos somewhere else as well, it makes a lot more sense. The driver just wraps some payload in a timed event, and checks periodically for timed events.

Conclusion

The driver is very useful when used properly, but it is not thoroughly explained so far in the documentation. Now of course the devil is in the details of how you use it, and you are limited only by your own imagination and ingenuity.

Here are some additional uses and strategies for the driver:

• Map a WorkOrder to a Helpdesk application's work order that expects tasks to be completed.

• Use a driver to synchronize out of the application, or use the JDBC driver to get data straight from the application's database.

• Have the Work Order driver do all the work, and never generate a WorkOrderToDo; or,

• Have a more general Work Order driver that you use for a bunch of things, and handle the actual tasks in a driver somewhere else.