20 Communicating With Other BPMN Processes and Services
Learn how to develop a BPMN process that communicates with other BPMN processes and services. Also learn how to invoke other processes or services and how to broadcast a message to multiple process and how to configure your process to wait for a specific broadcast message.
-
Introduction to Communication with Other BPMN Processes and Services
-
Communicating With Other BPMN Processes and Services Using Message Events
-
Using Message Events to Invoke Asynchronous Services and Asynchronous BPMN Processes
-
Using Service Tasks to Invoke Synchronous Operations in Services and BPMN Processes
-
Communicating With Other BPMN Processes and Services Using Send and Receive Tasks
-
Using Send and Receive Tasks to Invoke Asynchronous Services and Asynchronous BPMN Processes
-
Introduction to Communication Between Processes Using Signal Events
20.1 Introduction to Communication with Other BPMN Processes and Services
Oracle BPM provides multiple ways for BPMN processes to communicate with other processes or services, such as messages,send and receive tasks, and signal events.
-
Messages
They enable you to invoke asynchronous services or asynchronous BPMN processes. You can also use them to define the interface your process exposes to other processes or services.
See Communicating With Other BPMN Processes and Services Using Message Events, for more information about message events.
-
Send and Receive Tasks
They are very similar to message events. You can choose to use one or the other.
The only difference they have with message events is that they support boundary events.
They enable you to invoke asynchronous services or asynchronous BPMN processes. You can also use them to define the interface your process exposes to other processes or services.
See Communicating With Other BPMN Processes and Services Using Send and Receive Tasks, for more information about send and receive tasks.
-
Signal Events
They enable you to broadcast a message to multiple process. The processes waiting for that specific message react to it.
See Communicating Between Processes Using Signal Events, for more information about signal events.
20.1.1 Introduction to Synchronous and Asynchronous Operations
Message events, send and receive tasks, and service task use operations to communicate with other BPMN processes or services. These operations can be synchronous or asynchronous.
The main difference between a synchronous and an asynchronous operation is how the process invoking the service or operation responds when invoking the service or operation.
When you invoke a synchronous operation, you send a message and then wait for a response before proceeding with the process flow.
When you invoke an asynchronous operation, you send a message but do not wait for an answer to proceed with the process flow. The asynchronous operation receives the message and starts running. You can obtain the answer of an asynchronous operation by invoking a callback operation. If you invoke the callback operation before the asynchronous operation finishes running, then you must wait for it to complete before getting the answer.
Message events and send and receive task require you to specify how to associate an operation with its corresponding callback. Conversations allow you to group one or more operations with their callback. A conversation may define multiple operations that you can use to access a BPMN process.
20.2 Communicating With Other BPMN Processes and Services Using Message Events
Message events enable you to communicate with the other BPMN processes and services in your project.
You can use message events to:
-
Invoke an asynchronous service.
-
Invoke an asynchronous BPMN process.
-
Define an interface for other processes to communicate with your process.
Note:
The send and receive tasks perform similar functionality to the throw and catch message events. However, it is recommended that you do not mix both within a single process.
The implementation of the different message events varies according to the type of event and their role in the conversation. Table 20-1describes the different implementation of message events.
You can configure message start events in a subprocess to suspend the main process flow. For more information, see Suspending the Current Process Flow to Run an Alternative Process Flow.
Table 20-1 Message Event Implementation
Event | Initiates Conversation | Continues Conversation |
---|---|---|
Message Start |
|
Not Available |
Message Throw |
|
If it continues a start event or a catch event that defines an interface:
If it continues a message throw that invokes a service or a BPMN process:
|
Message Catch |
|
If it continues a start event or a catch event that define an interface:
If it continues a throw event that invokes a service or a BPMN process:
|
Message End |
Not Available |
If it continues a start event or a catch event that define an interface:
If it continues a throw event that invokes a service or a BPMN process:
|
20.3 Using Message Events to Invoke Asynchronous Services and Asynchronous BPMN Processes
You can use message events to invoke asynchronous services and asynchronous BPMN processes.
To invoke an asynchronous operation from service or BPMN process you must use an intermediate throw message event configured to initiate a conversation.
When the BPMN Service Engine runs the message throw event, it creates an XML message based on:
-
the asynchronous operation
-
the input required by the asynchronous operation
-
the data association defined for the message throw event
Then it sends the XML message to the service or BPMN process, and continues running the rest of the process flow. It does not wait for the asynchronous service or BPM process to answer.
The asynchronous service or BPMN process receives the message and runs the requested operation. When it finishes it sends a message with the result of the operation to the BPMN process that invoked it. This message is the callback operation of the asynchronous service or BPMN process.
The BPMN process that invoked the asynchronous operation must wait for the callback operation to obtain its results. The BPMN process must define a message catch event that waits for the callback operation. This message catch event continues the conversation and uses the message throw event that invoked the operation as the initiator event.
When a token arrives to the message catch event it might receive an immediate answer if the asynchronous process completed, or might have to wait until the asynchronous process completes to get an answer.
Figure 20-1 Invoking an Asynchronous Service or BPMN Process Using Message Events

Description of "Figure 20-1 Invoking an Asynchronous Service or BPMN Process Using Message Events"
20.3.1 How to Invoke Asynchronous Service Operation Using Message Events
You can invoke an asynchronous service operation using message events.
To invoke an asynchronous service operation using message events:
20.3.2 How to Receive the Callback Operation of an Asynchronous Service Using Message Events
You can receive the callback operation that pairs with an asynchronous operation using message events.
To receive the callback operation of an asynchronous service using message events:
20.3.3 What Happens When You Invoke an Asynchronous Service Operation Using Message Events
When you invoke an asynchronous service operation using a message throw event, the BPMN Service Engine does not wait for the service to answer. It continues running the flow objects that follow to the message throw event.
The BPMN process can obtain the response of the asynchronous service by invoking the service callback operation using a message catch event.
Even if the service finishes running, the BPMN process does not receive the service response until it invokes the callback operation using a message catch event.
If the service is still running when the BPMN Service Engine runs the message catch event, then the engine waits for the service operation to complete before passing the token to the next flow object in the process.
20.3.4 How to Invoke an Asynchronous BPMN Process Operation Using Message Events
You can invoke a node in an asynchronous BPMN process using message events.
To invoke an asynchronous BPMN process operation using message events:
20.3.5 How to Invoke the Callback Operation of an Asynchronous BPMN Process Using Message Events
You can invoke the callback operation that paris with an asynchronous node in a BPMN process using message events.
To invoke the callback operation of an asynchronous BPMN process using message events:
20.3.6 What Happens When You Invoke an Asynchronous BPMN Process Using Message Events
When you invoke an asynchronous BPMN process using a message throw event, the BPMN Service Engine does not wait for the BPMN process to answer. It continues running the flow objects that follow to the message throw event.
The invoking BPMN process can obtain the response of the asynchronous BPMN process by invoking the service callback operation using a message catch event.
Even if the asynchronous BPMN process finishes running, the invoking BPMN process does not receive the response until it reaches a message catch event that receives a message from the asynchronous BPMN process.
If the asynchronous BPMN process is still running when the BPMN Service Engine runs the message catch event, then the engine waits for the asynchronous BPMN process to complete before passing the token to the next flow object in the process.
20.4 Using Message Events Configured as Boundary Events
You can use message catch events configured as boundary events to wait for an event while an activity is running. If the message arrives after the activity finishes running, then the event is not triggered.
You can configure a boundary message catch event as interrupting or non-interrupting.
Interrupting boundary message catch events stop running the activity when the expected message arrives. Then the engine starts running the flow defined for the message catch event. The flow defined for interrupting boundary message catch events may resume the main process flow.
Non-interrupting boundary catch events do not stop running the current activity. When the expected message arrives the engine starts running the flow defined for the message catch event in parallel to the current activity. The flow defined for non-interrupting boundary message catch events cannot resume the main process flow.
You can configure boundary events to suspend the flow object or subprocess they are associated to. For more information, see Suspending the Current Process Flow to Run an Alternative Process Flow.
20.5 Using Service Tasks to Invoke Synchronous Operations in Services and BPMN Processes
Service tasks enable you to invoke synchronous operations in services and BPMN processes.
When the BPMN Service Engine runs a service task, it invokes the operation specified in the service task and waits for a response. The BPMN Service Engine does not move the token to the next activity until it receives a response from the synchronous service or BPMN process.
The services you can use from a service task include BPEL processes, SOA mediators and SOA adapters that expose synchronous operations. You can also use service tasks to invoke other BPMN processes that expose synchronous operations.
See Using Message Events to Define a Synchronous Operation in a BPMN Processes Interface or Using Send and Receive Tasks to Define a Synchronous Operation in a BPMN Process for more information on how to define synchronous operations in a BPMN process.
Figure 20-2 Invoking a Synchronous BPMN Process or Service Using a Service Task

Description of "Figure 20-2 Invoking a Synchronous BPMN Process or Service Using a Service Task"
20.5.1 How to Invoke a Synchronous Service Operation Using a Service Task
To invoke a synchronous service operation you must use a service task.
To invoke a synchronous service operation using a service task:
20.5.2 What Happens When You Invoke a Synchronous Service Operation Using a Service Task
When the BPMN Service Engine runs a service task, it waits for the service to respond before continuing with the process flow. When the service finishes running, it sends the response to the service task.
If the service operation returns output data, then this data is mapped to the data objects in the project using the service task data association.
20.5.3 How to Invoke a Synchronous BPMN Process Operation Using a Service Task
You must invoke a synchronous BPMN process operation using a service task.
To invoke a synchronous BPMN process operation using a service task:
20.5.4 What Happens When You Invoke a Synchronous BPMN Process Operation Using a Service Task
When the BPMN Service Engine runs a service task, it waits for the synchronous BPMN process to respond before continuing with the process flow. When the synchronous BPMN process finishes running, it sends the response to the service task.
If the synchronous BPMN process returns output data, then this data is mapped to the data objects in the project using the service task data association.
20.6 Communicating With Other BPMN Processes and Services Using Send and Receive Tasks
Send and receive tasks enable you to communicate with the other BPMN processes and services in your project.
The only difference between message events and send and receive tasks is that you can add boundary events to the latter. If you are invoking an asynchronous service and you want to add a deadline using a timer event configured as boundary, then you must use a send and a receive task instead of using message events.
You can use send and receive tasks to:
-
Invoke an asynchronous service.
-
Invoke an asynchronous BPMN process.
-
Define an interface for other processes to communicate with your process.
To use a receive task to define the start operation of a process, you must locate it after a none start event and configure it to create instances.
The implementation of the different message events varies according to the type of event and their role in the conversation. Table 20-1describes the different implementation of message events.
Note:
The send and receive tasks perform similar functionality to the throw and catch message events. However, it is recommended that you do not mix both within a single process.
Table 20-2 Send and Receive Tasks Implementation
Task | Initiates Conversation | Continues Conversation |
---|---|---|
Send Task |
|
If it continues a receive task that defines an interface:
|
Receive Task |
|
If it continues a receive task that defines an interface:
If it continues a sent task that invokes a service or a BPMN process:
|
20.7 Using Send and Receive Tasks to Invoke Asynchronous Services and Asynchronous BPMN Processes
You can use send and receive tasks to invoke asynchronous operations in services and BPMN processes.
To invoke an asynchronous operation from service or BPMN process you must use a send task configured to initiate a conversation.
When the BPMN Service Engine runs the send task, it creates an XML message based on:
-
the asynchronous operation
-
the input required by the asynchronous operation
-
the data association defined for the message throw event
Then it sends the XML message to the service or BPMN process, and continues running the rest of the process flow. It does not wait for the asynchronous service or BPM process to answer.
The asynchronous service or BPMN process receives the message and runs the requested operation. When it finishes it sends a message with the result of the operation to the BPMN process that invoked it. This message is the callback operation of the asynchronous service or BPMN process.
The BPMN process that invoked the asynchronous operation must invoke the callback operation to obtain its results. When it invokes the callback operation it might receive and immediate answer if the asynchronous process completed or might have to wait until the asynchronous process completes to get an answer.
Figure 20-3 Invoking an asynchronous service or BPMN process using send and receive tasks

Description of "Figure 20-3 Invoking an asynchronous service or BPMN process using send and receive tasks"
20.7.1 How to Use a Send Task to Invoke an Asynchronous Service Operation
You can invoke an asynchronous service operation using a send task.
To invoke an asynchronous service operation using the send task:
20.7.2 How to Use the Receive Task to get Callbacks from the Invoked Asynchronous Service
You can get the callback operation that pairs with an asynchronous service operation using a receive task.
To get the callback operation of an asynchronous service:
20.7.3 What Happens When You Invoke an Asynchronous Service Using Send and Receive Tasks
When you invoke an asynchronous service operation using a send task, the BPMN Service Engine does not wait for the service to answer. It continues running the flow objects that follow to the send task.
The BPMN process can obtain the response of the asynchronous service by invoking the service callback operation using a receive task.
Even if the service finishes running, the BPMN process does not receive the service response until it invokes the callback operation using a receive task
If the service is still running when the BPMN Service Engine runs the receive task, then the engine waits for the service operation to complete before passing the token to the next flow object in the process.
20.7.4 How to Use the Send Task to Invoke an Asynchronous BPMN Process Operation
You can use a send task to invoke an asynchronous BPMN process operation.
To invoke an asynchronous BPMN process operation:
20.7.5 How to Use a Receive Task to get the Callback operation of an Invoked Asynchronous BPMN Process
You can use a receive task to get the callback operation that pairs with an asynchronous process operation.
To get the callback operation of an asynchronous BPMN process:
20.7.6 What Happens When You Invoke an Asynchronous BPMN Process Using Send and Receive Tasks
When you invoke an asynchronous service operation using a send task, the BPMN Service Engine does not wait for the service to answer. It continues running the flow objects that follow to the send task.
The BPMN process can obtain the response of the asynchronous service by invoking the service callback operation using a receive task.
Even if the service finishes running, the BPMN process does not receive the service response until it invokes the callback operation using a receive task.
If the service is still running when the BPMN Service Engine runs the receive task, then the engine waits for the service operation to complete before passing the token to the next flow object in the process.
20.8 Introduction to Invoking a Process Using Call Activities
You can invoke a process from another process using call activities. The invoked process is a child of the process invoking it.
When you run a call activity, the engine does not create a new token for the reusable process. The token in the parent process passes to the reusable process. When the token completes the child process, it returns to the parent process to continue running the activities that follow the call activity.
The child process must be a reusable process. Reusable processes can be invoked from multiple processes. You can only start a reusable process by invoking it from a call activity.
You cannot access reusable process from other SOA components because they are not part of the SOA composite.
The start event of a reusable process must always be of type none. The end event can be a error or a message event.
20.9 Invoking a Process Using Call Activities
You can use call activities to invoke a process from another process. The child process must be a reusable process.
You can invoke a reusable process from multiple processes within your BPM project.
20.10 Introduction to Communication Between Processes Using Signal Events
Signal events allow you to broadcast a message to all the processes in a BPM project. Only the processes configured to listen to that signal react.
In the Sales Quote example you might want to trigger a signal when a quote gets approved to trigger all the process that depend on the approval of a quote.
Mediators and BPEL processes also react when a BPMN process broadcasts a signal and they can also trigger a BPMN process by broadcasting a signal.
Oracle BPM uses Oracle Event Delivery Network (EDN) to send and receive signals. For more information about Oracle EDN see “Using Business Events and the Event Delivery Network" in Developing SOA Applications with Oracle SOA Suite.
For information on how to access Event in Oracle BPM, see Introduction to the Business Catalog.
The EDN events your SOA project defines automatically appear in the business catalog in the Events predefined module Events. When you add a signal event you can choose which of the events in the business catalog the signal event broadcasts or reacts to.
You can broadcast a signal from a throw intermediate signal event or from a signal end event. In a BPMN process you can only receive a signal in a a signal start event in another process.
The process that broadcasts the message has no information about the receivers. You might add or remove processes that react to a signal without impacting the process that broadcasts the signal.
In a similar way, the process that reacts to a specific message has no information about the processes that broadcast that message. If you add a process that broadcast a message to your project, all the process waiting for that specific message react to it without you having to modify them.
The events you use to broadcast a signal contain a payload that you can use to send information to all the processes configured to react to this specific signal. To assign values to the payload in the event you must configure the signal throw event data association. This data association enables you to pass the relevant data stored in the process and project data objects to the event. When the corresponding processes receive the signal, they must obtain the data in the event using another data association. This data association defines which data objects store the data in the event received in the signal start event.
Note:
Use signal events to communicate with other processes. The process that broadcasts the signal event does not include itself in the broadcast list.
20.11 Communicating Between Processes Using Signal Events
You can use signal events to communicate a message to all the processes that are configured to wait for that message.
You can broadcast a signal from a throw intermediate signal event or from a signal end event. In a BPMN process you can only receive a signal in a a signal start event in another process.
20.11.1 How to Broadcast a Signal to Multiple Processes
Before following this procedure you must add the events you want to broadcast, to your SOA project.
To broadcast a signal to multiple processes:
20.11.2 How to Configure Your Process to React to a Specific Signal
Before following this procedure you must add the events you want to react to, to your SOA project.
To configure your process to react to a specific signal: