Your message has been sent.
This article has been saved to your account.
Go to my account
This article has been emailed to your Kindle.
Send this article
Complete the form below to send this article, Inter-process Communication, to a friend (or to yourself). We will never share your details (or your friend's) with anyone. For more information, read our Privacy Policy.
In this article by Mark Nelson and Tanya Williams, the authors of Oracle BPM Suite 11g: Advanced BPMN Topics , you will learn to convert a video into any of the formats needed for HTML5 Video playback.
Inter-process Communication introduces us to the theory of how processes can communicate with each other and with other components. A number of topics are covered such as: conversations—what they are, and the default conversation.
Welcome to our exploration of some of the advanced topics in BPMN. When we set out to write this book, we chose the areas where we see the most confusion and difficulty in understanding how to use BPMN. We will present theory and also build practical exercises together so that you can see how the theory is applied. Let's start our journey by building an understanding of inter-process communication.
(For more resources related to this topic, see here.)
Inter-process communication refers to the ability for instances of processes to communicate—with other instances of the same process, with instances of other processes, and with services. Such communication is usually implemented so that process instances can work collaboratively to achieve a given goal. Common scenarios when this may occur include:
-
When common logic is extracted from a number of processes into a reusable "utility" process
-
When the occurrence of an event in one process means that another, perhaps separate, process needs to be started—this is often seen where the second process is an audit or investigation process
-
Where a process has a set of data, needs to run a common set of logic over each item in that data set, and then consolidate the results
-
Through normal decomposition of a business process into various levels of granularity, resulting in the need for the process to invoke one or more sub-processes to accomplish its work
There are different mechanisms available for processes to communicate with each other. In this article, we will explore the options and when we should employ each.
Conversations
A conversation is a set of message exchanges. The message exchanges can be synchronous or asynchronous, but they should all be about the same subject matter, for example, a particular order, customer, case, and so on. The set of messages that forms the conversation is typically a request and a response, or a request and several (possible) responses.
A single process instance can participate in more than one conversation simultaneously.
The collaboration diagram allows you to visualize the process in the context of its conversations. You can access the collaboration diagram using the Collaboration Diagram tab at the bottom of the process editor in JDeveloper. An example of a collaboration diagram is shown in the following diagram:

This example includes a number of features that will be discussed in this book. The small, disconnected process that begins with Order Over Limit is an event sub-process. Briefly, they are invoked if a particular event (set of circumstances) occurs at any time during the execution of the process they belong to, the ProcessOrder process in this example. If at any time it is determined that the order is over some predefined limit, then an audit is required. The event sub-process sends a message to start the Audit process using a throw message event. The collaboration diagram allows us to see both of the processes that are involved in this collaboration and shows us visually where the interaction between them occurs (with the dotted arrow from the throw message event to the start of the Audit process).
Conversations may also be scoped; this means that they may be defined in a smaller scope than the process as a whole. For example, you can define a conversation inside an embedded sub-process. To define a scoped conversation, you must do so in the Structure pane so that the conversation is placed in the correct scope. If you do not define the conversation in the Structure pane, it will inherit the process scope. The following image shows a process with two conversations defined: myconv1 at the process (global) scope, and the scoped conversation scopeConv, which is inside an embedded sub-process:

In addition to defining conversations for communication with other processes, each service that you want to interact with will also require a conversation. When implementing your process, you need to create a conversation for each service, choose Service Call as the type, and then select the service you wish to interact with.
The default conversation
Each process has a default conversation. The default conversation is used to expose services provided by the process, and it therefore controls the interface for invocation of the process. This interface manifests itself as the WSDL port type.
The default conversation can be defined "top down" by starting with WSDL (service contract) for the process and creating the conversation from that, or "bottom up" by defining the arguments for the process and having the service interface (WSDL) generated from the process.
If we are using the bottom-up approach, the interface is defined by adding arguments to the start node, as shown in the following screenshot. You need to select Define Interface as the message exchange type to use the bottom-up approach. The arguments can have simple types (String, Date, Integer, and so on) or complex types, that is, they can be based on the business object (which in turn can be based on an element or type definition in an XSD).

Correlation
Correlation is the mechanism that is used to associate a message with the conversation that it belongs to. There are two main classes of correlation:
-
Automatic correlation refers to mechanisms where the correlation is handled automatically. BPM uses mechanisms like WS-Addressing and JMS Message IDs to achieve automatic correlation.
-
Message-based correlation refers to the mechanism the process developer needs to define some keys, which can be extracted from the message in order to determine which conversation a message belongs to. Examples are given in the next section.
There are some occasions when message-based correlation is necessary because automatic correlation is not available, for example:
-
When the other participant does not support WS-addressing, or
-
When a participant joins the conversation part way through but has only the data values, but no other information about the conversation
If you do not specify any settings for message-based correlation, the runtime engine will attempt to use automatic correlation. If it is not possible to do so, then you will get a correlation fault. The engine checks to see if the called process or service supports WS-addressing, in which case it will insert a WS-addressing header into the call. It will then wait for a matching reply. Similarly, if JMS is being used to transport the message, it will look for a reply message with the JMS correlation ID that matches the JMS message ID of the message it sent.
Correlation is especially important inside a loop construct, as there may be multiple threads/receives waiting at once, and the engine needs a way to know which reply belongs with which receive.
Summary
In this article, we have explored the inter-process communication and the default conversation.
This article has introduced us to the theory of how processes can communicate with each other and with other components. A number of topics are covered such as: conversations—what they are, and the default conversation.
Resources for Article :
Further resources on this subject:
- Author Podcast - Ronald Rood discusses the birth of Oracle Scheduler [Article]
- Oracle Integration and Consolidation Products [Article]
- Author Podcast - Aleksander Seovic Talks About Oracle Coherence 3.5 [Article]
About the Author :
Mark Nelson
Mark Nelson is a Consulting Solution Architect in the Oracle Fusion Middleware Architect's Team (known within the Oracle community as "the A-Team") in Oracle Development. Mark spends a significant part of his time working with Oracle BPM Suite users around the world. His other main area of technical interest currently is Continuous Integration and its application to Oracle Fusion Middleware. Mark is one of the question authors for the Oracle SOA Certification Exam. He lives in Sydney, Australia.
Tanya Williams
Tanya Williams is a Principal Solution Consultant in the Oracle Fusion Middleware Sales Consulting team in Australia. Tanya has experience helping organizations understand Oracle's products, map the product capabilities to their business needs, develop demonstrations and proofs of concept, and giving advice and guidance on adoption of Oracle products. Tanya spends much of her time working with Oracle BPM Suite and how to use Oracle BPM Suite, SOA Suite, and Service Bus to integrate with Oracle applications like E-Business Suite. Tanya has presented and run hands-on labs at Oracle OpenWorld. Tanya lives in Sydney, Australia.
Tanya and Mark contribute to the popular "RedStack" blog at http://redstack.wordpress.com, and have both presented at a number of Oracle OpenWorld and various regional Oracle User Group events.



Post new comment