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:
In this article, I want to discuss the following things at a higher level:
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:
If you process it in the Work order driver itself, then:
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.
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: