SOA Suite 12c: Human Task and Escalation through the LDAP hierarchy image55

SOA Suite 12c: Human Task and Escalation through the LDAP hierarchy

A Human Task in SOA Suite can be configured to automatically escalate when the task is not taken care of for a certain period of time. This escalation implies that the task is assigned to the person (or persons) one level higher up the organizational hierarchy than the people who had gotten the task assigned originally.

In this article I will show very briefly a setup for the task definition and and the user & groups in the embedded LDAP directory in WebLogic that together make this escalation work.

The task is defined with the following Assignment for a one participant of type “single participant”  in a single stage:image

So the task is set (radio button) to be be auto-assigned to a single user according to the Least Busy assignment pattern. The Group to which the task is assigned is selected from the identity store (which is just the embedded LDAP directory in WebLogic).

On the Deadlines tab of the task editor, we have specified that the assignees better be quick: after two minutes, the task will be escalated to the next level up the hierarchical food chain:


If we had 40 levels of hierarchy, that is how for the task could get escalated. We run out of hierarchy after about three levels – because that is the way how things are defined in the LDAP.

Through the WebLogic Admin console, I created several users (Dick, Tom, Harry, Matthew and Mark), groups (Account Manager, Sales Manager and CEO) and group memberships (Tom, Dick and Harry => Account Manager, Matthew to => Sales Manager and Mark => CEO). Using the JXplorer tool and the perfect instructions in this article: Creating an hierarchical user structure in embedded LDAP of weblogic , I ensured that Tom, Dick and Harry are peers that report to Matthew who reports to Mark:


The exact value for the manager attribute is:


in the case of Tom, Dick and Harry.

Deploy and Run

If the SOA composite that contains the task is deployed and its exposed service is invoked. the task gets instantiated – assigned to the role of Account Manager. If we do not touch it, it will be escalated: after two minutes to the manager(s) of the Account Managers and two minutes later to the manager of that/those manager(s) – Mark, the CEO. This is what the flow trace tells us after five minutes:



Right after calling the service, you could login to the BPM worklist application, as Tom. You should see the newly created task – available for Tom to work on. Logout and login as Dick. This user too should see the task, because of his membership of the Account Manager group to which the task was assigned. The same applies to Harry.

If Dick claims the task or even executes it, it is no longer available to Tom and Harry: only one of them has to complete the task. After initially claiming the task, Dick can also release the task if for some reason he cannot complete it after all. The task the reappears in the todo lists for all three account managers.

If no one touches the task for 2 minutes, an automatic escalation takes place. Login to the BPM worklist application as Matthew before the 2 minutes are up, and there should not be any tasks visible. However, when an AssessProposal task was unattended for 2 minutes, the manager of the original assignees – Matthew, who is the manager of Tom, Dick and Harry – gets the now escalated task assigned. And if he does not react within 2 minutes, the task is moved up the hierarchy once more, to Mark whom Matthew reports to.

Note: It seems that the setting of the radio button to be auto-assigned to a single user [according to the Least Busy assignment pattern] is crucial (without I did not get the escalation). I have not tried but suppose the users with the initial role (Account Manager) would have several managers among themselves, would then escalation take place to all of these managers? And would the next round of escalation involve multiple people as well – the managers of these first time managers?

Note: this article complements chapter 17 of the Oracle SOA Suite 12c Handbook.


  1. Mithun July 5, 2016
  2. Yadav February 3, 2016
  3. Yadav January 29, 2016
  • Joshua Lan November 21, 2014