Cool Solutions

1 – WorkOrder Introduction



By:

May 22, 2007 3:22 pm

Reads: 4474

Comments:5

Score:0

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, it’s 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-WorkOrder

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. 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-WorkToDo

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.

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.).

filter0.png
Filter Screenshot1
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.

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, might have a default password, and is 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:

Create disabled User object with PeopleSoft in Identity Vault

Also create WorkOrder object at the same time setting its DueDate to the employees start date and the nwoContent to the new employee’s DN

Driver processes WorkOrder placing it in a directory made for WorkOrders. Polling available WorkOrders does a check to see if they are due.

When WorkOrder is due it is read and sent to the Publisher channel as a WorkToDo object.

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.

Optionally write WorkToDo object to eDirectory for other processes to use.

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 and 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 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 veto’s 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. 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 CoolSolutions 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).

Good luck.

VN:D [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Categories: Uncategorized

Disclaimer: This content is not supported by Novell. 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 it thoroughly before using it in a production environment.

5 Comments

  1. By:Axel Larsson

    This is a great introduction to the usage of the WorkOrder driver!

    Has Novell done any testing to determine how scalable the WorkOrder driver is? What is the expected practical limit on the number of WorkOrder objects you can have pending for a future dated action-10s, 100s, 1000s? Does it cache information about upcoming WorkOrders that need to be triggered, or does it scan through all of the WorkOrder objects on each polling interval?

    The reason I ask is because we implemented our own homegrown solution a few years ago to deal with the issue of future dated transactions which I’ve been contemplating trying to reimplement using policy and the WorkOrder driver. Essentially we needed the ability to extend the concept of Role Based Entitlements to include the idea of time. So, with RBE you can say “if a user object matches Y conditions, grant X entitlement”. We needed to be able to say “if a user object matches Y conditions, grant X entitlement from time T1 to time T2″, where the values of T1 and T2 themselves were computed based upon attribute values. A good example of this would be handling something like student registrations–we have a mutlivalued attribute containing courses that students are registered for, which are keyed by term–so say if we have a student that is registered for courses for term 2007/Fall, then we want to grant certain entitlements for the time period covered by the 2007/Fall term.

    The system we developed to do this now is built on top of an SQL database. The process of resolving what work-to-do we need to send back to the Identity Vault is a single SQL SELECT query against a table with indexed columns, so it can be fairly efficient at doing this. Is it feasble to think about trying to do this with WorkOrder instead, with potentially 1000s of future-dated WorkOrders sitting in a container?

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  2. By:Aaron Burgemeister

    Yes, Novell has done some testing on the scalability of this driver with thousands of WorkOrder objects. I have done some tests as well with a few hiccups (user-introduced, fortunately) which I will cover in a later post in this series. I hope to have the demonstrations ready this week with some results. I am currently about to start a 10K-WO test to see if I can get a time estimate out of it on my little Optiplex GX1 box (500 MHz, 512 MB RAM, IDM 3.5… should be a blast).

    It sounds like your environment would be ideal for a WorkOrder driver. As users are registered a WorkOrder could be created to remove them at the end of the term. eDirectory does all of the querying and it’s all based on a DueDate so once that DueDate arrives (end of term) the WorkOrders could be processed as you specified they should be. In your case it may be that the RBE grants them access when you add them to a course (adding an attribute to them) and the WorkOrder driver could simply remove that value from their “course” attribute at the end of the term, automatically revoking the RBE.

    Good luck.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  3. By:Andrew

    Hi Aaron,

    Are you aware if it is possible to remove a WorkOrder once it has been created before it has been actioned ?

    I ask this as this as this driver sounds perfect for where I work, as we want to disable an account when someone leaves and then delete it say 30 days later.

    However if that person comes back before the 30 days and we need to re-enable the account is it possible to remove or cancel the WorkOrder to delete their account ?

    Other than this query the Driver sounds great and we would definitely use it once we get from DirXML 1.1a to IDM 3.x

    Cheers, Andrew.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  4. By:Aaron Burgemeister

    Andrew,

    Yes, removing a pending WorkOrder is as simple as finding the appropriate object and deleting it. This could probably be handled with anything that can interface with the directory. For instance, you have a driver that sets the account to delete in 30 days. Have another rule in your HR driver stating that if an existing account is re-enabled to go and verify there aren’t any objects in the WorkOrder container that would do the delete (you defined the rules for the delete (which WorkOrder driver’s container and such) so that should be simple enough to determine). Worst-case scenario is that you delete the object manually. No harm, no foul.

    Good luck.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  5. By:Rob

    Thanks aaron

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)

Comment

RSS