39 Oracle SOA Suite Templates and Reusable Subprocesses
This chapter includes the following sections:
39.1 Introduction to Oracle SOA Suite Templates
A template is a reusable part of an Oracle SOA Suite project that you can use to create new projects. There are three types of templates, as described in Table 39-1.
Table 39-1 Template Types
Template Type | Description |
---|---|
SOA project |
A complete SOA project packaged and used to start new projects. You can create new SOA composite applications using this template. |
Service component |
A service component, such as a BPEL 2.0 process (including sensors) packaged for import into other projects. All dependent components and wires are also packaged. It appears as a custom service component in the SOA composite application's Components window. |
Custom BPEL scope activity |
A scope activity of a BPEL process packaged as a custom activity in the Components window and ready for import into other BPEL projects. This custom activity can potentially surface in the BPEL activity palette of the Components window. |
Oracle SOA Suite templates provide the following benefits:
-
Share common code (subpart of a process or a scope) between applications, composites, and processes. You create once, then share with others. The template can be reused multiple times.
-
Store and reuse templates from the Oracle Metadata Services Repository (MDS Repository).
-
Fully editable upon consumption.
-
Automatically discover templates in Oracle JDeveloper. Once the template is saved, it is displayed in the Components window.
-
No inheritance, meaning that future changes to source templates are not visible to applications. If you make changes to the source template, a current user of the template does not see the change.
-
Custom icons are provided for component scope templates.
-
No versioning in templates. To differentiate between versions, you specify the version number in the template name.
-
Support for templates in both the BPEL versions 1.1 and 2.0.
Changes made to a specific template are not propagated to projects previously created using this template. This functionality is achievable through layered customization.
A new annotation is added to the composites/BPEL processes to identify the relationship to a template.
For information about using templates, see Creating and Using a SOA Project Template, Creating and Using a Service Component Template, and Creating and Using a BPEL Scope Activity Template.
39.2 Introduction to Standalone and Inline BPEL Subprocess Invocations
BPEL provides limited support for modularizing business process logic for reusability. The only method is to package reusable process logic as completely separate processes, which are utilized by the parent process (the process utilizing the reusable process logic) in a method identical to using a web service (through the invoke activity).
To address this challenge, Oracle SOA Suite provides a subprocess extension to BPEL. A subprocess is a fragment of BPEL code that can be reused within a particular processor by separate processes. The subprocess extension provides the following benefits:
-
BPEL process code reusability, which reduces the need to create the same activities multiple times to perform the same tasks.
-
Code modularity.
-
Code maintenance (changes are propagated, which eliminates the need to implement updates in multiple places every time a change is necessary).
-
Less overhead than invoke activities.
-
Memory footprint reduction, which can be considerable in a complex process.
Note:
-
Subprocesses are only supported with BPEL version 2.0. There is no support with BPEL version 1.1.
-
Correlation sets are not supported in subprocesses. If you create a correlation set in an inline or standalone subprocess, it fails during runtime.
-
Subprocesses cannot be shared between multiple composites.
-
Monitor view is not supported from inside a subprocess. Monitor view is accessible from a BPEL process by selecting the Change to Monitor view icon above Oracle BPEL Designer.
Oracle SOA Suite provides support for two types of subprocesses, as described in Table 39-2.
Table 39-2 Subprocess Types
Standalone Subprocess | Inline Subprocess |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Not Applicable. |
|
For information about creating a standalone subprocess, see How to Create a Standalone BPEL Subprocess. |
For information about creating an inline subprocess, see How to Create an Inline Subprocess. |
39.2.1 Introduction to a Standalone Subprocess
A standalone subprocess is defined, as shown in the following example, in a file with the extension .sbpel
(subprocess BPEL extension).
<!-- A subprocess is defined in a SBPEL file, containing a bpelx:subProcess ! document ! The bpelx:subProcess is similar to a standard bpel:process, with ! differences asnoted below. --> <bpelx:subProcess name="NCName" targetNamespace="anyURI" xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:bpelx="http://schemas.oracle.com/bpel/extension" ...> <!-- Partner links and variables serve as sub-process arguments --> <partnerLinks>? <partnerLink name="NCName" partnerLinkType="QName" myRole="NCName"? partnerRole="NCName"? bpelx:argumentRequired=["yes"|"no"]? /> <partnerLinks> <variables>? <variable name="BPELVariableName" messageType="QName"? type="QName"? element="QName"? bpelx:argumentRequired=["yes"|"no"]?> from-spec? </variable> </variables> <!-- Standard process definition here, except no <receive> or <pick> with --> <!-- createInstance="yes" --> /activity/ </bpelx:subProcess>
The <subProcess>
element is an extension of the WS-BPEL 2.0 language. The <subProcess>
element is the root element for a subprocess definition. The namespace for this element is as follows:
http://schemas.oracle.com/bpel/extension
The <subProcess>
activity must be embedded in an <extensionActivity>
, as specified in section 10.9 of the Web Services Business Process Execution
Language Specification Version 2.0.
A subprocess is of type tProcess
, as defined in the following WS-BPEL target namespace:
http://docs.oasis-open.org/wsbpel/2.0/process/executable
It differs from tProcess
in the following ways:
-
Variables and partner links immediately under the
<subProcess>
element can serve as arguments for the subprocess. Required arguments are marked by setting the attributeargumentRequired
toyes
(the default value isno
). The subprocess's required arguments are the minimum set of arguments the caller must pass to it. -
A variable defined with an inline
from-spec
initializer serves as an optional argument with a default value. If the caller passes this argument, the caller-supplied value for the argument overrides the default value. -
Validation reports an error if a variable is referenced prior to setting the value if it is not a required argument.
-
The first activity in the subprocess cannot be a receive or pick activity with
createInstance
set toyes
. This is because no instance of a given subprocess type is created; the subprocess is logically part of an existing process instance.
The subprocess /@name
attribute defines the name of the subprocess that is unique within the composite in which it is deployed.
The subprocess is self-contained. That is, all the variable and partner link references in the process snippet resolve to local definitions or arguments. This contrasts with the <inlineSubProcess>
element, which allows unresolved references to variables and partner links that are in-scope at the call activity.
In a typical scenario, more than one variable is exchanged between the parent and a subprocess. If they are large documents, copying them is expensive. Because of this, passing by reference is an option.
A subprocess can converse with partners synchronously (InOut
) or asynchronously (InOnly
). The partner link for these interactions can be passed as an argument from a parent process or configured within the subprocess. For asynchronous requests, the conversation ID for WS-Addressing/normalized messages is set with the parent process instance ID. This enables routing of callback messages to the correct process instance.
Subprocesses in a SOA composite application are enumerated in the composite.xml
file. The component element definition associates a subprocess's name with the sbpel
file in which it is defined. During deployment, the subprocess components are delegated to the BPEL process service engine. The BPEL process service engine validates the process definition and builds a map with the subprocess target name as the key and the subprocess definition as the value. At most, only one instance of a subprocess exists in the service engine independent of consumer count. For optimizing memory, it may lazily load the process or unload the process if it is not actively used.
For information about creating a standalone subprocess, see How to Create a Standalone BPEL Subprocess.
39.2.2 Introduction to an Inline Subprocess
An inline subprocess can be defined as part of a BPEL 2.0 process at the <process>
level. The syntax is shown in the following example:
<process name="NCName" targetNamespace="anyURI" xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" ...> <!-- ! All sub-process definitions must appear prior to the WS-BPEL artifacts of ! the process definition. --> <!-- Inline sub-process definition at process scope --> <bpelx:inlineSubProcess xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="NCName">* ... <!-- Partner links and variables serve as sub-process arguments --> <partnerLinks>? <partnerLink name="NCName" partnerLinkType="QName" myRole="NCName"? partnerRole="NCName"? bpelx:argumentRequired=["yes"|"no"]? />+ <partnerLinks> ... <variables>? <variable name="BPELVariableName" messageType="QName"? type="QName"? element="QName"? bpelx:argumentRequired=["yes"|"no"]?>+ from-spec? </variable> </variables> ... <!-- ! Standard process activity graph here, except that no <receive> or <pick> ! activities with createInstance = "yes" are allowed. --> activity </bpelx:inlineSubprocess> <!-- ! BPEL code stripped for brevity --> </process>
When a BPEL process instance is first created, all subprocess references are resolved. When the process executes a particular call activity, it uses the subprocess resolved at instance creation time. Therefore, two different instances of the same process may use different versions of subprocesses referenced if, for example, the default composite revision for a subprocess changes.
When the BPEL process instance executes the call activity, it is executed within the process's execution space, sharing its state. The call activity transfers control to the subprocess, at which time the subprocess scope is initialized with the argument variables:
-
Each parameter is copied (by reference or value, as specified) from the call activity to the subprocess's scope.
-
Optional parameters (those with default values) that are not referred to in the call activity's parameter list are initialized with their default values.
-
All required parameters must be supplied by the call activity.
-
All values supplied by the call activity's parameters must be type-compatible with the corresponding variable (or partner link) defined in the subprocess.
-
Each variable (or partner link) in the subprocess can be set only once in a call activity's parameter list.
On completion of the subprocess, control is returned to the parent process. In the normal case, execution continues with the next activity after the call activity. In the case of abnormal subprocess completion, the parent process evolves the process according to the standard life cycle rules of WS-BPEL.
From the monitoring and management view, there is no new process instance for the subprocess created. It is represented by a call activity in the parent process instance. Expanding the activity (navigate) shows subprocess execution details.
To minimize linking errors during runtime, upon deployment of the process and subprocess, references are resolved. Parameter lists are validated as a postdeployment activity. Preprocessing for creating a new process instance validates all subprocess references in the process. If any reference is not resolved, the instance is not created. Instead, an error message is returned, meaning essentially the following:
HTTP Status Code 503, "service not available
Upon a linking error, if the service consumer is waiting, an error message is sent to the consumer that is inline with exit activity handling. Otherwise, the instance is suspended with the reason set as linkage
error
. If a suitable subprocess is deployed and the reference is resolvable, suspended instances can then be recovered and resume normal execution by automatic recovery.
For information about creating an inline subprocess, see How to Create an Inline Subprocess.
39.3 Differences Between Oracle SOA Suite Templates and Reusable Subprocesses
When determining whether templates or reusable subprocesses are the best solution for your business use case, it is important to understand the differences:
-
Templates
A template is a customizable, skeletal project, service component, or scope activity. You can drag and drop a template into a SOA composite application or a BPEL process and make additional changes. You essentially are copying and pasting a template. For example, if there are 50 lines of code in a template and you copy it twice to use, the code increases by 100 lines.
-
Reusable subprocesses
A subprocess is a BPEL code snippet intended for a specific purpose. A subprocess that is defined earlier can be called and used as it is. An inline subprocess of 50 lines can be called twice and the parent process code remains at 50 lines, and not 100. Subprocesses perform better and have a smaller memory foot print than templates.
39.4 Creating Oracle SOA Suite Templates
You can create the following types of templates:
-
SOA project
-
Service component
-
Custom BPEL scope activity
For conceptual information about templates, see Introduction to Templates and Differences Between Oracle SOA Suite Templates and Reusable Subprocesses.
39.4.1 Creating and Using a SOA Project Template
This section describes how to create and use a SOA project as a template.
Note:
Use of templates is not supported in the Oracle JDeveloper Customization role.
39.4.1.2 How to Use a Composite Template in Another SOA Composite
This section describes how to use the composite template created in How To Create a SOA Project Template in another SOA composite application.
To use a composite template in another SOA composite
39.4.2 Creating and Using a Service Component Template
This section describes how to create and use a service component template.
39.4.2.2 How to Use a Service Component Template in Another SOA Composite
This section describes how to use the packaged service component template created in How to Create a Service Component Template in another SOA composite application.
To use a service component template in another SOA composite:
39.4.3 Creating and Using a BPEL Scope Activity Template
This section describes how to create and use a BPEL scope activity template.
39.4.3.1 How to Create a BPEL Scope Activity Template
To create a BPEL scope activity template:
-
In Oracle BPEL Designer, drag a scope activity into a BPEL process.
-
Design the contents of the scope activity to include activities, event handlers, and catch and catch all branches that include fault variables, as necessary.
-
Create a template from the scope.
-
Right-click the scope and select Create Custom Activity Template.
or
-
Expand the scope and select Create Custom Activity Template, as shown in Figure 39-11.
The Create Custom Activity Template wizard - Specify Template Information page is displayed, as shown in Figure 39-12.
Figure 39-12 Create Custom Activity Template Wizard - Specify Template Information Page
Description of "Figure 39-12 Create Custom Activity Template Wizard - Specify Template Information Page" -
-
Specify details, and click Next.
The Create Custom Activity Template wizard - Variables page is displayed. Figure 39-13 provides details. This page is displayed if variables are used in the scope. This page is not displayed if you have an empty scope or a scope that does not use variables.
Figure 39-13 Create Custom Activity Template Wizard - Variable Page
Description of "Figure 39-13 Create Custom Activity Template Wizard - Variable Page" -
Select to convert your variables to local variables. This conversion is not recommended if this variable is used outside of the scope activity in receive and reply activities. If the variables are used only inside this scope, the check boxes are selected by default.
-
Enter an optional description of the variables, and click Next.
The Create Custom Activity Template wizard - Files to Bundle page is displayed as shown previously in Figure 39-2. This page shows all the files packaged as part of this template. You can also manually select test suites to include.
-
Select files, and click Finish.
39.4.3.2 How to Use a BPEL Scope Activity Template in Another BPEL Process
This section describes how to use a BPEL scope activity template in another BPEL process.
To use a BPEL scope activity template in another BPEL process
-
Create a new or open an existing BPEL process.
-
From the Custom Activity Templates section in the Components window, drag the scope activity template created in How to Create a BPEL Scope Activity Template into the BPEL process. Figure 39-14 provides details.
Note:
Only scope activity templates that are compatible with the BPEL service component version are available. For example, if this is a BPEL 2.0 service component, only scope activity templates for BPEL 2.0 are available for selection. No BPEL version 1.1 scope activity templates are displayed.
Any error handling you designed such as catch and catch all activities and any scope variables you created are also copied into the BPEL process.
The Create Custom Activity from Template page is displayed, as shown in Figure 39-15.
Figure 39-15 Create Custom Activity from Template Wizard
Description of "Figure 39-15 Create Custom Activity from Template Wizard" -
Click Next.
If there are conflicts, the Create Custom Activity from Template wizard - Resolve Conflicts page is displayed, as shown in Figure 39-16.
Figure 39-16 Create Custom Activity from Template Wizard - Resolve Conflicts Page
Description of "Figure 39-16 Create Custom Activity from Template Wizard - Resolve Conflicts Page" -
Select to skip all or individual file conflicts, and click Next.
The Create Custom Activity from Template wizard - Variables page is displayed, as shown in Figure 39-17.
If you selected to convert your variables to local variables on the Create Custom Activity Template Wizard - Variable Page in Step 5 of How to Create a BPEL Scope Activity Template, they do not require special processing and are not displayed on this page. Only variables that were not converted to local variables are displayed on the Create Custom Activity from Template wizard - Variable Bindings page.
Figure 39-17 Create Custom Activity from Template wizard - Variable Bindings Page
Description of "Figure 39-17 Create Custom Activity from Template wizard - Variable Bindings Page" -
If the template and the project both include this variable, you can choose to reuse the variable or bind to a new variable from the list in the BPEL Variable column.
-
If you selected to bind to a new variable, enter a name and select whether to create the variable locally for the template scope or globally for the BPEL process, then click OK. Figure 39-18 provides details.
If you drop an activity template inside of Scope A that is inside of Scope B, then Scope A and Scope B also are in the list. This enables you to select among all locations where variables can be declared.
-
-
Click Next.
-
If a scope uses partner links, the Create Custom Activity Template Wizard - Partner Links Page is displayed.
-
Click Finish.
39.5 Creating Standalone and Inline BPEL Subprocesses in a BPEL Process
You can create standalone subprocesses in a SOA composite and inline BPEL subprocesses in a BPEL process. A subprocess is a fragment of BPEL code that can be reused within a particular processor by separate processes.
For conceptual information about subprocesses, see Introduction to Standalone and Inline BPEL Subprocess Invocations and Differences Between Oracle SOA Suite Templates and Reusable Subprocesses.
Note:
-
There is no restriction on one BPEL subprocess calling itself recursively. You must determine if you want to recursively call the same BPEL subprocess and the number of times the subprocess calls occur.
-
You can create and successfully deploy a SOA composite application that contains only a standalone subprocess. For example, create a SOA composite application and add a standalone subprocess in which you define two parameters for the subprocess and define an assign activity in the subprocess to swap the values of both parameters. However, while a SOA composite application that contains only a standalone subprocess and no other components can be deployed, it has no practical purpose.
-
A standalone subprocess cannot be shared in the MDS Repository. However, a BPEL process with call activities for calling the subprocess can be shared in the MDS Repository
39.5.1 How to Create a Standalone BPEL Subprocess
This section provides an example of how to create a simple application that uses a standalone subprocess.
Note:
A standalone subprocess can include an inline subprocess.
To create a standalone BPEL subprocess:
39.5.2 How to Create an Inline Subprocess
An inline subprocess is similar to a standalone subprocess, except that the inline subprocess is embedded in the parent process. For example, you may have a BPEL 2.0 process that includes assign and invoke activities within a scope activity that update the status of a customer order. You may have a business need for repeating these same activities later in the same process. One method is to physically repeat the same assign and invoke activities of the scope activity later in the process, but this can be error prone. In addition, every time a change is necessary, it must be implemented in both scopes. As an alternative to repeating the activities, you can use an inline subprocess.
Note:
Creating an inline subprocess within an existing inline subprocess is not supported.
To create an inline subprocess:
For more information about using inline BPEL subprocesses, see Section "Updating Order Status with an Inline BPEL Subprocess" of Understanding Oracle SOA Suite.
39.5.3 How to Create a Standalone Subprocess that Takes a Partner Link as a Parameter
This section describes how a subprocess takes a partner link as a parameter and uses it to call the partner and return the result. You are essentially using a partner link from subprocess to subprocess.
To create a standalone subprocess that takes a partner link as a parameter:
39.5.4 What You May Need to Know About Renaming a Subprocess
When you rename a subprocess, it is not updated in the invoking call activity. You must manually update the subprocess name in the call activity.
Assume you perform the following steps:
- Create an asynchronous BPEL 2.0 process.
- Right-click the SOA Composite Editor, and select Insert > Subprocess.
- Create a subprocess named SubProcessNew.
- Right-click SubProcessNew, and click Edit.
- From the Components window, drag an Empty activity into the subprocess.
- Open the asynchronous BPEL 2.0 process.
- From the Components window, drag a Call activity into the process.
- Invoke the SubProcessNew subprocess from the call activity.
- Return to the SOA Composite Editor, and rename the SubProcessNew subprocess to SubProcessRenamed.
- Open the call activity in the asynchronous BPEL 2.0 process, and note that the Subprocess field is now empty.
- In the Subprocess field, manually enter the updated name of SubProcessRenamed.