Communicate Between Processes
Processes can interact using message start and message end events, send and receive activities, or message throw and message catch events. Processes can also call other processes or include subprocesses.
Processes interact synchronously when one process starts another and waits for a response. Processes interact asynchronously when one process starts another and both processes run independently.
Interaction Type | Description |
---|---|
Message Start and Message End events |
If you define input arguments for a process in a message start event, you must supply data for these arguments to start the process. You can asynchronously start a process that begins with a message start event using a message throw event or send activity in another process. Or you can synchronously start such a process using a Service activity. A process that begins with a message start event is exposed as a web service after deployment. Therefore, you can connect with the process as a web service consumer to start it. See Creating a Web Service Connection. If you define output arguments for a process in a message end event, the process supplies data for these arguments when it completes. |
Send and Receive activities |
A send activity sends data to and starts another process. A receive activity receives data from another process when it completes. Send and receive activities can have boundary events, unlike message throw and message catch events, which can't. See Using Send and Receive to Communicate Between Processes. For a send activity in a calling process, see Calling Another Process. For a receive activity or a send activity in the called process, see Defining Input or Output Arguments. |
Message Throw and Message Catch events |
A message throw event sends data to and starts another process. A message catch event receives data from another process when it completes. See Using Message Throw and Catch to Communicate Between Processes. For a message throw event, see Calling Another Process. For a message catch event, see Defining Input or Output Arguments. |
Service activity |
A Service activity can call another process or a web service. The send, receive, and call activities and the message throw and message catch events can only call another process asynchronously. The Service activity can call a process asynchronously or synchronously. However, if the called process begins with a message start event, the call must be synchronous. For web service details, see Creating a Web Service Connection. |
Call activity |
A Call activity starts another process as a child process. The parent process waits for the child process to complete before continuing. This lets you reuse a process in multiple processes that call it. See Defining Input and Output Arguments for a Child Process. |
Subprocess activity |
A Subprocess activity contains a subprocess with its own start and end events. A subprocess isn't separate from its parent process. A subprocess activity lets you hide the complex details of a part of a process to make the overall process more readable. Click Expand to expand the subprocess, then drag and drop activities directly into the subprocess. Click Collapse to collapse the subprocess. |
Use Send and Receive to Communicate Between Processes
Use the send and receive activities to start another business process and receive messages back from it. Processes that begin with a receive activity and contain a send activity are exposed as services that other processes and services within Process can use.
The diagram shows how a send activity starts another process and a receive activity receives a response.
The following steps outline a possible scenario for using send and receive activities to communicate between processes.
-
Process A starts.
-
The flow of Process A reaches the send activity.
-
The send activity starts Process B.
The send activity implementation specifies which process is started.
-
The flow of Process A continues to the next flow element.
-
The receive activity initiates an instance of Process B.
The start event in Process B must have a Trigger value of None. The receive activity implementation must have Create Instance checked.
-
Process B runs.
-
Depending on the specific behavior of both processes, the following scenarios may occur:
-
If the flow of Process A reaches a receive activity paired with a send activity from Process B, the flow of Process A waits until a response is received.
After the response is received, the flow of Process A continues to the next flow element.
-
If the flow of Process B reaches a send activity paired with a receive activity in Process A, Process B sends a response to Process A.
The flow of Process B continues to the next flow element.
-
-
Both business processes continue running.
You can use subsequent send and receive pairs to define subsequent communication between the two processes.
Use Message Throw and Catch to Communicate Between Processes
Use combinations of message throw and message catch events to start and communicate with other business processes.
When using a message throw event to start another business process, the following conditions must be met:
-
The business process being started must be an asynchronous process.
Although you can use a message throw event to start a synchronous process, there is no mechanism for catching messages synchronously from the other process. To start a synchronous process, use the Service activity.
-
The first time you use a message throw event, it must be paired with the message start event of the process it starts.
This is required to start the process instance. After the instance has been started, you can use subsequent message throw events that are caught by other events in the second process.
Processes that begin with a message start event are exposed as web services. See Creating a Web Service Connection.
Processes started by another process aren’t considered child processes. This means that a terminate end event in the calling process doesn’t stop a process started with a message throw event.
This diagram shows how a message throw event starts another process and a message catch event receives a response.
The following steps outline a possible scenario for using message throw and catch events to communicate between processes.
-
Process A starts.
-
The flow of Process A reaches a message throw event that starts Process B.
-
The message throw event sends a message to the message start event of Process B.
-
The flow of Process A proceeds to the next flow element.
-
The message start event starts an instance of Process B.
-
Process B runs.
-
Depending on the specific behavior of both processes, the following scenarios may occur:
-
If the flow of Process A reaches a message catch event paired with a message throw event from Process B, the flow of Process A waits until the message is received.
After the message is received, the flow of Process A continues to the next flow element.
-
If the flow of Process B reaches a message throw event paired with a message catch event in Process A, Process B throws a message to Process A.
The flow of Process B continues to the next flow element.
-
-
Both processes continue running.
You can use subsequent message throw and message catch event pairs to define subsequent communication between the two processes.
Define Input or Output Arguments
You can define input arguments for message start and message catch events and for receive activities. You can define output arguments for message end events and for send activities in processes called by other processes.
Define Input and Output Arguments for a Child Process
You can define input and output arguments for a child process called by a call activity in the parent process.