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. See Defining Input or Output Arguments.
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. See Calling Another Process.
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.

Description of the illustration send-receive-tasks.png

The following steps outline a possible scenario for using send and receive activities to communicate between processes.

1. Process A starts.

2. The flow of Process A reaches the send activity.

3. The send activity starts Process B.

   The send activity implementation specifies which process is started.

4. The flow of Process A continues to the next flow element.

5. 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.

6. Process B runs.

7. Depending on the specific behavior of both processes, the following scenarios may occur:

   1. 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.

   2. 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.

8. 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.

Description of the illustration catch-throw-events.png

The following steps outline a possible scenario for using message throw and catch events to communicate between processes.

1. Process A starts.

2. The flow of Process A reaches a message throw event that starts Process B.

3. The message throw event sends a message to the message start event of Process B.

4. The flow of Process A proceeds to the next flow element.

5. The message start event starts an instance of Process B.

6. Process B runs.

7. Depending on the specific behavior of both processes, the following scenarios may occur:

   1. 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.

   2. 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.

8. 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.

To define input or output arguments for a process interaction event or activity:

1. In the process editor’s Elements Palette, expand the system or event elements.
2. Drag and drop the element into the process.
3. Select the element, click Menu , and then select Open Properties. The implementation pane appears.

   
   Description of the illustration message-implement.png

4. For a Receive activity in a process called by another process, check Create Instance.
5. Select Define Interface from the Type drop-down list. Click Edit.
6. Click Add to add new arguments, then determine the Name and Type of each argument.
7. For a Send activity in a process called by another process, select Synchronous if the process must wait for a reply.
8. Enter an Operation Name or accept the default name.
9. Define data associations to pass the input argument data to the next activity in the process. See Configure Data Association.

When you activate a process that begins with a message start event, the process is exposed as a web service. Information about the web service is displayed when you select View Deployed Services on the Manage Active Applications page. See Integrate with Applications and Services and Administrator Basics.

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.

The start and end events in the child process must have Trigger values of None. The child process can't contain elements that only make sense in an independent process, such as message events and send, receive, or service activities.

To define input or output arguments for a child process:

1. Open the child process in the process editor.
2. In the process editor, click the Restore Pane icon in the lower-right corner.
   The Properties pane opens at the bottom of the window.
3. Click the Add icon to add new input or output arguments, then determine the Name and Type of each argument.
4. Open the parent process in the process editor, select the call activity, click Menu , and select Open Properties.
5. Click Implementation.
6. Select the child process from the Process drop-down list and close the Properties pane.
7. Define data associations for the call activity to pass the input data to the child process and receive the output data from it. See Configuring Data Associations for a Process Flow Element.

Call Another Process

You call another process using a message throw event or a send, service, or call system activity.

To call another process:

1. In the process editor, expand the System or Events types in the Elements Palette.
2. Drag and drop a system or event element into the process.
3. Select the element, click Menu , and select Open Properties.
4. Click Implementation.

   • For a call activity, select a process to call from the Process drop-down list. Want to learn more about using a Call activity? See Define Input and Output Arguments for a Child Process.

   • For all other calling components, select Process Call from the Type drop-down list. Click the Browse icon, select a process, then click OK.

5. Select a different Target Node from the drop-down list if necessary.

   • For a message throw event, the message start events in the called process are listed.

   • For a send or service activity, both message start events and receive activities are listed.

6. Define data associations to receive input data from the previous activity in the process. See Configure Data Association.