SOA Suite 12c: BPEL Inline Sub Processes or locally Reusable Chunks of BPEL process logic

An in-line sub process can best be thought of as a callable scope. It is a scope that is not part of the normal process flow, but rather a unit of encapsulated logic that can be called zero, one or multiple times from anywhere within the BPEL process – even recursively from within itself. It is in effect very similar to a private member function in a Java Class or a procedure in the body of a PL/SQL package. Just like private member methods or functions help structuring a Java Class or PL/SQL package, so can subprocesses help organize a large BPEL process – even more than scopes already can.

An in-line sub process can define arguments to be passed in. These can be passed by reference, which means the sub process can alter their values as well. Additionally, the in-line sub process can access all global process variables. The in-line sub process is a scope which as such can define local variables and nested scopes, use partner links, have event handlers etcetera. At run-time, the subprocess code is re-entrant and re-usable – only one copy is stored in memory, even if it is called multiple times. However, on each call, it has a private scope for local and passed-by-value variables.

An in line sub process is created from a normal scope that is promoted using the context menu option Convert to sub process. At that time, at the location in the BPEL process where the scope used to be, a call to the sub process can be inserted. Later on, such calls can be added in other places as well. Of course the sub process can be further refined after its initial creation.

Note: In addition to the In-Line Sub Process, the BPEL component also supports stand-alone Sub Processes. These are defined in a separate file (with extension .sbpel) and appear as components in their own right in the composite overview. They can be called from multiple other BPEL components (but only from BPEL components). They cannot access global elements of these calling BPEL processes, unlike the in-line sub process. However, for every other intent and purpose, they act as if merged into the calling process. An important advantage of the stand-alone sub process, apart from its ability to be reused across multiple BPEL process components is the fact that because the sub process has its own definition file, developers can work in parallel on sub processes.

An in-line sub process can easily be created from a scope. Create for example a new scope called ReportError, somewhere in a BPEL process. Create or Copy an Assign activity (in the example called CopyValidationFaultToProcessingResults from the Fault handler on scope SchemaValidation) to the new scope ReportError.

Select the scope and click on the icon Convert to a Subprocess – or select that option from the context menu.

The dialog box appears to create the Inline Subprocess. Provide a name – such as ReportMessageToProcessingResults – and a label and comment (for documentation purposes)

Press OK to create the inline subprocess.

The scope ReportError has been replaced with a Call Activity that invokes the new sub process. In order to inspect and further edit the sub process, you have to select it in the dropdown list in the upper left hand corner, as shown in this screenshot.

Click on the global scope for the sub process. Next, click on the variables icon that displays as an x between parentheses: (x). Specify three variables for the sub process – for message code, message summary and description, each of type string.

Edit the Assign activity in the Sub Process. Take the values from the three [input] variables of the sub process to provide the values for the new ProcessResult element, as is shown here:

Set the flag insertMissingToData on each of the three copy rules, to have all elements in the nested XML structure specified in the target XPath expression constructed if they do not exist, instead of throwing a selectionFailure fault if the XPath expression does not return exactly one element.

Return to the main process and to the call activity that replaced the scope. Edit the call activity. Specify the values for the three input variables . See next figure for an example. Copy these values by value – because it is not our intention to have the sub process manipulate these values.

Next, copy the call activity and paste it at some other location in the BPEL process – to get a feeling for the reuse potential. In this example, it will call the sub process to report an incorrect length for the carrier element. Update the values passed to the sub process accordingly.

You may also want to use the call activity in the fault handlers in other scopes in the main BPEL process or in other in-line sub processes.