X

Best Practices from Oracle Development's A‑Team

The curious case of SOA Human tasks' automatic completion

Introduction

A customer I was working with using Oracle BPM and SOA ran into an interesting issue with the unexpected automatic completion of a human workflow task. This article describes how to resolve this problem if you run into it.

Main Article

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: SOA 11g is designed to treat human tasks that don't have assignees as eligible for automatic completion. Because of this, no warning/error messages are recorded in the logs.

Usecase variant: A variant of this usecase, where an assignee doesn't exist in the repository, is treated as a recoverable error. You 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 is normally only see on tasks whose assignees are derived from an assignment expression - i.e. at runtime an XPath expression 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 like this, you will notice in the Audit Trail for the instance 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 example, 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, you should be able to use 'grab' to route back to the task to fire again. Hope this helps.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha