Monday Oct 24, 2011

Reassigning Leaver tasks in OIM11g

The use case

OIM11g allows arbitrarily complex approval rules to be defined via it's integration with SOA BPEL workflow.  It also allows the management of user lifecycle, for example the classic joiner-mover-leaver cycle.

So what happens to a user's outstanding approvals if the user leaves the company or for example enters a disabled state for some reason ?  Failure to address this point leaves end-user requests stalled, waiting on an approver who may never respond.

The solution

Using a combination of OIM11g's event handlers to detect an event and the SOA Workflow Services API one can easily address this by reassigning leaver tasks to some agreed user.

This JDeveloper project implements an OIM11g scheduled task that scans for user's in a Locked state and reassigns their outstanding approval tasks to their manager.  The MDS data for the scheduled task is included in the config directory.  The scheduled task can be loaded to OIM as described here.  One can use the same technique in an event handler to do the reassignment at the moment where the user enters a Locked or Disabled state.  Note that once the user is Disabled one cannot reassign the approval tasks...so we have to make the reassignment action before the user is disabled.

The task scans all users matching the regular expression parameter to the scheduled task.  For each such user it uses the Workflow Services API to recover any tasks assigned to that user that are in the IWorkflowConstants.TASK_STATE_ASSIGNED or IWorkflowConstants.TASK_STATE_INFO_REQUESTED states--we are only interested in reassigning currently active tasks.  See the getTasksForUser() method.  OIM can recover the parameters (username, password, SOA URL) to talk to SOA using the following code:

  BPELConfig bpelConfig = Platform.getConfiguration().getBPELConfig();

For each task currently assigned to a target user we use the reassignTask() method to reassign the task to the user's manager, or to a hardcoded user if no manager is configured.  The key call to the Workflow Services API is this one, where wfCtx is the Workflow context and taskSvc is a reference to the task service:

  taskSvc.reassignTask(wfCtx, t.getSystemAttributes().getTaskId(),  newAssignee);

In the sample code one can see how to go from the BPEL Config object to recovering a task service and workflow context objects that can be used to do this reassignment.

Conclusion

OIM11g allows us to detect and responds to user-lifecycle events in a agile way, ensuring that any business processes in flight are kept moving in the face of user's entering locked, disabled or deleted states.

References

  • SOA Workflow Services Developers Guide: examples of using the Worklist API
  • Jar files required for the WorkList Services API.  These jar files are available with JDeveloper: Use the Help->Check For Updates menu to install the SOA Extension:
    • soa/modules/oracle.soa.fabric_11.1.1/bpm-infra.jar
    • soa/modules/oracle.soa.fabric_11.1.1/fabric-runtime.jar
    • soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar
    • oracle_common/modules/oracle.xdk_11.1.0/xml.jar
    • oracle_common/modules/oracle.xdk_11.1.0/xmlparserv2.jar
  • SOA Workflow Services API Javadoc




About

user12587121

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today