5.3 Additional Solutions

The WorkOrder driver can be used in conjunction with other drivers to create and schedule work orders. The following samples illustrate two possible solutions for customizing your driver.

5.3.1 Human Resource Sample Using an HR Driver

The following samples illustrate how the WorkOrder driver can be used with an HR driver to create a new user and postpone activating the new employee’s access to the system until the hire date. Figure 5-1 illustrates how these drivers work together in the sample configuration.

In this scenario, the new employee is hired, but does not begin wok until a future date and time. The new employee is put into the HR system with his hire date set. The employee is marked as not active and does not have access to the system.

The HR Identity Manager driver writes the new user object to the Identity Vault. A policy in that driver checks to see if he is active. If he is active, the driver performs the work. If he is not active, the policy creates a work order to activate the new employee on the hire date. The work order is marked pending. A policy in the WorkOrder driver processes the work order on the hire date. The policy in the WorkOrder driver sets the user object’s loginDisabled attribute to False, allowing the user to log in.

The sample could be extended to allow other Identity Manager drivers to have a Create rule to disallow the creation of the user object in other connected systems until the user object’s loginDisabled attribute is set to False. The result is that the user’s system access is provisioned on his hire date and not before.

Figure 5-1 Data Flow with an HR Driver

Other Identity Manager drivers that are interested in this user have a Create rule that does not allow the user to be created in the application until the loginDisabled attribute is set to False.

Human Resource Driver Policies

The following policies show how to implement this sample. In the sample, the Delimited Text Driver is acting as the HR system interface. The Delimited Text Driver is configured to provide the needed attributes: LastName, FirstName, HireDate, Disabled.

Mapping Rule

The mapping Rule maps the attributes used in the Delimited Text Driver to attributes in the Identity Vault. You can view the sample at hr-drv-schema-map.xml.

Filter

The filter attribute allows only the attributes that are needed by this example to be passed through. The DirXML-DueDate is notify only. This attribute should not be applied to the user object. However, it should be available for the Command Transformation. You can view the sample at hr-drv-schema-map.xml

Command Transformation Policy

The Command Transformation policy checks to see if a user object is being added to the Identity Vault. It also ensures that the loginDisabled attribute is set to True. If the conditions are satisfied, the policy then creates a work order and places it in the WorkOrder container. The WorkOrder driver looks in this container for work orders to process.

The policy puts the DN of the user that was created in the DirXML-nwoContent attribute. It also puts the DirXML-DueDate from the user into the WorkOrder object DirXML-DueDate and then sets the work order status to “pending”. You can view the sample at hr-drv-cmd-transform.xml.

WorkOrder Driver Policy

The WorkOrder driver Policy only uses the Publisher Command Transformation policy, described below:

Publisher Command Transformation Policy

The Work Order Command Transformation policy checks to see that a DirXML-WorkToDo object is being added. If it is, the policy gets the DN of the user from the DirXML-nwoContent attribute. It then sets the users Login Disable attribute to False. This allows the user to log in.

NOTE:<do-add-dest-attr-value class-name="User" direct="true" name="Login Disabled"> should not be used.

When direct is equal to True, the action is performed as desired, but the results are not returned to the driver. Therefore, the driver cannot report the results of the write correctly. You can view the sample at hr-wo-drv-pub-cmd-transform.xml.

5.3.2 Human Resource Sample without an HR Driver

This sample creates a new user and postpones activating the new employee’s access to the system until the hire date by putting policies in the WorkOrder driver to create the work order. Figure 5-2 illustrates this sample configuration.

When a new user object is created in the Identity Vault, a policy in the WorkOrder driver checks to see if the loginDisabled attribute is set to True. If it is not set to True, the Create rule blocks the event. If it is set to True, the policy creates a work order to set the loginDisabled attribute on the user to False on the loginActivationTime.

Figure 5-2 Data flow without an HR Driver

The following policies show how to implement the sample configuration:

Filter Additions

Modify the filter to allow user objects with loginActivationTime and loginDisabled attributes to synchronize on the Subscriber channel. You can view the sample at wo-filter.xml.

Subscriber Create Rule

The Create rule vetoes this event if the loginActivationTime or the loginDisabled attributes are not present. It also vetoes this event if the loginDisabled attribute is set to False. You can view the sample at wo-create.xml.

Subscriber Command Transform

This policy checks to see if the event is an Add of a user object. If that is true, the policy creates a WorkOrder object. The DN of the user object is added to the DirXML-nwoContent attribute. The DirXML-DueDate is set to the loginActivationTime. The DirXML-nwoStatus is set to pending. The DirXML-nwoSendToPublisher attribute is set to True.

This work order has not yet been created in the Identity Vault, This sample configuration creates the work order in the Identity Vault by setting the SendToPublisher attribute to True. This tells the publisher in the WorkOrder driver to write the policy to the work order container that it looks in for work orders to be processed. You can view the sample at wo-sub-cmd-transform.xml.

Work Order E-Mail Notification of Work Order Completion

This policy can be used with the WorkOrder driver to send e-mail notification of a completed work order. This policy is in the Publisher Command Transform. The policy checks to see if a DirXML-WorkOrder modify event is happening. If it is, it builds an e-mail from the status, description, and process log of the work order and then sends it to an administrator. This notifies the administrator that a work order has been processed and gives them the results. You can view the sample at wo-pub-cmd-transform.xml.