This chapter includes the following sections:
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
A complete SOA project packaged and used to start new projects. You can create new SOA composite applications using this template.
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.
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 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.
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|
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.
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>
<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:
<subProcess> activity must be embedded in an
<extensionActivity>, as specified in section 10.9 of the .
A subprocess is of type
tProcess, as defined in the following WS-BPEL target namespace:
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 attribute
yes (the default value is
no). 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 to
yes. This is because no instance of a given subprocess type is created; the subprocess is logically part of an existing process instance.
/@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.
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
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.
When determining whether templates or reusable subprocesses are the best solution for your business use case, it is important to understand the differences:
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.
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.
You can create the following types of templates:
Custom BPEL scope activity
For conceptual information about templates, see Introduction to Templates and Differences Between Oracle SOA Suite Templates and Reusable Subprocesses.
This section describes how to create and use a SOA project as a template.
Use of templates is not supported in the Oracle JDeveloper Customization role.
To create a SOA project template:
The project name
This invokes the Create SOA Template wizard. Default names and the location for saving the template based on the composite name are automatically included. Figure 39-1 provides details.
Figure 39-1 Create SOA Template Wizard - Specify Template Information Page
The Create SOA Template Wizard - Files to Bundle page is displayed. Figure 39-2 provides details. This page shows all the files packaged as part of this template.
You can also manually select measurements (business indicators) and test suites to include. If your composite includes domain value maps (DVMs) (for example, a DVM function is referenced in a BPEL scope activity), they are also included in the template.
Figure 39-2 Create SOA Template Wizard - Files to Bundle Page
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
Figure 39-3 Custom Template Selection
The list of available templates is displayed. Figure 39-4 provides details.
Figure 39-4 SOA Templates Available for Selection
The SOA Composite Editor is displayed with the custom template. The files of the template are displayed in the Applications window.
You can rename components as necessary, such as renaming the binding components and process names.
This section describes how to create and use a service component template.
To create a service component template:
This launches the Create Component Template wizard.
Figure 39-5 Create Component Template Wizard - Specify Template Information Page
The Create Component Template wizard - Files to Bundle Page is displayed.
The service component template is added to the Component Templates section of the Components window. Figure 39-6 provides details.
Figure 39-6 Service Component Template in Component Templates Section of Components Window
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:
Figure 39-7 SOA Templates Option in SOA Menu
This invokes the Create SOA Component from Component Template dialog, as shown in Figure 39-8. This dialog shows the template name, description, and files included in the template.
Figure 39-8 Create SOA Component from Component Template Dialog
The service component template is displayed in the SOA composite application.
Figure 39-9 Create SOA Component from Component Template Dialog
Figure 39-10 File Names in Conflict
This section describes how to create and use 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.
Expand the scope and select Create Custom Activity Template, as shown in Figure 39-11.
Figure 39-11 Scope Template Creation
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
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
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.
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.
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.
Figure 39-14 Scope Activity Template
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
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
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
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.
Figure 39-18 Bind to New Variable Dialog
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.
If a scope uses partner links, the Create Custom Activity Template Wizard - Partner Links Page is displayed.
You can manage all available template types from the Preferences dialog.
To manage templates:
The Preference dialog is displayed, as shown in Figure 39-19.
Figure 39-19 SOA Template Preferences
Templates can be stored in two locations:
Folders: Templates are stored in the file system.
SOA-MDS: Templates are stored in the MDS Repository and can be shared.
Figure 39-20 Management Tasks
Table 39-3 describes the management tasks you can perform.
Table 39-3 Template Management Tasks
Browses for a specific template name.
The Browse option uses Windows Explorer on Windows or the file browser on Linux for the storage folder. Templates are stored as files, so you may want to operate with them as with files (that is, upload with FTP, send by email, copy to another folder to back up, and so on).
Refreshes the list of templates.
Adds existing templates to the Preferences - SOA Templates dialog.
Deletes the folder and its templates only from the Preferences - SOA Templates dialog. The templates are not physically deleted from the file system or MDS Repository. You can add them to this dialog again by selecting Add Storage or clicking the Add icon. The template context menu contains a Delete option that physically deletes a template.
Displays all templates.
Displays only SOA project templates.
Displays only service component templates.
Displays only BPEL scope activity templates.
/integration/templatesdirectory, select File > Import > SOA Template. The file can then be added to the Preferences dialog by clicking the Add icon or right-clicking a folder and selecting Add Storage.
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.
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
This section provides an example of how to create a simple application that uses a standalone subprocess.
A standalone subprocess can include an inline subprocess.
To create a standalone BPEL subprocess:
A variable of type string is created (for this example, named
variable1) to pass in as a parameter.
An assign activity is created in which the client input string is mapped to
Figure 39-21 shows the BPEL process design.
Figure 39-21 BPEL 2.0 Process Design
The Create Subprocess dialog is displayed.
Figure 39-22 Create Subprocess Dialog
You now design simple process logic in the standalone subprocess.
This invokes the Edit Call dialog. Note that variable p1 is displayed in the Name column after the selected Subprocess1.
Leaving this check box deselected copies the variable by reference. Only variables or partner links are accepted for variables, not XPath function queries. Copy by reference supports both input and output variables. Copy by value supports only input values.
Figure 39-23 Edit Assign Dialog
Figure 39-24 shows the BPEL 2.0 process with the subprocess. In this BPEL 2.0 process, the following logic is designed:
The string value in the input message in Assign1 is taken and assigned to variable1 in the call activity, to be passed by reference.
assign2 takes variable1 and creates the response. The variable1 value is updated by the subprocess.
Figure 39-24 BPEL 2.0 Process
You are now ready to deploy the SOA composite application and create a business flow instance in Oracle Enterprise Manager Fusion Middleware Control.
When you access the audit trail for the created business flow instance in Oracle Enterprise Manager Fusion Middleware Control, note that the call activity and its contents are displayed.
For more information about standalone BPEL subprocesses, see Section "Using Templates and Standalone Subprocesses to Update the Order Status in the Database" of Understanding Oracle SOA Suite.
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.
Creating an inline subprocess within an existing inline subprocess is not supported.
To create an inline subprocess:
Inline subprocesses can also be created in a BPEL process by selecting Inline Subprocesses from the Property Structure menu above Oracle BPEL Designer, selecting the Inline Subprocesses folder, and clicking Add.
Figure 39-25 Scope Activity
The Create Inline Subprocess dialog is displayed, as shown in Figure 39-26.
Figure 39-26 Create Inline Subprocess Dialog
Table 39-4 Create Inline Subprocess Dialog
Enter a name or accept the default value, which defaults to the scope name.
Replace scope with subprocess call
Select to automatically replace the scope with a BPEL call activity (the default selection). If you want to create an inline subprocess and keep the selected scope in the process, you can deselect this check box.
Optionally enter a description.
Optimally enter a comment.
Select to replace the standard call activity icon with a unique image.
The scope activity is converted to a call activity in the BPEL 2.0 process, as shown in Figure 39-27.
Figure 39-27 Call Activity
The new inline subprocess is also displayed in the Subprocess section of the Components window. Figure 39-28 provides details.
Figure 39-28 Inline Subprocess in Components Window
Figure 39-29 Subprocess Selection Above Oracle BPEL Designer
The contents of the inline subprocess are displayed. Figure 39-30 provides details.
Figure 39-30 Inline Subprocess Contents
You can add the subprocess to the same BPEL 2.0 process, as necessary.
Figure 39-31 Subprocess Added to Same BPEL 2.0 Process
The subprocess name is automatically changed to Callnumber as shown in Figure 39-32.
Figure 39-32 Subprocess Name Changed
For more information about using inline BPEL subprocesses, see Section "Updating Order Status with an Inline BPEL Subprocess" of Understanding Oracle SOA Suite.
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:
The Create Subprocess dialog is displayed.
Subprocess1), and click OK.
You now create a second process to use as the partner link.
BPELProcess2). This is the process to call.
Figure 39-33 Edit Assign Dialog
string("hello from process2")
Figure 39-34 Partner Link Creation
The Partner Links dialog is displayed.
The Create Partner Link dialog is displayed. You now define this partner link as a parameter.
PartnerLink1), and click OK. Figure 39-35 provides details. The role of the partner link is as the provider.
Figure 39-35 Partner Link Creation
The Partner Links dialog looks as shown in Figure 39-36.
Figure 39-36 Partner Links Dialog
Figure 39-37 shows the contents of the subprocess.
Figure 39-37 Subprocess Contents
Figure 39-38 Request and Response Message Type Variable Creation
The Variables dialog is displayed.
Figure 39-41 Edit Assign Activity
Subprocess design is now complete.
Figure 39-42 Variables Dialog
Figure 39-43 Subprocess Added to Main BPEL 2.0 Process
Figure 39-44 Create Partner Link Dialog
The Edit Call dialog shows the partner link created earlier in the subprocess.
Figure 39-45 Edit Call Dialog
Figure 39-46 Edit Assign Dialog
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: