This chapter describes how to design your business processes to communicate with other processes and services.
This chapter includes the following sections:
When you add operations to a Business Process Model and Notation (BPMN) process, you are defining points in the process that other processes or services can use to communicate with it. The communication between processes and other processes or services generally requires an input and returns an output.
The flow events that you use to define the BPMN process operations allow you to define input and output arguments. These input and output arguments define the process input and output.
When you create a process that begins with a message Start event, you must define the input arguments that are passed to the process.
To define the input arguments for a process:
After you have defined the input arguments to your process, you must map them to data objects in your process.
To define data associations for a message start event:
When you create a process that contains message End events, you must define the output arguments for each End event. These are the output arguments for the process.
To define the output arguments for a process:
After you have defined the output arguments for your process, you must map them to the data objects in your process.
To define data associations for a message end event:
You can use the send and receive tasks to invoke another BPMN process and receive messages back from it. Processes that begin with a receive task and contain a send task are exposed as services that can be used by other process and services within an Oracle Business Process Management (Oracle BPM) application.
Figure 18-1 outlines the basic behavior when using send and receive tasks to invoke a process and receive a response.
Figure 18-1 Using the Send and Receive Tasks to Communicate Between Processes
The following steps outline a possible scenario when using the send and receive tasks to communicate between processes.
Process A is invoked.
A token of Process A reaches the send task.
The send task invokes Process B.
This is defined by the implementation for the send task.
The token of process A proceeds to the next flow object in the process.
The receive task initiates a process instance of Process B.
The receive task must have the Create Instance property defined. See Starting a Process with the Receive Task..
The newly created token proceeds through process B.
Depending on the specific behavior of your process, the following scenarios may occur:
If the token of Process A reaches a receive task paired with a send task from Process B, the token of Process A waits until a response is received.
After the response is received, the token of Process A continues to the next flow object.
If the token of Process B reaches a send task paired with a receive task in Process A, Process B sends a response to Process A.
The token of Process B continues to the next flow object.
Both processes continue running.
You can use subsequent send and receive pairs to define subsequent communication between the two processes.
You can use combinations of throw and catch events to invoke and communicate with other BPMN processes.
When using a throw event to invoke another process, the following conditions must be met:
The process being invoked must be an asynchronous process.
Although you can use a message throw event to invoke a synchronous process, there is no mechanism for catching messages synchronously from the process.
If you invoke a synchronous process use the service task. See Introduction to the Service Task for more information.
The first time you use a message throw event it must be paired to the message start event of the other process.
This is required to trigger the process instance. After the instance has been triggered, you can use subsequent message throw events that are caught by the second process.
Processes that begin with a message start event and end with a message end event are exposed as services that can be used by other processes and services within an Oracle BPM application.
Processes invoked from another process are not considered child processes. This is important to consider when designing processes that use the terminate end event as a process end point. For example, a terminate event in the calling process does not stop a processes invoked with a message throw event.
Figure 18-2 shows the basic behavior when using message throw and catch events to invoke a process and receive a response.
Figure 18-2 Using Message Throw and Catch Events Between Processes
The following steps outline a possible scenario when using the message throw and catch events to communicate between processes.
Process A is invoked.
The token of Process A reaches a message throw event that is configured to invoke Process B.
The message throw event sends a message to the message start event of Process B.
The token of Process A proceeds to the next flow object.
The message start event triggers an instance of Process B.
The newly created token proceeds through Process B.
Depending on the behavior of your process, the following scenarios may occur:
If the token of Process A reaches a catch event paired with a throw event from Process B, the token of Process A waits until the message is received.
After the message is received, the token of Process A continues to the next flow object.
If the token of Process B reaches a throw event paired with a catch event in Process A, Process B throws a message to Process A.
The token of Process B continues to the next flow object.
Both processes continue running.
You can use subsequent catch and throw event pairs to define subsequent communication between the two processes.
Conversations group the message exchange between two or more processes. The message exchange between processes is called collaboration. Within a project you can define multiple conversations that you can reuse amongst the processes in that project.
Conversations group the message exchange between two or more processes. The message exchange between processes is called collaboration. Within a project you can define multiple conversations that you can reuse amongst the processes in that project.
Collaboration diagrams allow you to view the process flow together with the interactions your process has with other participants in the conversation.
Your BPM project defines a conversation by default. If you do not want to define multiple conversations you must use this default conversation to gather all the message exchanges amongst the processes in your project.
You can only define one default conversation per project. However you can modify your project to use a different default conversation than the one it uses by default.
The different types of conversations allow you to specify the different types of interaction your process can establish with other processes or services. The following list describes the different types of conversations:
Define Interface: Use to define the operations that other services and processes can invoke to interact with a BPMN process.
Use Interface: Use to configure your process to use an interface from a component in the Business Catalog.
Process Call: Use to invoke another BPMN process.
Service Call: Use to invoke a service defined in your BPM project.
The following sections describe how to define and configure conversations using Oracle Business Process Composer.
To view the collaboration diagram for a process, click the View Collaboration button in the process editor toolbar.
Note:
In the collaboration view, you cannot make changes to the process. To return to normal process editing, click the View Collaboration button again.
Oracle Business Process Composer allows you to create new services in the business catalog. These services are based on standard web services.
The following sections describe how to create services using Oracle Business Process Composer.
Services based on web services are defined using a Web Services Description Language (WSDL) file. A WSDL file is an XML file used to describe how web services are implemented. When creating a new service using Oracle Business Process Composer, you can specify a WSDL file stored locally on your machine or one that is available online.
Process developers are responsible for providing a WSDL file or a URL location.