Recently I came across a new driver that has been added in Novell Identity Manager (IDM) 3.5. The name of the driver is the "WorkOrder" driver. Not to be confused in any way with "Workflow" or the User Application (UserApp) and what those do, the WorkOrder driver is a completely new type of driver that will probably throw those familiar with IDM and its existing drivers for a loop. During my first implementation I relied a bit too much on my past knowledge, and it bit me fairly hard. With that in mind, I want to make this useful driver as easy-to-understand as possible for others out there.
So what is the WorkOrder driver? First, let's go over what it is not for those who are already familiar with IDM. It is not a driver that connects to another application or system by default. Therefore, similar to the Loopback driver, it is not a driver that synchronizes identities from one environment to another. This will become overly-obvious when you notice the filter does not have any User or Group classes in it by default. Without users, Passwords become fairly dull, so this driver doesn't do any Password Synchronization. Similarly, a lack of users means a lack of roles, so Role-Base Entitlements (RBE) are out as well. This isn't a lack of functionality for the driver but, as a special driver, those things are just outside the scope of what the driver needs to do. This driver also primarily does its heavy lifting on the Publisher channel, similar to the eDirectory driver. The driver's object placement is not what you think if you have any experience with IDM, and you will get errors if you try to treat it like a normal driver with regard to object placement.
So now, hopefully the experienced IDM people are making few if any assumptions about the driver, and people newer to IDM are where they would be anyway. With this lack of presumptions, let's continue. The WorkOrder driver is made to handle odd little objects new to IDM 3.5, with a class of DirXML-WorkOrder. These classes have a few predefined attributes that meet the objects' needs and that are needing some good explanation. We'll explain this more later on, but here's some information to start with:
- DirXML-DueDate: The date and time the workorder is to be executed.
- DirXML-nwoProcessLog: A log of things that happen related to this WorkOrder. Having this log means you get automatically (really, no configuration) logging with regard to this WorkOrder's history from the WorkOrder driver.
- DirXML-nwoStatus: The status of the current WorkOrder object. Pending, configured, resolved, canceled, error.
- DirXML-nwoDeleteDueDate: When to delete the WorkOrder. This also works with the next attribute for situations when an error occurs.
- DirXML-nwoDeleteOnError: If an error occurs (status = "error"), specify if the WorkOrder should be deleted when the DueDate comes. A WorkOrder with the "error" status is done as far as automatic operations are concerned, so manual intervention is now required. Without being deleted, these will sit forever.
- DirXML-nwoSendToPublisher: Specify if this WorkOrder should be sent to the Publisher channel immediately. This can be true or false and, if false, the WorkOrder waits until the next polling cycle or heartbeat for it to be processed on the Publisher side. If true, it goes immediately.
- DirXML-nwoDoItNowFlag: Interesting name for an attribute, but it tells the Publisher channel that this WorkOrder must be processed now. As a result the documentation indicates that ALL WorkOrders that are ready to be processed (by DueDate) will be processed immediately.
- DirXML-nwoDependentWorkOrder: DN of a WorkOrder object on which this WorkOrder depends. This WorkOrder won't go until its dependency has a status of Configured.
- DirXML-nwoContent: An attribute used to store custom information specific to this WorkOrder. It is passed through to the WorkToDo object.
There are quite a few other attributes but most of them are fairly self-explanatory (creator's name, creation timestamp, a few other fields for miscellaneous data, etc.).
- DirXML-nwoDN: The DN of the WorkOrder from which this WorkToDo object originated.
- DirXML-nwoContent: Look familiar? This holds the data that was in the same attribute on the WorkOrder object that led to this WorkToDo object.
There are quite a few other attributes for this class as well and most of them are copied directly from the WorkOrder object. We'll see why before this is all through.
Default Driver Filter
So let's move on to the default driver filter to see what happens there. As mentioned, a large change for this Filter is what it works with (no Users, Groups, etc.).
What is interesting here is that WorkOrder objects are used in both channels, while WorkToDo objects are only sent out from the Publisher channel. We'll see where they come from before this is all through.
Driver Functionality: HR System Example
So let's try to get our minds wrapped around the driver's functionality. The WorkOrder driver is made to create and process an object of type WorkOrder, possibly ending up with a WorkToDo object. Let's use an example that fits with this driver. Imagine you have a driver from your Human Relations (HR) system, PeopleSoft. This driver creates users in your Identity Vault (IDV) as employees are hired on. What happens in the two weeks or months between when the user is added into PeopleSoft and they start working? Jack, the evil cracker in Marketing, is trying to break into the new employee's account. It's out there; it might have a default password, and it's ripe for exploitation. To prevent this type of malicious user from having weeks to months with access to things they shouldn't, the account is logically disabled - but now a new administrative chore surfaces. Who enables the account on the first day of employment? Does the new employee wait around while the administrator who would have enabled the system is out sick, or do you give managers rights to enable and disable accounts and hope they remember how to do it, have the tools to do it, and the ethics to be honest?
Enter the WorkOrder driver to save the day. When the user is provisioned from PeopleSoft a WorkOrder is created by that driver and placed where the WorkOrder driver will find it. This object is made to be processed by the WorkOrder driver and has some data relevant to the WorkOrder's task in the object. DirXML-nwoContent has the DN of the user who was just hired. DirXML-DueDate has the date and time when the user should be officially enabled. The driver detects this object and processes it much like a normal driver would process a user creation.
The WorkOrder object is placed in a container where it is held until the DueDate comes along. In this first example, we know this is the first day of work for the new employee. The WorkOrder driver differs slightly from others at this point in that it implements a Polling Interval, Heartbeat, or both to regularly check on the objects in the pending area. The polling interval can be a time period or a time of day (or both). An appropriate value for this example may be 0030 (12:30 a.m.) so that new users are enabled in time for their first day. The DueDate is set for the first day of work, sometime before 0030, and when the polling takes place the WorkOrder object is finally processed by the Publisher Channel.
The WorkOrder shim is sent a WorkOrder object (mapped in Schema Mapping policyset from DirXML-WorkOrder). A difference between this driver and others appears here. There is no application for the shim to send the object to. So, if DirXML-nwoSendToPublisher is set to true, this new WorkOrder object is sent right back into the Publisher channel where it is eventually written back into eDirectory. The object has an association to this driver in the Engine, and subsequent polling intervals will affect it.
The WorkOrder driver shim picks up the new DirXML-WorkOrder object (through queries), verifies it should be worked on at this time, and starts it through the Publisher channel. On its way through, the object is treated as a "WorkOrderToDo" object (not "DirXML-WorkOrder"), which is then mapped to DirXML-WorkToDo. When was the DirXML-WorkOrder object made into a WorkOrderToDo object? Once the shim determined that the DueDate had arrived and passed, it built this new WorkOrderToDo object with the values from the original WorkOrder. From here on out the WorkOrder is simply used to log processes as they take place.
A normal DirXML-WorkToDo object is short-lived. It basically goes into the Publisher channel as an add-event, is optionally evaluated for things to do by the custom policies, and is written to a container in eDirectory made for WorkToDo objects. This object-creation could kick off a Loopback driver designed to do the actual enabling of the user, along with a number of other tasks. But in an example like this, we could just as easily do this in the WorkOrder driver. For instance, there is a Placement policyset created by default that really isn't needed for our example. The desired behavior is to have the new employee?s account enabled. To do that, a simple rule can be placed in a policy to set the destination-attribute of "Login Disabled" for the user specified in DirXML-nwoContent to FALSE (was set to TRUE before, as you might recall), effectively enabling the account. The actual creation of the DirXML-WorkToDo object can be vetoed, as it's not needed for this example - and we are finished.
A quick recap may be in order:
1. Create a disabled User object with PeopleSoft in Identity Vault.
2. Also create a WorkOrder object at the same time setting its DueDate to the employees start date and the nwoContent to the new employee?s DN
3. The driver processes the WorkOrder, placing it in a directory made for WorkOrders. Polling available WorkOrders does a check to see if they are due.
4. When the WorkOrder, is due it is read and sent to the Publisher channel as a WorkToDo object.
5. Custom processing can be done here if desired, to actually enable the user in the nwoContent attribute - or it can be left to another driver.
6. Optionally write the WorkToDo object to eDirectory for other processes to use.
Another Example - Delayed User Deletion
Here we have seen one example of what the WorkOrder driver can do. Another practical example I am going to demonstrate in my next blog post will be a driver that ends a user's lifecycle. Many companies may not have PeopleSoft or SAP or some other large HR system, but most companies terminate employment of users at some point. A few I have come across want to delete the users, but not until a period of time has elapsed. This can be in case the employee comes back, for legal reasons, for auditing, or for many other reasons. No matter what the reason, there is a need for somebody with a fair amount of authority to spend time cleaning up users after a period of time. Again, do we have the senior administrators do this, instead of hunting for bad guys or fixing the payroll system? No, this is something to automate and is a good example of a WorkOrder driver's task.
This new driver will probably not depend on something else for the initial workflow creation. A simple way to work past this is to let the driver itself detect when a user is disabled or moved to a container for terminated employees. After detecting a disabled user, a small amount of IDM policy (written via a GUI because that?s my kind of option today) creates the DirXML-WorkOrder object, which then is sent through the remainder of the Subscriber channel.
The biggest difference between this example and the previous example is what happens on the Publisher side. When the user is disabled and the WorkOrder is created, its due date attribute is set for 90 days into the future. When those 90 days have elapsed, and it's time for the user to be deleted, the polling picks up the WorkOrder and determines this is for a delete. A rule is added, which sees a WorkToDo object coming back through the Publisher channel and has enough brains to know what the WorkToDo object is all about. Knowing it's been 90 days since the employee was terminated, the driver deletes the object from eDirectory and could optionally do other operations to clean the employee from other systems. Because this was the completion of an employee's lifecycle in eDirectory, the administrator determines there's no need to leave the WorkToDo object around, and it vetos the placement to prevent these objects from building up. It could have been allowed through, but with no reason to store it we'd might as well save space.
So far we have seen what the WorkOrder driver can do and hopefully a few ideas for your own environment come to mind. For instance, this is a fairly simple and customizable cron job built into eDirectory. IDM 3.5 also has "Jobs," but those are meant for other things. This driver can save a lot of time with tasks every administrator currently has assigned and always forgets, because they are out of the office or the time delay causes forgetfulness. Policies for keeping the environment clean can be written once and run forever with minimal monitoring. Imagine the audit where your boss or a SOX auditor comes and asks for a forensics trail regarding users' data removed from a given system. Picture yourself confidently referring to one little WorkOrder driver doing all your mundane tasks as needed all, because of a process started by somebody over in HR who didn't know a thing about the driver.
Sounds like a good way to make life easy, and so I must get you ready for the price for all this functionality. All good things come with a price but thankfully this one is not that bad, if you use a simple equation:
- Calculate dozens of uses for this driver. Keep track of the time required to do this.
Multiple the amount of time it took to do that, plus some time to implement it, by your hourly wage.
- Subtract the amount of time you would have wasted doing this work yourself.
- Subtract the amount of stress received from your higher-ups over completion of various mundane tasks.
- Add in a negative number for your personal bonus for meeting all your mundane-task objectives so well.
- Add in a negative number arbitrarily chosen by yourself representing your job security?s worth to you.
If you are anywhere above $0 I'll be surprised. As an IDM customer, you already have full access to this driver. As one of the many IDM service drivers, this one has no additional fees required. Labor is required, of course, but I think the benefits will make it worth your while.
Anyway, that's all for today. Another post with at least the latter example above will be coming before too long.
If you have any interesting comments on this driver or uses you have found, please post them. Any great implementations you want to share can be submitted as Cool Solutions to help others enjoy life more and to earn you points (so you can enjoy life more, up to and including a cruise for two to Hawaii).
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.