Friday Aug 17, 2012

Business Process Interrupt Design Pattern


Requirement

How do I optionally interrupt the normal flow of an in-flight business process instance to modify or end it gracefully?

Problem

In this problem scenario, a business process instance has been started by an initial request and the in-flight instance begins to execute its normal business flow.

Normal execution of the in-flight instance may need to be interrupted due to receipt of one or both of the following types of messages meant to:

  • Modify the behavior of the in-flight instance execution path based on the content of one or more modification request messages.
  • Cancel the execution of the in-flight instance after the necessary clean-up activities have been completed.

Arrival of the interrupting message(s) will call for the in-flight instance to stop executing its normal primary business flow and start executing interrupt-specific activities.

Once interrupt-specific activities are complete, the instance may be able to rejoin the primary business flow. The decision to have the modified instance rejoin the primary flow is business- driven and not mandatory. If rejoining is required, you must design the BPEL to fulfill this requirement.

In the case of a gracefully cancelled instance, rejoining is irrelevant and therefore not required.

Use Cases

Order Fulfillment Process

Order Fulfillment Process execution needs to be terminated when a cancellation message arrives

  1. An end user submits an order for 100 light bulbs from 101bulbs.com.
  2. The in-flight business process instance begins to execute its normal Order Management business process flow.
  3. After clicking the Submit Order button, the end user receives a phone call that the 100 light bulbs are no longer needed.
  4. Implementation of the "Interruptible Business Process Instance" design pattern enables the 101bulbs.com site to offer the end user a "Cancel Order" option within a window during which the instance is interruptible.
    • The window during which the instance is interruptible is dependent on the use case. The window may or may not be time-based. In this example, the window during which the order can be cancelled closes once the order goes to shipment in the order process flow. For another example, see the Collection Strategy use case below.
  5. The end user clicks the Cancel Order link on the site to cancel the order.
  6. This end user action sends an interrupt message that arrives in parallel to the in-flight business process instance.
  7. Receipt of the interrupt message stops the normal execution flow so that the in-flight business process instance (the order) can be cancelled and necessary clean-up activities can be performed.

Order Fulfillment Process execution needs to be modified when a change order message arrives

  1. An end user submits an order for 100 light bulbs from 101bulbs.com.
  2. The in-flight business process instance begins to execute its normal Order Management business process flow.
  3. After reading the order confirmation email, the end user realizes that he meant to order only 10 light bulbs.
  4. Implementation of the "Interruptible Business Process Instance" design pattern enables the 101bulbs.com site to offer the end user a "Modify Order" option within a window of time during which the instance is interruptible.
  5. The end user clicks the Modify Order link on the site to access his order, modify the quantity, and submit the modified order.
  6. This end user action sends an interrupt message that arrives in parallel to the in-flight business process instance.
  7. Receipt of the interrupt message stops the normal execution flow so that the interrupt-specific quantity modification activities can be performed.
  8. Once the modification is complete, the normal business process flow can resume.

Collections Strategy

Credit companies apply different collection strategies to solicit payments due from delinquent customer accounts. Strategy is template defined with a collection of Work items that needs to be applied on customers depending on grouping and filtering of customers. Strategies include issuing payment reminders by phone and mail, placing the account in collections, invoking legal escalations, and so forth.

Once a strategy is applied on a group of customers, there should be a control to cancel this strategy in case if there is change in strategy Template. For instance, when the process is in one strategy state; the customer might have paid off. Hence the credit card company would want to cancel the applied strategy. When existing strategy is canceled, the requirement is to terminate the running business process instances with that strategy

  1. The credit company applies a specific collections strategy to a delinquent customer account. This raises the appropriate events and the in-flight business process instance begins to execute its normal collection strategy business process.
  2. There are two possible scenarios here that run in parallel.
    • An initial collection strategy is applied. The Strategy gets completed if there is no work item left.
    • The customer makes the required payment. This customer action sends an interrupt message that arrives in parallel to the in-flight instance. Receipt of the interrupt message stops the normal execution flow so that the interrupt-specific modifications (or cancellation) can be made to the selected strategy based on the customer payment.

Once the modification is complete, the normal business process flow can resume. If the interrupt message was for cancellation of the collections strategy, it is cancelled and necessary clean-up activities are performed.

Solution

To address this problem, the business process design should:

  • Accept optional event requests, such as modification and cancellation requests.
  • In addition to a normal business interface, expose another interface (service operation in the WSDL) to client applications through which interrupting messages can be sent. Only services that need to address the problem being described must define this additional interface. Not every process is required to include these interruptible interfaces.
  • Include one or more event handlers to process these various event requests.
  • Identify the point up until which these event requests can be accepted. Associate event handlers at the right level to ensure that event requests are not entertained after the process instance has progressed beyond this point.
  • Process these event requests in parallel to the business process primary execution flow and in parallel to each other.
  • Use the message correlation feature, which will ensure that the interrupting message can be delivered to the correct business process instance.
    • The message correlation feature is an infrastructure mechanism that enables the correlation of asynchronous messages based on message body content. For this solution, you select a unique XML element in the message body as the correlation identifier.

Caveats

Following are side effects, challenges, and other issues you should expect when implementing a solution to address this problem:

  • Interrupting messages (one or more) arrive in parallel to the primary business flow.
  • The primary business flow must not be required to wait for the arrival of possible interrupt messages.
  • Interrupt messages may not be received by every business process instance. Many business process instances will NOT receive interrupt messages during their execution.
  • When no interrupt message is received, the business process instance needs to continue its normal execution sequence.
  • Arrival of the interrupt message will sometimes call for the reversal of certain work completed prior to its arrival.
  • Clients may or may not know the state of the running instance. For this reason, a client may end up sending interrupt messages after the instance has reached the point of no return.
  • When processing interrupting messages, you must design the business process to deliver the system in a consistent state. Specifically, any transactions that are committed by primary business flow activities cannot be rolled back. 
  • Receipt of interrupt messages does not automatically undo work that has already been completed. The developer must design the process to perform any necessary clean-up tasks based on receipt of the interrupt message. 
    • For example, receipt of a cancellation message after a human workflow task has been created does not mean that the human workflow task will be automatically removed from the worklist of a participant. If the use case warrants, the developer must add any necessary activities to the onMessage event handler to enable the cancellation message to programmatically cancel the human workflow task.

Implementation

These implementation guidelines assume that Oracle BPEL technology will be used to implement the business process. I will post a blog soon on how this pattern could be implemented using BPM tool.

Describing the Structure of an Interruptible Business Process

Let’s assume that we are building the following integration flow: 

  1. A customer initiates the flow by sending the submitOrder message the CRM system. 
  2. This action triggers the sending of the createOrder message from the CRM system to the Order Management BPEL process. This Order Management process is what we are building to implement this interrupt pattern.
  3. The Order Management process then invokes an external service that provides the required functionality to be used by the Order Management process.
  4. While the external service processing is underway, the Order Management process is in a "wait" state during which a customer may send another message to the CRM system to cancel the order.
  5. The CRM system sends the cancelOrder interrupt message to the Order Management process. 
  6. The Order Management process receives the interrupt message and performs the appropriate activities to cancel the Order Management process. 

As mentioned in the Solution section, the business process must be built so that it can react to events that occur while the business process executes. The business process must not wait for an interrupting event, but rather it should execute while listening for potential subsequent interrupting events and handle them, if they arrive.

This design pattern uses event handlers and correlation sets, as described in the following sections, to support this recommended approach. Using this approach, an interrupt event is received in-flight using an event handler and is correlated to the correct in-flight BPEL process instance using a defined correlation set.

Understanding Event Handlers

BPEL provides event handlers, which are meant to enable this exact capability for a business process. Event handlers are defined to enable a process to handle events that may arise independent of or asynchronous to the process. They can be defined at the process (global) or scope (local) level and remain active as long as their enclosing process or scope remains active.

For this design pattern implementation, we will define the event handler at the process level. The event handler is defined to receive a specific event message. When this corresponding event message arrives, event handlers are invoked concurrent to the primary business process flow.

Understanding Correlation Sets

To ensure that an interrupt message is delivered to the intended in-flight BPEL process, we will use BPEL correlation sets. A BPEL correlation set is a set of key message payload elements, such as OrderID or AccountID, which enables the correlation of incoming payloads to preexisting in-flight processes.

BPEL correlation sets provide a mechanism by which a BPEL process instance can be registered in memory against a correlation set whereby subsequent requests to the BPEL process can be routed to a specific BPEL process instance.

Constructing an Interruptible Business Process

This section describes the high-level steps involved in constructing an interruptible business process.

Step 1: Extend the Service WSDL and Corresponding Schema XSD Files

In this step, we will extend the WSDL of the Order Management process SOA service and the corresponding schema XSD files to facilitate invocations to the specific interrupt operation.

In the Order Management process service WSDL, define an additional operation, such as cancelOrder, apart from the primary business operation(s).

The service WSDL now exposes at least two operations:

  1. A primary business operation, such as createOrder, which the service will carry out in the primary business flow of the BPEL.
  2. An interrupting operation, such as cancelOrder, which will trigger the OnMessage event handler of the BPEL process instance identified by correlation set.

The new interrupting operation may have a different message type. If this is the case, add a new schema XSD file and import it into the service WSDL. 

CancelOrder Interrupt Message Sample Schema

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://xmlns.oracle.com/InterruptPatternSampleProcess" targetNamespace="http://xmlns.oracle.com/InterruptPatternSampleProcess" elementFormDefault="qualified">
     <xsd:element name="CancelOrder">
          <xsd:complexType>
               <xsd:sequence>
                    <xsd:element name="orderID" type="xsd:string"/>
               </xsd:sequence>
          </xsd:complexType>
     </xsd:element>
</xsd:schema> 

Service WSDL Sample Snippet Containing Imported CancelOrder XSD

<wsdl:types>
     …
     <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema">
          <xsd:import namespace="http://xmlns.oracle.com/InterruptPatternSampleProcess" schemaLocation="xsd/cancelOrder.xsd"/>
     </xsd:schema>
</wsdl:types>
     …
<wsdl:message name="cancelOrderReqMsg">
     <wsdl:part name="cancelOrder" element="tns:CancelOrder"/>
</wsdl:message>
     …
<wsdl:portType name="InterruptPatternSampleProcess">
     <wsdl:operation name="createOrder">
          <wsdl:input message="tns:createOrderReqMsg"/>
     </wsdl:operation>
     <wsdl:operation name="cancelOrder">
          <wsdl:input message="tns:cancelOrderReqMsg"/>
     </wsdl:operation>
</wsdl:portType>   

Step 2: Construct the BPEL Process for Event Handling

Construct the BPEL process according to business specifications and requirements. In addition to these normal activities, the BPEL must also be designed to accept interrupt messages. To do this, associate an OnMessage event handler with either a scope or with the business process (which we also refer to as the "global scope"). 

  • When you add an event handler at the process level, this means that it is enabled as soon as the process instance is created. In this case, an event handler is invoked when the corresponding interrupt message occurs anytime during the lifetime of the process.
  • When you add an event handler to a specific scope, this means that the event handler is enabled only when this scope becomes active. The event handler is disabled when the scope ends. In this case, the event handler associated with the scope wait for specified interrupt messages and if no message occurs while the scope is active, the event handler does nothing and is disabled when the scope ends.

To do this, access the Edit OnMessage dialog box. On the General tab, set the Operations: field value to cancelOrder. The cancelOrder operation was added to the service in Step 1: Extend the Service WSDL and Corresponding Schema XSD Files.

Screenshot of setting the Operations field value to cancelOrder on the General tab of the Edit OnMessage dialog box

Within this OnMessage branch, add the activities that must be performed upon interruption of the process. This OnMessage branch is triggered upon receipt of an incoming interrupt request message for the cancelOrder operation. It accepts the interrupt request message and carries out the defined activities.

Under normal circumstances when the interrupt request message is not received, the BPEL process service component continues its normal execution sequence without waiting for the optional interrupt message.

Event Handler Code Sample Snippet

<eventHandlers>
     <onMessage variable="OnMessage_cancelOrder_InputVariable" partnerLink="interruptpatternsampleprocess_client" portType="ns1:InterruptPatternSampleProcess" operation="cancelOrder">
          <correlations>
               <correlation set="Correlation_Set1" initiate="no"/>
          </correlations>
          <sequence name="Sequence1">
               <empty name="CleanupActivities"/>
               <terminate name="Terminate1"/>
          </sequence>
     </onMessage>
</eventHandlers> 

Note that the event handler contains a correlation set. For more information, see Step 3: Create Correlation Sets.

The following diagram provides a sample illustration of the BPEL process to be constructed. The primary business flow is on the left and may include activities such as Receive, Assign, Invoke, and so forth. The event handler is on the right and includes the onMessage definitions.

Diagram of BPEL process to be constructed

The BPEL flows as follows:

  1. The primary business flow starts when an input business message to the process arrives.
  2. If an interrupt message arrives, the event handler’s sequence is executed in parallel with the execution of the primary business flow activities.

Note: The Wait activity in this diagram is a dummy activity denoting that the process is in dehydration state after performing some asynchronous activity.

Step 3: Create Correlation Sets

We use correlation sets to ensure that interrupt messages are delivered to the correct BPEL process instances. The correlation set associates the input business message that triggers the process with the interrupt message received by the OnMessage handler.

Create correlation sets and property aliases for the activities that need to support correlated message payloads. Start with the initial receive activity and work through to the onMessage handler. Define correlation sets based on the elements in the BPEL process input business message. Good candidates for these aliases are primary key values, such as OrderID. 

Double-click a receive or onMessage activity to display the Correlations tab. From there, begin defining the correlation set and define property aliases for key elements in the message payload. Select the appropriate elements of the respective input payload using the Property Alias browser. The following screenshot of the Edit Property dialog box shows the defined property aliases and associated input payload elements. Once the property aliases have been added, the correlation set is complete.

Edit Property dialog box

Screenshot of the Edit Property dialog box displaying defined property aliases and associated input payload elements

For more information about creating correlation sets, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite, "Using Correlation Sets and Message Aggregation."

The next step in creating the correlation set is to group the primary BPEL receive activity and the onMessage activity. Configure the primary BPEL receive activity to use the defined correlation set and set its initiate property yes. For the onMessage activity that leverages the same correlation set, set the initiate property to no. The receive and onMessage activities are now in a correlated group.

When the initiating input payload arrives and triggers the initial receive activity, the correlation set is “registered” in memory. When any subsequent service invocations to this component are made, including the arrival of interrupt messages, they will be inspected for a correlation match. If a match is made, the interrupt message, for example, will be routed to the in- flight/in-memory instance.

Assumptions

Implementation of this design pattern is based on the following assumptions:

  • Interruption of an in-flight instance is possible only for asynchronous processes.
  • Interruption can be performed only on process instances in a dehydrated state.

Related Patterns

Message Correlation Pattern

Additional Information

Correlation Set in BPEL to Interrupt BPEL on Kavin's Technology Space

About

This is the blog about Oracle Business Integration Design Patterns. Our team which is part of Business & Data Integrations Development Organization at oracle, focuses on providing technical and architectural guidance & support to Fusion Applications, AIA as well as Product Development teams across various Global Business Units on designing & building integrations. This blog focuses on discussing the different types of integration use cases we have come across and how the design patterns prescribed, could be used to implement similar use cases leveraging various components (BPEL, OSB, Mediator, OBR, BAM, BPM, CEP, WLS) available in Oracle SOA & BPM Suite.

Search

Categories
Archives
August 2012 »
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
18
19
20
21
22
24
25
26
27
28
29
30
31
 
       
Today