The curious case of SOA Human tasks' automatic completion
- by Kavitha Srinivasan
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:
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.
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.
