The building blocks of the BPEL process editor

IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing business processes > Building BPEL processes > Defining BPEL process logic
The building blocks of the BPEL process editor

Compose your own BPEL process using a combination of the building blocks listed in this topic.
There are several kinds of building blocks:

Partners
Variables
Correlation artifacts
Activities, elements, and handlers

Partners

These are the external users or services that interact with the process.
There are two kinds of partners:

Interface partners
The interface partner is a direct link to the interface where the partner is configured. An interface partner is the process interface and exposes operations that can be called by external partners
Reference partners
The reference is not an interface, but instead tells the process where to find operations that it can invoke. More to the point, it specifies the interface that is used in the invocation of another component.

Variables

Variables store the messages that are exchanged between the partners in a process and the data that is used in its business logic.
A variable belongs to the scope in which it is declared. If it is created in the global process scope then it is a global variable, and thus visible to the process as a whole. Those that are created within nested scopes can only be seen by objects within that scope.
There are two choices available:

Data type variables
This variable can be either a business object or a simple type.
Interface variables
This variable uses either an input or output parameter as defined within an interface.

Correlation artifacts

Correlation sets
Correlation sets are used in runtime environments where there are multiple instances of the same process running. The sets allow two partners to initialize a BPEL process transaction, temporarily suspend activity, and then recognize each other again when that transaction resumes.
Correlation Properties
Similar to correlation sets, correlation properties make it possible for the runtime engine to recognize a specific process in an environment where multiple ones are running.

Activities, elements, and handlers

When you work with the palette and the canvas, you will be working with a combination of the three following types of objects:

Activities
Activities are the individual business tasks that operate in conjunction with each other to implement the larger business goal that is represented by the BPEL process that contains them.
Elements
Elements are the objects used to support or configure activities.
Handlers
Handlers appear as inline interactive boxes that you populate with activities. They are associated with an activity on the canvas and, when certain conditions are met within this parent activity, they represent a specific course of action.
The following graphic shows a fault handler (with a catch element), and an empty compensation handler that are both associated with an invoke activity. If how each handler is connected to the parent activity through a line of a different color.

The following tables provide a description of all the activities, elements, and handlers that are available in the palette, as well as the action bars that appear when you hover over an activity on the canvas. The palette is located to the left of the canvas.

Basic Actions palette menu

The following table describes the activities that are available in the Basic Actions palette menu.

Activities in the Basic Actions palette menu
Activity Description
Invoke Use this activity to call an operation on a specific partner. Operations can be either one-way (asynchronous) or request/response (synchronous).
Assign Use this activity for basic data manipulation through the use of expressions, to map service endpoint references to or from partner links, or to copy some form of information from one part of your process to another.
For example, it could be used to update the values of your variables or partner links.
Receive This activity waits for a single external input, and channels it into the process.
Receive choice This is a structured activity, in that it contains other activities that are organized onto individual control paths. It halts the process in order to wait for an operation to be called on it, and then follows the control path that is appropriate to the first message it receives. The first activity in that path, can be either a receive case element or a timeout element. The various inputs that a receive choice anticipates must be mutually exclusive, an example would be orders received for pick-up or delivery, a receive choice can route these two options to two different receive cases.
Reply Use this activity in a synchronous (request/response) operation to return the output or fault to the partner that initiated the operation. This activity specifies the same partner implementation as the corresponding receive activity. A reply is always sent to the same partner from which a message was previously received
Wait Use this activity to stop the process for a specified period of time. You configure this activity either by telling it how long it should hold up the process, or by specifying when it has waited long enough.
Empty action Use this activity as an undefined object to act as a placeholder within your process. You might do this if you were designing a process that you expected somebody else to implement, or if you were trying to synchronize the activities within a parallel activity.
Snippet Use this activity to compose visual expressions and Java™ code and thereby insert custom behavior into your process.
Data map Use this activity to transform data between two variables.

Structures palette menu

The following table describes the activities that are available in the Structures palette menu.

Activities in the Structures palette menu
Activity Description
Scope Use this activity to act as a behavioral container for one or more activities in your process. By definition, your process as a whole is contained within a single global scope, and you can nest other scopes within it, forming a hierarchy.
A variable is visible only in the scope in which it is declared. If it is created in the global process scope then it is a global variable, and thus visible to the process as a whole. Those that are created within nested scopes can only be seen by objects within that scope.
Each scope has a primary activity that defines its normal behavior, and you can associate a scope with fault, event or compensation handlers.
You can also use a scope activity for enhanced dynamic behavior, by using an administrative human task to grant a user administrative privileges over the execution order of the activities that are nested within the scope.
You can configure a scope in one of two ways:

Choose isolated when you want to control simultaneous access to shared variables.
Choose compensable if you want to allow compensation related activities on this scope. If this check box is clear, then this scope will be transparent to all compensation logic.

Parallel Use this activity to nest other activities that will run concurrently. This is a structured activity, in that it contains other activities separated into individual control paths that are dictated by links and transition conditions. You can embed as many paths in the activity as you want, and they will all be executed simultaneously. This activity is equivalent to the concept of fork/join: all the paths within the activity are run simultaneously, and the target activity will not fire until all paths have completed.
Sequence Use this structured activity to nest a series of activities into your process that will be run in the order in which they are placed. Execution returns to the BPEL process when the last activity within the nest has completed.
Choice This is a structured activity, in that it contains other activities that are organized onto individual control paths. During execution, the choice activity evaluates the conditions on the paths in order, and follows the first one that evaluates to True.
You can embed as many paths as you want, each containing one case element followed by any other activities that are necessary. If none of the control paths evaluate to true, then the otherwise path is chosen.
While loop Use this structured activity to repeat one or more activities as long as specific success criteria or conditions are being met. If the condition that leads to the activity evaluates to false, then none of the activities within will be executed.
For Each The For Each activity repeats the execution of the activities that it contains either sequentially or in parallel for a specified number of iterations.
For an example of how to use a For Each activity, see the paper WS-BPEL 2.0 forEach activity - a typical usage pattern.
Generalized Flow Use this activity to nest activities on individual, customized control paths. A generalized flow activity is very similar to a parallel activity in that you can control the execution order of those activities nested within it through links. The generalized flow activity differs however in its ability to use conditional links to loop back to previous activities in the sequence.

Faults palette menu

The following table describes the activities that are available in the Faults palette menu.

Activities in the Faults palette menu
Activity Description
Compensate Use this activity within a scope's fault or compensation handler to invoke a specific compensation handler within the scope.
Throw Use this activity to signal an internal fault. In defining the properties of this activity, you can specify a name and a message in the properties area of the BPEL process editor. These details can then be passed onto a fault handler that presumably is configured to deal with this kind of exception.
Rethrow Use this activity to forward a fault from inside a fault handler to delegate the handling of a fault to an enclosing scope. The fault is sent to the enclosing scope exactly as it was caught by the fault handler, that is, any modifications of the associated fault data are ignored.
Terminate Use this activity to halt the execution of a process. When used, all activities that are currently active are halted without any fault handling or compensation behavior. When the terminate activity has been invoked, its own fault handler is executed.

Human Workflow palette menu

The following table describes the activities that are available in the Human Workflow palette menu.

Activities in the Human Workflow palette menu
Activity Description
Human Task Use the human task activity to send a process-related task out to a human for completion. This activity is used in conjunction with the human task editor. Double-click an existing human task activity on the canvas to launch the human task editor.
Collaboration scope Use a collaboration scope in situations where a BPEL process requires a well-defined procedure without a loss of operational flexibility. A collaboration scope is ideal when a BPEL process is knowledge-intensive and the end result can be expedited by allowing task owners to adapt the workflow to the current situation.

Action bar

The elements and handlers that appear in the action bar will vary according to what activity is currently selected. The following table provides a list, in alphabetic order, of the elements that you might see.

Elements and handlers in the action bar
Element Icon Description
Case element Used within a choice activity, this element is used to create a control path and define the conditions that will cause this path to run. During execution, the process will evaluate the conditions in each of the case elements, and follow the first one that evaluates to true.
Catch element Use this element within a fault handler to intercept, and deal with a specific kind of fault. The catch element is always the first element on a fault handler's control path, and the activities that follow it are executed should the fault conditions you specify occur. You can catch a built-in fault type, or define one yourself. On the canvas, each catch shows the name of the fault type that it will catch, and each is associated with a variable.
Catch all element Use this element within a fault handler to intercept, and deal with any fault that is not already defined in an existing catch element. The catch all element is the first object on a control path, and the activities the follow it are executed should the fault conditions you specify occur.
Compensation handler Use the compensation handler on either an invoke or a scope activity, and within a long-running process to define logic that will run when a fault is thrown after the parent activity has already been committed. Compensation is used when the activity cannot simply be reversed or undone, but another operation must be executed in order to return the failed process to a balanced state.
Create a note

Use this tool to place a note anywhere on the canvas. You can then enter text into the body of the note to label specific parts of your BPEL process.
Event handler Use the event handler to associate either a process or a scope activity with an external stimulus. They can respond to events that happen at any time during an application's lifetime, or as many times as those events repeat. There can be several paths within the handler, and they determine how the process should proceed based on the nature of the data received. Each path is preceded by either an OnEvent or a Timeout element.
Fault handler A fault handler is a collection of specific activities that will run when a fault is thrown on the activity with which the handler is associated. Fault handlers can be used on both invoke and scope activities, and will run either when a fault is thrown by the invoke activity, or by an activity inside the scope activity.
You can place activities on paths within the handler to either deal with anticipated faults, or attempt to find another way to complete the operation. Each path within the fault handler is preceded by either a catch, or a catch all element.
Link Use the link within a parallel activity to connect nested activities and form individual control paths. The link is used to express a synchronization dependency. In other words, it is execution under constraint because the link creates a dependency of one activity and the variables it uses on another activity. You can specify a transition condition on the link in the properties area of the BPEL process editor.
Local variable Click this to create a local variable that will be visible to all objects within the associated scope activity.
OnEvent element Use this element within an event handler to create a control path and specify the operation that will cause this path to be executed.
Otherwise element Use this element within a choice activity to to create a control path that will run when none of the other cases evaluate to true. Use this element on only one of the paths within a choice activity. When run, the process will evaluate the conditions in each of the case elements, and should none of them evaluate to true, it will run the activities in this path.
Receive case element Use this element within a receive choice activity to create a control path and specify the operation that will run it. There is at least one receive case element path nested within a receive choice activity. When run, the process halts at the receive choice activity and listens for a message from its operations. The first message that comes in determines which path is executed.
Set compensate link Use this element with a compensate activity to call a compensation handler on nested scopes.
Set partner

Use this to select a partner to associate with this activity.
Timeout element Use this element within either a receive choice activity or an event handler to create a control path that is executed when a specified time has either been reached or has elapsed. This element is used on a single path, and is configured to specify either a specific date, or period of time. When run, this path is chosen when no input is received within this time period, or by the specified date.
Set partner

Use this to select a partner to associate with this activity.
Timeout element Use this element within either a receive choice activity or an event handler to create a control path that is executed when a specified time has either been reached or has elapsed. This element is used on a single path, and is configured to specify either a specific date, or period of time. When run, this path is chosen when no input is received within this time period, or by the specified date.

Defining BPEL process logic

Related concepts:
Dealing with faults in your BPEL process
Work with XPath in the BPEL process editor
Work with micropatterns
Locked activities

Related tasks:
Adding an interface or a reference to a business state machine
Adding a variable to a business state machine
Adding a process application as an activity
Adding an activity to a BPEL process
Defining transactional behavior
Defining timer-driven behavior in a BPEL process
Enabling SCA events to be emitted
Calling other BPEL processes
Calling business services

Activity	Description
Invoke	Use this activity to call an operation on a specific partner. Operations can be either one-way (asynchronous) or request/response (synchronous).
Assign	Use this activity for basic data manipulation through the use of expressions, to map service endpoint references to or from partner links, or to copy some form of information from one part of your process to another. For example, it could be used to update the values of your variables or partner links.
Receive	This activity waits for a single external input, and channels it into the process.
Receive choice	This is a structured activity, in that it contains other activities that are organized onto individual control paths. It halts the process in order to wait for an operation to be called on it, and then follows the control path that is appropriate to the first message it receives. The first activity in that path, can be either a receive case element or a timeout element. The various inputs that a receive choice anticipates must be mutually exclusive, an example would be orders received for pick-up or delivery, a receive choice can route these two options to two different receive cases.
Reply	Use this activity in a synchronous (request/response) operation to return the output or fault to the partner that initiated the operation. This activity specifies the same partner implementation as the corresponding receive activity. A reply is always sent to the same partner from which a message was previously received
Wait	Use this activity to stop the process for a specified period of time. You configure this activity either by telling it how long it should hold up the process, or by specifying when it has waited long enough.
Empty action	Use this activity as an undefined object to act as a placeholder within your process. You might do this if you were designing a process that you expected somebody else to implement, or if you were trying to synchronize the activities within a parallel activity.
Snippet	Use this activity to compose visual expressions and Java™ code and thereby insert custom behavior into your process.
Data map	Use this activity to transform data between two variables.

Activity	Description
Scope	Use this activity to act as a behavioral container for one or more activities in your process. By definition, your process as a whole is contained within a single global scope, and you can nest other scopes within it, forming a hierarchy. A variable is visible only in the scope in which it is declared. If it is created in the global process scope then it is a global variable, and thus visible to the process as a whole. Those that are created within nested scopes can only be seen by objects within that scope. Each scope has a primary activity that defines its normal behavior, and you can associate a scope with fault, event or compensation handlers. You can also use a scope activity for enhanced dynamic behavior, by using an administrative human task to grant a user administrative privileges over the execution order of the activities that are nested within the scope. You can configure a scope in one of two ways: Choose isolated when you want to control simultaneous access to shared variables. Choose compensable if you want to allow compensation related activities on this scope. If this check box is clear, then this scope will be transparent to all compensation logic.
Parallel	Use this activity to nest other activities that will run concurrently. This is a structured activity, in that it contains other activities separated into individual control paths that are dictated by links and transition conditions. You can embed as many paths in the activity as you want, and they will all be executed simultaneously. This activity is equivalent to the concept of fork/join: all the paths within the activity are run simultaneously, and the target activity will not fire until all paths have completed.
Sequence	Use this structured activity to nest a series of activities into your process that will be run in the order in which they are placed. Execution returns to the BPEL process when the last activity within the nest has completed.
Choice	This is a structured activity, in that it contains other activities that are organized onto individual control paths. During execution, the choice activity evaluates the conditions on the paths in order, and follows the first one that evaluates to True. You can embed as many paths as you want, each containing one case element followed by any other activities that are necessary. If none of the control paths evaluate to true, then the otherwise path is chosen.
While loop	Use this structured activity to repeat one or more activities as long as specific success criteria or conditions are being met. If the condition that leads to the activity evaluates to false, then none of the activities within will be executed.
For Each	The For Each activity repeats the execution of the activities that it contains either sequentially or in parallel for a specified number of iterations. For an example of how to use a For Each activity, see the paper WS-BPEL 2.0 forEach activity - a typical usage pattern.
Generalized Flow	Use this activity to nest activities on individual, customized control paths. A generalized flow activity is very similar to a parallel activity in that you can control the execution order of those activities nested within it through links. The generalized flow activity differs however in its ability to use conditional links to loop back to previous activities in the sequence.

Activity	Description
Compensate	Use this activity within a scope's fault or compensation handler to invoke a specific compensation handler within the scope.
Throw	Use this activity to signal an internal fault. In defining the properties of this activity, you can specify a name and a message in the properties area of the BPEL process editor. These details can then be passed onto a fault handler that presumably is configured to deal with this kind of exception.
Rethrow	Use this activity to forward a fault from inside a fault handler to delegate the handling of a fault to an enclosing scope. The fault is sent to the enclosing scope exactly as it was caught by the fault handler, that is, any modifications of the associated fault data are ignored.
Terminate	Use this activity to halt the execution of a process. When used, all activities that are currently active are halted without any fault handling or compensation behavior. When the terminate activity has been invoked, its own fault handler is executed.

Activity	Description
Human Task	Use the human task activity to send a process-related task out to a human for completion. This activity is used in conjunction with the human task editor. Double-click an existing human task activity on the canvas to launch the human task editor.
Collaboration scope	Use a collaboration scope in situations where a BPEL process requires a well-defined procedure without a loss of operational flexibility. A collaboration scope is ideal when a BPEL process is knowledge-intensive and the end result can be expedited by allowing task owners to adapt the workflow to the current situation.

Element	Icon	Description
Case element		Used within a choice activity, this element is used to create a control path and define the conditions that will cause this path to run. During execution, the process will evaluate the conditions in each of the case elements, and follow the first one that evaluates to true.
Catch element		Use this element within a fault handler to intercept, and deal with a specific kind of fault. The catch element is always the first element on a fault handler's control path, and the activities that follow it are executed should the fault conditions you specify occur. You can catch a built-in fault type, or define one yourself. On the canvas, each catch shows the name of the fault type that it will catch, and each is associated with a variable.
Catch all element		Use this element within a fault handler to intercept, and deal with any fault that is not already defined in an existing catch element. The catch all element is the first object on a control path, and the activities the follow it are executed should the fault conditions you specify occur.
Compensation handler		Use the compensation handler on either an invoke or a scope activity, and within a long-running process to define logic that will run when a fault is thrown after the parent activity has already been committed. Compensation is used when the activity cannot simply be reversed or undone, but another operation must be executed in order to return the failed process to a balanced state.
Create a note		Use this tool to place a note anywhere on the canvas. You can then enter text into the body of the note to label specific parts of your BPEL process.
Event handler		Use the event handler to associate either a process or a scope activity with an external stimulus. They can respond to events that happen at any time during an application's lifetime, or as many times as those events repeat. There can be several paths within the handler, and they determine how the process should proceed based on the nature of the data received. Each path is preceded by either an OnEvent or a Timeout element.
Fault handler		A fault handler is a collection of specific activities that will run when a fault is thrown on the activity with which the handler is associated. Fault handlers can be used on both invoke and scope activities, and will run either when a fault is thrown by the invoke activity, or by an activity inside the scope activity. You can place activities on paths within the handler to either deal with anticipated faults, or attempt to find another way to complete the operation. Each path within the fault handler is preceded by either a catch, or a catch all element.
Link		Use the link within a parallel activity to connect nested activities and form individual control paths. The link is used to express a synchronization dependency. In other words, it is execution under constraint because the link creates a dependency of one activity and the variables it uses on another activity. You can specify a transition condition on the link in the properties area of the BPEL process editor.
Local variable		Click this to create a local variable that will be visible to all objects within the associated scope activity.
OnEvent element		Use this element within an event handler to create a control path and specify the operation that will cause this path to be executed.
Otherwise element		Use this element within a choice activity to to create a control path that will run when none of the other cases evaluate to true. Use this element on only one of the paths within a choice activity. When run, the process will evaluate the conditions in each of the case elements, and should none of them evaluate to true, it will run the activities in this path.
Receive case element		Use this element within a receive choice activity to create a control path and specify the operation that will run it. There is at least one receive case element path nested within a receive choice activity. When run, the process halts at the receive choice activity and listens for a message from its operations. The first message that comes in determines which path is executed.
Set compensate link		Use this element with a compensate activity to call a compensation handler on nested scopes.
Set partner		Use this to select a partner to associate with this activity.
Timeout element		Use this element within either a receive choice activity or an event handler to create a control path that is executed when a specified time has either been reached or has elapsed. This element is used on a single path, and is configured to specify either a specific date, or period of time. When run, this path is chosen when no input is received within this time period, or by the specified date.
Set partner		Use this to select a partner to associate with this activity.
Timeout element		Use this element within either a receive choice activity or an event handler to create a control path that is executed when a specified time has either been reached or has elapsed. This element is used on a single path, and is configured to specify either a specific date, or period of time. When run, this path is chosen when no input is received within this time period, or by the specified date.