To illustrate further, assume you have an application that performs multichannel banking using various processes. In this scenario, the execution of each process depends on the channel for each particular process instance.
This chapter includes the following sections:
Two-layer BPM enables you to model business processes using a layered approach. In that model, a first level is a very abstract specification of the business process. Activities of a first-level process delegate the work to processes or services in a second level. Figure 54-1 illustrates this behavior.
Figure 54-1 Two-Layer BPM
In Figure 54-1, the phase I activity of the business process can delegate its work to one of the corresponding layer II processes: Task 1.1, Task 1.2, or Task 1.3.
The two-layer BPM functionality enables you to create the key element (namely, the phase activity) declaratively.
By using the design time and runtime functionality of Oracle Business Rules, you can add more channels dynamically without having to redeploy the business process. Design time at runtime enables you to add rules (columns) to the dynamic routing decision table at runtime. Then, during runtime, business process instances consider those new rules and eventually route the requests to a different channel.
The design time at runtime functionality of Oracle Business Rules also enables you to modify the endpoint reference of a service that is invoked from a phase activity, pointing that reference to a different service.
You can use the design time at runtime functionality of Oracle Business Rules through Oracle SOA Composer and the Oracle Business Rules SDK.
For information about using Oracle SOA Composer and the Oracle Business Rules SDK, see:
In two-layer BPM, a phase is a level-1 activity in the BPEL process. It complements the existing higher-level Oracle Business Rules and human task BPEL activities.
You add a phase activity to a process declaratively in Oracle BPEL Designer by dragging and dropping it from the Oracle Extensions section of the Components window to the process model. Figure 54-2 provides details.
Figure 54-2 Phase Activity in Oracle BPEL Designer
The reference WSDL (layer 2 or called references) must have the same abstract WSDL as that for the phase reference that gets automatically created.
You create the phase activity for your composite application after you have created the necessary variables.
To create a phase activity:
composite.xmlfile) above Oracle BPEL Designer. The SOA Composite Editor appears.
When you create a phase activity, the artifacts described in Table 54-1 are created.
Table 54-1 Artifacts Created with a Phase Activity
At the location where the user dropped the phase activity in the BPEL process, a new BPEL scope is created and inserted into the BPEL process. The scope has the name of the phase activity. Within the scope, several standard BPEL activities are created. The most important ones are one invoke activity to an Oracle Mediator and one receive activity from the Oracle Mediator.
Oracle Mediator component
With the SOA composite application of the BPEL process service component, a new Oracle Mediator service component is created. The Oracle Mediator service component is wired to the phase activity of the BPEL component that comprises the level-1 BPEL process where the phase activity has been dropped into the process model. The input and output of the Oracle Mediator service component is defined by the input and output of the phase activity.
The Oracle Mediator plan (the processing instructions of the Oracle Mediator service component) is very simple; it delegates creation of the processing instructions to the Oracle Business Rules service component.
Oracle Business Rules component
Within the SOA composite application of the BPEL process service component, a new Oracle Business Rules service component is created and wired to the Oracle Mediator component associated with the phase activity of the BPEL process service component. The Oracle Business Rules service component includes a rule dictionary. The rule dictionary contains metadata for such Oracle Business Rules engine artifacts as fact types, rulesets, rules, decision tables, and similar artifacts. As part of creating the Oracle Business Rules service component, the rule dictionary is preinitialized with the following data:
At runtime, the input of the phase activity is used to evaluate the dynamic routing decision table. This is performed by a specific decision component of the phase activity. The result of this evaluation is an instruction for the Oracle Mediator. The Oracle Mediator routes the request to a service based on instructions from the decision component.
In the current release, an asynchronous phase activity is supported. A synchronous or one-way phase activity is not supported.
When creating a phase activity, you must know the following:
Rules that you must either configure or create in the decision service. This is based on data from the payload that you use to evaluate a rule.
For each rule created in the decision service, you must know the corresponding endpoint URL that must be invoked when a rule evaluates to true. This endpoint URL is used by the Oracle Mediator to invoke the service in layer 2.
No transformation, assignment, or validation can be performed on a payload.
A Dynamic Routing Decision Table is a decision table evaluated by Oracle Business Rules. Conditions are evaluated on the input data of a phase activity. The result of the evaluation is a routing instruction for the Oracle Mediator.
After you have created the phase activity, the wizard launches the Oracle Business Rules Designer in Oracle JDeveloper for you to edit the Dynamic Routing Decision Table. Figure 54-3 shows a sample decision table within the Oracle Business Rules Designer.
Figure 54-3 Sample Decision Table
You can leave the information empty while modeling the level-2 process phases and complete it after the level-1 process is being deployed using Oracle SOA Composer.
Once you have created and edited the Dynamic Routing Decision Table, the new level-1 phase activity appears in the BPEL process in Oracle JDeveloper, as shown in Figure 54-4.
Figure 54-4 Completed Level-1 Phase in Oracle JDeveloper
By creating the Dynamic Routing Decision Table, you are configuring the decision service to dynamically evaluate the conditions applied to the incoming payload and give the corresponding routing rules to Oracle Mediator. Oracle Mediator then executes these rules when invoking the service in layer 2.
More specifically, here is what happens at design time when you create the Dynamic Routing Decision Table:
A new decision component is created in the composite of the project.
A new rule dictionary is created in the composite project directory.
The rule dictionary is populated with a data model that reflects the data model of the phase input; that is, the XML schema of the phase input is imported into the rule dictionary.