The curious case of SOA Human tasks' automatic completion

A large south-Asian insurance industry customer using Oracle BPM and SOA ran into this. I have survived this ordeal previously myself but didnt think to blog it then. However, it seems like a good idea to share this knowledge with this reader community and so here goes..

Symptom: A human task (in a SOA/BPEL/BPM process) completes automatically while it should have been assigned to a proper user.There are no stack traces, no related exceptions in the logs.

Why: The product is designed to treat human tasks that don't have assignees as one that is eligible for completion. And hence no warning/error messages are recorded in the logs.

Usecase variant: A variant of this usecase, where an assignee doesnt exist in the repository is treated as a recoverable error. One can find this in the 'pending recovery' instances in EM and reactivate the task by changing the assignees in the bpm workspace as a process owner /administrator.

But back to the usecase when tasks get completed automatically...

When: This happens when the users/groups assigned to a task are 'empty' or null. This has been seen only on tasks whose assignees are derived from an assignment expression - ie at runtime an XPath is used to determine who to assign the task to. (This should not happen if task assignees are populated via swim-lane roles.)

How to detect this in EM

For instances that are auto-completed thus, one will notice in the Audit Trail of such instances, that the 'outcome' of the task is empty. The 'acquired by' element will also show as empty/null.

Enabling the oracle.soa.services.workflow.* logger in em should print more verbose messages about this.

How to fix this

The application code needs two fixes:

  1. input to HT: The XSLT/XPath used  to set the task 'assignee' and the process itself should be enhanced to handle nulls better. For eg: if no-data-found, set assignees to alternate value, force default assignees etc.

  2. output from HT: Additionally, in the application code, check that the 'outcome' of the HT is not-null. If null, route the task to be performed again after setting the assignee correctly. Beginning PS4FP, one should be able to use 'grab' to route back to the task to fire again.

    Hope this helps. 

Comments:

Hi,
i've faced this weird behavior too. As workaround i've filled the "Error Assignees" field into the "Configure Assignement" mask. This way a wrong or not assigned task is routed to this user/role and the task goes into alerted state.

cheers

Posted by guest on September 13, 2012 at 02:51 AM PDT #

Error Assignees have nothing to do in this use case.As Kavitha explains, this behavior is seen just when an assignment resolved by a variable/XPath returns empty/null. Error Assignees work when the static or dynamic assignee is not empty *but* doesn't exist in the user repo.

Kind regards

Posted by Carlos Casares on September 16, 2012 at 10:34 AM PDT #

What if the user is disabled or terminated and still gets assigned?

Posted by guest on February 07, 2013 at 08:22 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About


This is the blog for the Oracle FMW Architects team fondly known as the A-Team. The A-Team is the central, technical, outbound team as part of the FMW Development organization working with Oracle's largest and most important customers. We support Oracle Sales, Consulting and Support when deep technical and architectural help is needed from Oracle Development.
Primarily this blog is tailored for SOA issues (BPEL, OSB, BPM, Adapters, CEP, B2B, JCAP)that are encountered by our team. Expect real solutions to customer problems, encountered during customer engagements.
We will highlight best practices, workarounds, architectural discussions, and discuss topics that are relevant in the SOA technical space today.

Search

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