Generating an executable BPM from an executable BPM

Chapter 14 Generating Other Models from a BPM

Generating an executable BPM from an executable BPM

You can wish to generate an executable BPM from an executable BPM for the following reasons:

Generation type	Usage
SOA > Orchestrator or BPEL languages	You use SOA process language when you want to design Web services orchestration independently from any platform. You choose one of the other provided executable process languages (Orchestrator or one of the BPEL languages) when you want to execute your processes and customize parameters specific to the platform
BPEL languages > Orchestrator	BPEL languages are a standard exchange format. PowerDesigner allows you to reverse a BPEL file into a BPEL BPM then generate an Orchestrator BPM that can be executed in Sybase Unwired Orchestrator application
Orchestrator > BPEL languages	A Sybase Unwired Orchestrator application user may want to share its executable BPM using BPEL language standard format

Most of the time you will perform the following types of generation:

The generation of a Sybase Unwired Orchestrator BPM from a reversed BPEL file
The generation of a Sybase Unwired Orchestrator BPM or BPEL BPM from an SOA BPM

Change target from BPEL4WS 1.1 to WS-BPEL 2.0
If you need to change target from BPEL4WS 1.1 to WS-BPEL 2.0, note that the top-level compensation handler is removed and the "variableAccessSerializable" extended attribute in scopes and top level process is replaced with "isolated" extended attribute.

The following transformations are executed when you generate a Sybase Unwired Orchestrator BPM from an executable BPM (SOA or one of the BPEL languages). The general rule being to preserve the processes semantic and to update operations.

Automatic invoke mode

Orchestrator supports an automatic invoke mode that implies the following:

Operation	Type
Received operation	Notify or Solicit-Response
Sent operation	One-Way or Request-Response

When you change process language from SOA or one of the BPEL languages to Orchestrator, you need to preserve the process action types (send or receive) by modifying the operation types:

When a received operation in the source model is of type One-Way or a Request-Response it becomes a Notification or Solicit-Response operation in Orchestrator.

When a sent operation in the source model is of type Notification or Solicit-Response it becomes a One-Way or a Request-Response operation in Orchestrator.

When the same type of operation is both received and sent in the same source model it is duplicated in Orchestrator.

Supported operation types

Each language can restrict the type of operations that can be attached to a process. When you switch from an executable process language to another, the list of supported operation types can be different.

When the target language does not support a Solicit-Response or a Request-Response operation type, the synchronous operation (that has both input and output messages) is split into two operations: one managing the input message and the other managing the output message. The send of fault messages is also replaced with specific One-Way or Notification operations associated with the fault message.

For example, Orchestrator does not support Solicit-Response operations that represent the reception of a message with a synchronous response (the caller is expecting that the process respond in a limited time). Such an operation is designed in the BPEL languages using one of the following action types: "Receive Request", "Reply" and "Reply Fault".

After generating the Orchestrator BPM:

The "Receive Request" processes are associated with a Notification operation that has the input message of the initial operation as output message.

The "Reply" processes are associated with a One-Way operation that has the output message of the initial operation as input message.

The "Reply Fault" processes are associated with a new One-Way operation that will have the fault message as input message.

Default graph for top-level processes

For all executable languages that support top-level choreography and do not support the role association object, the top-level diagram must be a valid graph with at least a start and an end.

When generating for example from one of the BPEL languages or ebXML to Orchestrator, each top-level process must be converted into a simple graph containing a start, a process and an end:

If you create top-level processes in an Analysis BPM, they are also converted into a valid graph during Orchestrator generation, if they respect all of the following rules:

The process must be attached to a model or a package and must not have any incoming or outgoing flows
The role association object must not be supported in the target language
Top-level choreographies must be allowed

In case of multiple top-level processes, they must all be associated with the same start and end objects:

Packages

Packages are used to organize sets of processes. However in Orchestrator, the model can contain only one process. When generating to Orchestrator packages are not preserved, and only objects defined under the model are generated.