Using Intermediate Events and Advanced TaskService Interactions in Oracle BPM Suite 11g

This blog post will demonstrate with the help of a basic use-case the use and importance of intermediate events in Oracle BPM based processes. A typical business process also has manual touch points that are implemented by process users through Human Task UI’s. It is evident that a very important aspect in any agile business process is the ability to interact with these in-flight human tasks based on intermediate events. This post shall also demonstrate how to modify in-flight task States in Oracle BPM Suite 11g. You can similarly do a host of other operations with the full use of the Worklist Management API’s.  Keep reading.

Intermediate Events occur in the middle of the process and are of either Catch or Throw type. The Catch Events wait or block for appropriate signals while the Throw events proceed after throwing the signal.

The Basic Use Case

XYZ Bank has a simple business process defined for a Credit Card approval flow. Below are some important activities that any card application request has to go through.

Manual Card Approval

All requests that require further investigation (i.e. applications that cannot be pre approved using the business rules) should be sent to analysts belonging to the Credit Card Approvers role. The approver can complete the review by either Approving or Rejecting the request.

Cancel Card Application Event

While a card application request is in process, a customer can indicate that they wish to cancel their request. The customer is asked to provide an optional reason for wanting to cancel the request. The result of the cancellation request can be:

• The request was cancelled
• The request could not be cancelled because it had already been completed.

In that case the outcome of the original request should be provided to the customer.

Note : This example doesn’t deals with the cancellation scenario. This is explained in details in my previous blog post.

https://beatechnologies.wordpress.com/2011/10/17/working-with-custom-correlation-in-oracle-bpm-suite-11g-ps4-feature-pack/

Potential Fraud

There is an external process that is evaluating increase requests to look for patterns that might signal fraud. When the pattern is matched, the process generates an Handle Fraud Event for a specific application request with a score that indicates that fraud is:

Probable ( Score =< 8 )

Possible ( Score >8 )

The process needs to listen for these events and take the following actions when the Handle Fraud Event is for the specific request that is in flight.

For Possible Fraud

When a possible fraud is recorded the existing process should be terminated. Before terminating the process the Manual Approval In-Flight task (if any) should also be withdrawn.

For Probable Fraud

An Ad-Hoc Manual Task should be created for the role FraudInvestigator. While the investigation is ongoing, the normal path of process must be suspended. The outcomes of the investigation is either APPROVE or REJECT. If the outcome is REJECT the current card application request likely represents fraud, or NO, the current increase request does not represent fraud. If the investigation result is APPROVE, the normal approval processing should be resumed unless the process has been tagged as cancelled.

Refer the business process diagram below to understand the use case better.

Prerequisites

The following version of software have been used to for this example and demonstration.

• JDeveloper 11g PS4 (With BPM-SOA FP Extension)
• PS4 FP SOA and BPM Extensions for JDeveloper
• Oracle BPM Suite 11g PS4 Feature Pack

More information about downloading it can be found here

Implementing the Process

Oracle  SOA Suite leverages the Human Workflow Engine to implement Manual/User Tasks. The Human Workflow Engine exposes APIs (both Java and Web Service based) which can be used to interact with Tasks for specific business needs. There are Task Management Services which can be used to alter States of in-flight tasks, Task Query Service that can query for task details based on taskId, taskNumber or other task Predicates.

In this example I will show how we can use the TaskService to manipulate task states from within a business process.

Getting the Task Id for the “Approve Card Manually” user task.

The first thing to do is create a Process Data Object called manualTaskApprovalId to hold the value of the generated Task Id for the manual Task. The data object should be assigned the value of execData.systemAttributes.taskId from the Output tab in the Data Association for the task activity.

We will use this obtained taskId to invoke operations on the TaskService API.

Creating a Reference to the TaskService in the Composite Application

Next we will have to create a reference to the TaskService.wsdl in our composite. The TaskService.wsdl can be located in the soainfra metadata store partition.

The operations of the TaskService Web Service API’s now appear in the External Reference panel of the composite application.

Create a Mediator Component that acts as a Proxy to the TaskService Interface

Drop a Mediator Component into the composite and Define its interface from the TaskService.wsdl that is now copied into the project directory. In case you have chosen not to copy the wsdl and its dependent artifacts into the project you can refer it from the MDS. It is just the same. Also uncheck the Create Composite Service with SOAP bindings since we will only need to invoke it from within the composite.

Double click on the Mediator Component you just created. We will see that all operations in the TaskService interface appear in the Mediator. Go to the suspendTask operation in the Mediator and create a static routing rule  for it. The static routing rule should invoke a Service. From the wizard prompt use the suspendTask operation from the TaskService interface.

In a similar way create the static routing for other two operations i.e withdrawTask and resumeTask.

Fraud Check Event Subprocess

Coming to the Fraud check event sun-process the first thing we need to do is define correlation for the Handle Fraud start event. This is required as this is an intermediate event and this need to correlate with the desired in-flight process instance.

To know more about the use of correlation in Oracle BPM 11g read my previous post here.

When there is a Probable Fraud i.e fraud check score is less than 8 the process needs to be suspended in case it is awaiting for manual approval.

This can be achieved quite easily. All that we have to do is create a Service Task Activity and invoke the suspendTask operation of the TaskFlowMediator.

To keep this absolutely simple the only input required for suspendTask operation is the taskId for the Approve Card Manually Task that we had captured earlier in a process data object.

This will suspend the Manual Approval task and hence the process instance cannot  move ahead unless it is withdrawn or resumed and subsequently Approved or Rejected.

Depending upon the outcome of the Ad Hoc Approval by the FraudInvestigator role the process can either be Resumed and the original process flow continue (as the Handle Fault Event was defined as a non Interrupting Event) or it can be withdrawn the process Terminated.

This is pretty much it about the defining the main tasks and services in the process. You can find the Composite Application attached here to be more acquainted with the process flow.

Testing the Process and Verifying the Results

Post deployment of the composite application to a running server we cam test it. The composite exposes three operations (approveCard, cancelCardRequest and handleFraudEvent). Let us start to test the composite by invoking the approveCard operation that will start the card application approval process.

As you observed the instance has moved to the ManualCardApproval touch point and is awaiting for a response from a user with CreditCardApprover role.

Now let say a Fraud Event is reported now for this instance while the CreditCardApprover still hasn’t dealt with this task. In this case the Fraud Event Subprocess should kick off and the FraudInvestigator is involved for Ad Hoc Approval in case the fraud is probable.

We can emulate this scenario by unit testing the composite once again. But this time we will invoke the handleFraudEvent opetation of the composite. One important point to note here is that since we are using the customer contact number to correlate the fraudEvent with the in-flight instance, we need to have the same customer contact number in the request of this operation.

The effect of a fraud intermediate event is that the original task assigned to the CreditCardApprover role will be suspended and hence the process instance is stalled.

The FraudInvestigator has to provide an ad hoc response to confirm/reject this probable fault. So an Ad Hoc Approval Task awaits his response in his worklist.

If the FraudInvestigator approves the application then the original task is once again resumed and appears in the Assigned state in the CreditCardApprover’s worklist. Once it is approved once again (this time the approval is based on things like applicant’s eligibility, credit score, limit requested etc) the process is successfully completed.

The entire process flow diagram will give a picture of the path that the process took during its Happy-Path completion.

Testing the Unhappy Path – FraudInvestigator Confirms a Probable Fraud

To test this follow a couple of steps that we did earlier i.e. invoking an approveCard operation and then invoking the intermediate fraud check event operation for the same customer.

The flow will be similar to the above till here. The Fraud Investigator will have an Ad Hoc Approval Task and the original task will be suspended.

Now if the FraudInvestigator confirms a fraud in the application then the process instance is terminated and the original Manual Card Approval task is withdrawn.

A look at the process flow will now reveal that the process instance doesn’t moves back to the original instance (Since it is Terminated).

That’s is with the process.

Conclusion

This article deals with some advanced concepts around Oracle BPM Suite 11g. Hope it explains how we can effectively use intermediate events (of both Interrupting and Non-Interrupting Type). It also explains how we can interact with the Worklist API’s using the TaskService interface to interact with Human Workflow tasks from within a BPM process.

The composite used for the demonstration can be downloaded from this location or from here

Please send across your questions, commends and feedback and i will be eager to answer them.

.