Solving the conflicting-receive limitation in Business Process Choreographer

This article provides a solution to the conflicting-receive limitation mentioned in the following developerWorks article: Event handlers in Business Process Choreographer.


Gero Morreale (, Senior IT Specialist, IBM

Photo of Gero MorrealeGero Morreale is a Senior IT Specialist with the IBM Software Services for WebSphere (ISSW) team in Italy since 2005. He has experience in building solutions for Italian customers in the area of Business Process Management.

21 September 2011


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:

  1. Receive a package of electronic invoices from a customer.
  2. Perform business validation of the invoices.
  3. Route the package to the target division.
  4. For each invoice in the package and within a timeout period:
    1. Wait for an approval or reject response from the target division.
    2. Send an e-mail to the customer with the details of the response.
    3. 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
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
Business process generating a conflicting-receive

The flow in Figure 2 is as follows:

  1. Receive a request (with the package of invoices).
  2. Log the start.
  3. Initialize some variables.
  4. Perform some business validation.
  5. Route the package to the target division.
  6. Enter an event handler scope and start a timeout activity.
    1. If a receiveDivisionNotification event arrives:
      1. Invoke a one-way service to send an email to the customer.
      2. Wait for an asynchronous response through the "Receive Confirmation from Customer" activity.
      3. Increment a notification counter.
      4. Check for a notification completion.
    2. If the timeout expires, log the expiration.
  7. 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. 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
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 the 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):

if (notificationCounter == numInvoices)
	notificationsCompleted = true;
	notificationsCompleted = false;

It is important that notificationCounter is a global variable and notificationsCompleted is local to correctly handle the concurrency.

Figure 4 shows the interface of the child business process ConflictingReceiveEventHandlerSub.

Figure 4. Interface of the child business process
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
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 idPackage and 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 fileConflictingReceiveProblem_PI.zip56KB
Project interchange fileConflictingReceiveSolved_PI.zip62KB





developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management, WebSphere
ArticleTitle=Solving the conflicting-receive limitation in Business Process Choreographer