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

Lucas Jellema 5
0 0
Read Time:3 Minute, 35 Second

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:

image

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:

image

The exact value for the manager attribute is:

uid=Matthew,ou=people,ou=myrealm,dc=soa_domain

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:

image

 

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.

About Post Author

Lucas Jellema

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director and Oracle Developer Champion. Solution architect and developer on diverse areas including SQL, JavaScript, Kubernetes & Docker, Machine Learning, Java, SOA and microservices, events in various shapes and forms and many other things. Author of the Oracle Press book Oracle SOA Suite 12c Handbook. Frequent presenter on user groups and community events and conferences such as JavaOne, Oracle Code, CodeOne, NLJUG JFall and Oracle OpenWorld.
Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

5 thoughts on “SOA Suite 12c: Human Task and Escalation through the LDAP hierarchy

  1. Hi Lucas,

    Firstly I would say, this is a vert good post and easily understandable as well. But I have one doubt, could you please help me out how to create more than one user inside the human task component in soa 12c composite editor

  2. Hi Lucan,

    Is there any oracle Soa 12c handBook chapter complements are you providing.. Like oracle soa 11c you provided .

    Please let me know 🙂

  3. Hi Lucas, is there any way of assign approver according to the hierarchy of the LDAP?
    For example John is the boss of David. So the request will be automatically assign to John.

    Thanks.

Comments are closed.

Next Post

Oracle Service Bus: Obtaining a list of exposed SOAP HTTP endpoints

The Oracle Service Bus is often used for service virtualization. Endpoints are exposed on the Service Bus which proxy other services. Using such an abstraction layer can provide benefits such as (among many other things) monitoring/logging, dealing with different versions of services, throttling/error handling and result caching. In this blog […]
%d bloggers like this: