Custom Escalation in Oracle BPM Suite 11g (guest post by Vivek Acharya)

This article is contributed by our guest writer Vivek Acharya. Vivek is an Oracle Consultant working as a Professional Freelancer. He has been in the Design, Development, consulting and Architect world for approximately seven years working in Oracle Practice at IBM,HP,Zensar. He is an Oracle Certified Expert as Oracle Fusion-SOA 11g Implementation Specialist and Oracle – BPM 11g Implementation Specialist. He has experience and expertise in Oracle Fusion – SOA, BPM, BAM, Mediator, B2B, BI, AIA, Web logic,  Workflow,Rules,Webcenter,UCM,IDM,Oracle Fusion Applications,SaaS,OnDemand etc. He loves all things to do with Oracle Fusion Applications, Oracle SOA, Oracle BPM, Cloud Computing, Salesforce,SaaS and BSM.

Vivek is author of the Oracle BPM Suite 11g Developer’s cookbook (Packt, 2012).

Escalation is a common requirement while implementing Oracle BPM processes with human interactions. Processes don’t do work, it’s the people who do. This concept leads to those processes which have heavy human interactions. There are scenarios when a participant does not act on an assigned human task and such scenarios become candidate for being escalated.

Custom Escalation is to empower BPM system with the capability to introduce a check on the Task’s outcome. A participant is assigned a task and if it doesn’t acts on the task in a specified time frame, then non-availability should be accounted, published and notified. If the Participant does not act in the duration provided, the task is escalated to the manager or another user, as appropriate.

Escalation makes sure that SLAs are met and the process performs as per the exceptions within in the time frame it is suppose to. For example – if a task is assigned to a participant and the participant was suppose to respond in 2 days and it’s overdue by 4 days, it basically hampers the fabric of the process and might lead to loss of business. Assume a loan approval process. If the loan document request is awaiting a loan officer approval and it’s overdue in its kitty by 4 days. Then it’s the best practice to escalate overdue information and the task to another participant.

This post is meant to showcase custom escalation and how participant list can be build dynamically.

Duration deadline section in human task metadata can be used to create human task definition.

By default escalation is based on the management chain hierarchy and task gets escalated up in the hierarchy from user to his/her manager and so on. You can control the level to which task can be escalated and can also use a title to which task gets escalated to. Level and title assignment can be configured while configuring human task definition’s duration deadline.

Oracle BPM offers varied ways to escalate –

1. Role Based escalation

2. Level & Title based escalation and

3. Custom Escalation.

This blog post covers Level & Title based escalation and custom escalation by implementing “IdynamicTaskEscalationPattern” interface.

When to use custom escalation?

A couple of seeded patterns are available for task escalation like the one shown below –

Assignment Pattern	Type	Description
MANAGERS_MANAGER	Task escalation	Picks the manager’s manager.

However for those scenarios, where hierarchy are not defined or when requirement is to explicitly use a list or users to whom task should be escalated rather than using default management chain feature, than custom escalation is an option.

 

Level & Title based escalation

Am trying to use an approval group as the user list building option as this was the initiation requirement which fueled this blog post. However other list building mechanism can be used.

Also to simply list building, am using a static dynamic group however dynamic group can be configured and used too, as a custom mechanism to build user/group list. Following is the Participant Type definition. Instead of Dynamic Approval Group am using the Static Approval group, however the story remains the same.

1.    Login to BPM workspace – http://server:host/bpm/workspace as admin user.
2.    Go to Administration and click Task administration → Approval Group
3.    Create a Static group named – “DynamicAG” with two users – jstein and jlondon as shown below –

To use the Approval group in your human task –

4.    Open the human task definition and go to Assignment Section and open the participant type definition as shown below.
•    Following configuration is meant to assign tasks in serial fashion and hence participant type is serial.
•    List of participant is build using approval group. Use the static group created above or you can use a dynamic group for building the list dynamically based on a Java call.

With a requirement to escalate to three (3) levels and stop the escalation when the title reached is CEO can be configured as follows –

5.    Click on Human task definition and open deadline definition as shown below. For the test purpose, set the time to three minutes.  With this configuration, task will get escalated if the assignees do not act on it in three minutes. Escalation will follow the hierarchy of the user defined in weblogic embedded LDAP and task will escalate till level three and stop if the title of CEO is reached or three levels are achieved.

6.    Deploy the process.
7.    Test escalation process from EM console.
8.    Following is the screen shot of the task assignment. Login to BPM workspace as ‘admin’ user and check the task assignment as shown below –

You can witness that the task got assigned to user “jstein” as per the user list returned from the static approval group.

Wait for 3 minutes to get the task allocation time to expire.
Now check the behavior after 3 minutes which is as follows –

You can check that – task got assigned to – user “wfaulk” after it got expired from the user “jstein” task queue.

Why did that happen?
Answer lies in the myreal (embedded LDAP). User “wfaulk” is defined as manager to “jstein”.

Now there are 2 possibilities –
If user “wfaulk” doesn’t approve the task for another 3 minutes – it would get assigned to his manager which is – user “cdicken” as shown below –

And if user “cdicken” does not act on the task, task gets totally expired. This happens due to the fact that we have defined Highest Approver = CEO and user ‘cdicken’ is a CEO.

Custom Escalation –

Normally escalation is based on the fact that if“X” users doesn’t approves then it goes to its manager and so on. Similarly you can browse the identity lookup and that will give you the pointers to the task behavior as we have experienced above –

1.    Click on user “jstein”
2.    Click on Hierarchy and that will show the hierarchy defined in embedded LDAP.
3.    Click on user “cdicken” and click DETAIL button which will show the user title = CEO.
Because user “cdicken” is holding title ‘CEO’, the task got stopped at CEO level in spite of the fact that we have defined task with elevation level = 3

You can also define the title for the user in myreal, as shown below –

Escalation works on the principle that user hierarchy should be defined.

If not – You can always use Custom Escalation Java Class in Deadline section of Task Definition.

Custom Escalation Project

1.    Create a Generic project say – “CustomEscalator”
2.    Add following libraries to the project – BPM Workflow, BPEL Runtime, BPM Services.
3.    Create a java class with the desired name. In the project which you have downloaded, java class is named as “CustomEscalator”.Class must be in the package: oracle.bpel.services.workflow.assignment.dynamic and must implement the interface oracle.bpel.services.workflow.assignment . dynamic.IDynamicTaskEscalationPatten
4.    Modify following methods as per you requirement. For this use case, following screen shot contains the method definition –
•    getTaskEscalationUser (Task task)  – This method returns a string value which contains the username to whom you want to escalate. We have used the username “salesrep”. Remember to create the user “salesrep” in myrealm (Weblogic embedded LDAP).
•    GetName () – This method returns a string value which is the name of the escalation function. With this case, escalation function name is entered as “CustomEscalator”.

5.    Right click on the “CustomEscalator” project created above and open it;s properties.
6.    Click on deployment and create a deployment profile to generate the jar file of the class created in the previous step, in this case the deployment profile is called customEscalate, generate the jar and place on a route available in the server classpath.
7.    Place the generated jar file n the path SOA_ORACLE_HOME \ soa \ modules \ oracle.soa.ext_11.1.1
8.    In the unix box, go to SOA_ORACLE_HOME \ soa \ modules \ oracle.soa.ext_11.1.1 and run  – ant-buildfile build.xml

Now you need to create a custom task escalation function and register this with the human workflow service.
9.    Login to EM console http://server:host/em as admin user.
10.    Right click on soa_infra => Soa Management => Workflow Properties as shown below –

11.    Open Task tab and click Add Function to create a custom task escalation function. This would register the custom function with human workflow service.
12.    Enter the name of the function – “CustomEscalator” and enter Classpath as – “oracle.bpel.services.workflow.assignment.dynamic.CustomEscalator” where “CustomEscalator” is the class name.
13.    Click OK and Apply to persist the changes.
14.    Restart the server to let the changes applied.
15.    Open the .task file of the human task and go to deadline configuration as shown below.
16.    Let the escalation happen in three minutes. To enable this, enter three minutes as fixed duration type for escalation.
17.    Enter Custom escalation class name as shown below.
18.    Save and Deploy BPM project.

19.    Execute “EscalationPrj” project by login to EM.
20.    Login to BPM workspace as admin user and in administration tab you can check the task assignment history shown as below –

You can check the created and expiration time. This is three minutes as you have set in task configuration.
21.    Refresh after three minutes and you can verify the escalation as shown below. You can witness that the task gets assigned to “salesrep” user after three minutes.

If “salesrep” user, meaning the user to whom task is escalated , does not act on the task, then the task gets expired.

Happy Reading 