Business Process Choreographer (BPC) is a component in WebSphere Process Server (hereafter called Process Server) that provides support for business processes and human tasks. One of the features in BPC is the mechanism of event handlers that allow business processes to asynchronously listen for and react to events triggered by a partner.
This mechanism is powerful, but it has some limitations thoroughly described in the following article, Event Handlers in Business Process Choreographer. This article will focus on one of those limitations, the conflicting-receive, and will provide a solution for it.
Overview of the conflicting-receive problem
To understand the conflicting-receive problem, a simple business scenario will be described. Let's assume there is a company that has decided to change its billing system from paper to paperless. After business and architectural analysis, the company's IT team is assigned a task to create a HUB system that must handle the following scenario:
- Receive a package of electronic invoices from a customer.
- Perform business validation of the invoices.
- Route the package to the target division.
- For each invoice in the package and within a timeout period:
- Wait for an approval or reject response from the target division.
- Send an e-mail to the customer with the details of the response.
- Wait for a confirmation from the customer.
This sequence is shown in Figure 1, where each interaction is modeled as an asynchronous interaction.
Figure 1. Business sequence diagram
This flow is easily implemented using a business process. An example is illustrated in Figure 2, which is designed with WebSphere Integration Developer V7 (hereafter called Integration Developer).
Figure 2. Business process generating a conflicting-receive
The flow in Figure 2 is as follows:
- Receive a request (with the package of invoices).
- Log the start.
- Initialize some variables.
- Perform some business validation.
- Route the package to the target division.
- Enter an event handler scope and start a timeout activity.
- If a
- Invoke a one-way service to send an email to the customer.
- Wait for an asynchronous response through the "Receive Confirmation from Customer" activity.
- Increment a notification counter.
- Check for a notification completion.
- If the timeout expires, log the expiration.
- If a
- Log the end.
The business process waits for concurrent events until it receives all the notifications for all the invoices contained in the initial package, or until the timeout expires. In the latter case, an action can be performed; for example, notifying a forced acceptance (not implemented in the sample scenario).
When compiling this business process, the following warning appears in the Problem view of Integration Developer:
The ReceiveConfirmationfromCustomer receive activity is contained in onEvent event number 1 of the Scope scope activity, which implements a one-way operation, which can result in the standard fault bpws:conflictingReceive
It says that a potential problem exists about multiple Receives against one correlation set. In other words, if more than one event is concurrently received by the business process event handler, it ends up in multiple threads with the same correlation set, waiting for an asynchronous response. When the second thread enters the "Receive Response" while the first one is already waiting, the following error occurs:
CWWBE0057I: Activity 'ReceiveConfirmationfromCustomer' of processes '_PI:90030131.526f9779.acb6fde5.e9df13b7' has been stopped because of an unhandled failure. com.ibm.bpe.api.StandardFaultException: CWWBE0065E: Activity 'ReceiveConfirmationfromCustomer' and activity 'ReceiveConfirmationfromCustomer' cannot be enabled simultaneously.
That is the so-called "conflicting-receive limitation" that prevents the implementation of real customer scenarios using the out-of the-box event handler mechanism of Integration Developer.
To overcome this limitation, you need to provide each thread with its own correlation set by creating a new child business process per event that communicates with its parent in an asynchronous way. This is described in the following section.
A solution for the conflicting-receive problem
The proposed solution is based on using two long-running business processes:
- A parent business process corresponding to the original one, where you remove the "Send Email to Customer" and "Receive Confirmation from Customer" steps from the event handler.
- A child long-running business process that contains the logic extracted from the parent event handler.
Let's analyze the new parent business process first.
Parent process description
The new parent business process is illustrated in Figure 3.
Figure 3. Parent business process
In place of the "Send Email to Customer" and "Receive Confirmation from
Customer" steps, there is a new asynchronous request-response
activity in the event handler that calls a sub-process illustrated in the
following section. The "Exit?" choice is the same as in the previous
process and checks if no more events are expected (that is, it checks if
notificationCounter variable has reached
the total number of inner invoices). In that case, it throws an exception
to exit the event handler.
If you take a look at the details of the
Increment notificationCounter snippet, you have
the following code (see the Download section of
the article to get the complete source):
notificationCounter++; if (notificationCounter == numInvoices) notificationsCompleted = true; else notificationsCompleted = false;
It is important that
notificationCounter is a
global variable and
local to correctly handle the concurrency.
Figure 4 shows the interface of the child business process
Figure 4. Interface of the child business process
By looking at the source code, the new interface has the input and output parameters taken from the two replaced activities, "Send Email to Customer" and "Receive Confirmation from Customer". Obviously, the operation related to the "Receive Confirmation from Customer" activity was moved from parent to child.
Child process description
The child business process is illustrated in Figure 5.
Figure 5. Child business process
This business process is straightforward and implements just the logic
inside the old event handler. It sets a correlation set to its parameters
idInvoice (illustrated in Figure 4), invokes the email service, and waits for a response.
After that, it asynchronously responds to the parent business process to
notify the completion.
This article showed how to solve a limitation of the BPC Event Handler when multiple receive activities were required by the business process flow. This solution moved some logic from the event handler to a child business process and made the two processes interact asynchronously (in a request-response way).
The author would like to thank Bernd Breier for his review of this article.
|Project interchange file||ConflictingReceiveProblem_PI.zip||56KB|
|Project interchange file||ConflictingReceiveSolved_PI.zip||62KB|
- See the article Event Handlers in Business Process Choreographer to better understand the conflicting-receive limitation of Business Process Choreographer.
- To learn about Business Process Choreographer concepts through many sample scenarios, see Business Process Management samples & tutorials.
- For a technical overview on business processes, see the Business processes overview section of the WebSphere Process Server V7 Information Center.
- For how-to articles and technical information, see the developerWorks WebSphere Process Server and WebSphere Integration Developer resource page.
- To participate in discussion forums, see the WebSphere Process Server forum or the WebSphere Integration Developer forum.