54 Creating Dynamic Business Processes

This chapter describes how to use two-layer Business Process Management (BPM). Two-layer BPM enables you to create dynamic business processes whose execution, rather than being predetermined at design time, depends on elements of the context in which the process executes. Such elements can include, for example, the type of customer, the geographical location, or the channel.

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:

• Introduction to Two-Layer Business Process Management

• Creating a Phase Activity

• Creating the Dynamic Routing Decision Table

54.1 Introduction to Two-Layer Business Process Management

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

Description of "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.

Note:

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:

• Designing Business Rules with Oracle Business Process Management

• Java API Reference for Oracle Business Rules

54.2 Creating a Phase Activity

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

Description of "Figure 54-2 Phase Activity in Oracle BPEL Designer"

Note:

The reference WSDL (layer 2 or called references) must have the same abstract WSDL as that for the phase reference that gets automatically created.

54.2.1 How to Create a Phase Activity

You create the phase activity for your composite application after you have created the necessary variables.

To create a phase activity:

1. Double-click the Phase activity.
2. In the Name field, enter a value.
3. In the Input and Output Variables section, select the Add icon to add input and output variables.
4. Select Add Input Variable. The dialog for selecting a variable appears.
5. Select an existing variable or select the Variables folder and click the Add icon to create a new variable.
6. Click OK. The Phase dialog is displayed with the variable populated.
7. From the Input and Output Variables icon, select Add Output Variable. The dialog for selecting a variable appears.Select an existing variable or select the Variables folder and click the Add icon to create a new variable.
8. Click OK. The Phase dialog is displayed with the input and output variable names populated.Click OK. The Oracle BPEL Designer displays the BPEL process.
9. From the File menu, select Save All.
10. Close the BPEL process.
11. Click the composite_name link (that is, the composite.xml file) above Oracle BPEL Designer. The SOA Composite Editor appears.

54.2.2 What Happens When You Create a Phase Activity

When you create a phase activity, the artifacts described in Table 54-1 are created.

Table 54-1 Artifacts Created with a Phase Activity

Artifact	Description
BPEL scope	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: Fact Type Model: The data model used for modeling rules. The rule dictionary is populated with a fact type model that corresponds to the input of the phase activity with some fixed data model that is required as part of the contract between the Oracle Mediator and Oracle Business Rules service components. Ruleset: A container of rules used as a grouping mechanism for rules. A ruleset can be exposed as a service. One ruleset is created within the rule dictionary. Decision Table: From an Oracle Business Rules perspective, a decision table is a collection of rules with the same fact type model elements in the condition and action part of the rules so that the rules can be visualized in a tabular format. The new decision table is created within the ruleset. Decision Service: A decision service is created that exposes the ruleset as a service of the Oracle Business Rules service component. The service interface is used by Oracle Mediator to evaluate the decision table.

54.2.3 What Happens at Runtime When You Create a Phase Activity

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.

Note:

In the current release, an asynchronous phase activity is supported. A synchronous or one-way phase activity is not supported.

54.2.4 What You May Need to Know About Creating a Phase Activity

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.

  Note:

  No transformation, assignment, or validation can be performed on a payload.

54.3 Creating the Dynamic Routing Decision Table

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.

54.3.1 How to Create the Dynamic Routing Decision Table

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

Description of "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

Description of "Figure 54-4 Completed Level-1 Phase in Oracle JDeveloper"

54.3.2 What Happens When You Create the Dynamic Routing Decision Table

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.