18.1.1 Business Rules and Business Rule Engines

Business rules are statements that describe the policies of a company. Examples of business rules can include the following:

All customers that buy more than $100 worth of products at one time or who are over the age of 65 receive a 10% discount.

A sales department is notified when inventory quantity is lower than ten and there are more than five pending orders on a given day.

If the annual income of a customer is less than $10,000, a loan request is denied.

If a customer submitted a late payment for a previous purchase, an additional charge of 2% is added to their next purchase.

A business rule engine is a system that manages and executes business rules. A business rule system typically consists of a rule repository, rule author, and rule engine. The rule author allows business rules to be specified separately from application code. Separating the business rules from code allows business analysts to change business policies quickly with graphical tools. The rule engine evaluates the business rule and returns decisions or facts that are then used in the business process. The rules are typically stored in a rule repository in a database or file system.

18.1.2 Decision Service

Oracle BPEL Process Manager provides support for a decision service. A decision service is a mechanism for publishing rules and rule sets as a reusable service that can be invoked from multiple business processes. The decision service is a standalone deployment unit that consists of the following components:

A Web service that wraps the rule session to the underlying rule engine. This service lets business processes assert and retract facts as part of the process. In some cases, all facts can be asserted from the business process as one unit. In other cases, the business process can incrementally assert facts and eventually consult the rule engine for inferences. Therefore, the service has to support both stateless and stateful interactions.

Rules that are evaluated by the decision service using the rule engine. These are defined using the rule author and loaded into the rule repository.

Metadata that describes facts required for specific rules to be evaluated. Each rule exposed as a service uses different types of facts. These facts must be exposed through XSD definitions. Appropriate WSDL operations must be exposed for rule evaluation.

For example, a credit rating rule set may expect a customer's SSN, previous loan history, and so on as facts, but a pension payment rule may expect an employee's years of service, salary, age, and so on as facts.

18.1.3 Oracle Business Rules with Oracle BPEL Process Manager

Oracle BPEL Process Manager provides support for Oracle Business Rules. Oracle Business Rules is a component included with Oracle Application Server. Business analysts use Oracle Business Rules to create and change business rules that are separate from the application code. This enables analysts to change business rules without stopping business processes or having to involve programmers.

In Oracle Business Rules, facts are data objects asserted in the Oracle Business Rules Rules Engine. For example:

For a car rental company to create a rule to match a driver's age, the driver's age represents the fact used in the rule.

For a loan company to create a rule denying a loan request to customers whose incomes fall below a specific level, the income level represents the fact used in the rule.

Each data object instance corresponds to a single fact. Rules are expressions that can be evaluated on this factual information.

If an object is re-asserted (whether or not it has changed), the Oracle Business Rules Rules Engine is updated to reflect the new state of the object. Re-asserting the object does not create a new fact. In order to have multiple facts of a particular fact type, separate object instances must be asserted. Using the Oracle Business Rules Rule Author, you create rules that operate on facts that are part of a data model. You make business objects and their methods known to Oracle Business Rules using fact definitions.

Oracle Business Rules consist of the following key components:

Oracle Business Rules Rule Author — A Web browser-based tool that provides a point-and-click interface to create and edit rules.

A repository stores dictionaries. A dictionary is a set of XML files that stores the application's rule sets and the data model. Rule sets are a group of business rules that are typically evaluated together and generated as one unit. Dictionaries can have different versions. Dictionaries and dictionary versions can be created, deleted, exported, and imported into a repository.

Oracle Business Rules SDK — A Java library that provides business rule management features to use for writing customized rules programs.

18.2.1 Decision Service Components

The decision service consists of the following components:

Rule Provider Interface (RPI) — An interface used by decision service design time clients such as Oracle JDeveloper. The RPI hides the details of a concrete rule engine implementation. This enables the RPI to interface with any rule engine from any provider. The main purpose of the RPI is to expose a uniform view of rule engine metadata such as fact types, rule sets, dictionaries, and so on.

A design time component (such as Oracle JDeveloper) can use the RPI to browse the metadata of a backend rule engine. According to what you model, metadata information for a decision service partner link can be materialized in the decision service configuration file.

Decision Service Builder — Reads the metadata information from a decision service configuration file and creates a self-contained J2EE enterprise archive that can be deployed to an application server.

Decision Service Runtime — A JAX-RPC Web service that is the Web service enabler for business rule engines such as Oracle Business Rules. The run time itself consists of the following components:

Decision Service Cache — Maintains metadata information about the rule data model used by the service. This includes metadata about the fact types, rule set, and decision service configuration. In addition, all stateful rule sessions are stored in that cache. Oracle Java Object Cache (JOC) is used. Therefore, the cache can be configured to run in clustered environments.

Fact Converter — Converts data coming from and going to Oracle BPEL Process Manager to a format understood by a rule engine. For the Oracle Business Rules Rules Engine, the fact converters use the JAXB 1.0 tech stack to convert BPEL variable data (XML) to and from Java objects.

Execution Unit — Executes the various steps defined by the interaction pattern at the backend rule engine. The execution unit uses the RPI for executions.

The rule model is saved to a rule repository. The rule repository can be a file or a directory at a WebDav backend.

The RPI of the decision service is used by the Decision Service wizard to create a connection to the rule repository and browse the repository metadata.

The Decision Service wizard creates the decision service metadata configuration file. The metadata consists of information about the backend rule engine being used (rule provider) and the interaction patterns (together with fact type information) modeled for the partner link.

The decision service builder creates the decision service enterprise archive for deployment into an application server. As part of this, a WSDL is created with message types and operations adjusted to what you modeled in Step 3.

The decide activity uses decision service metadata information to present you with a list of available operations of the service and detailed information on the number and types of facts used for an interaction with the rule engine

The decide activity completes generation of a new BPEL scope in the BPEL process model. Appropriate assign activities are created to convert the data from BPEL variables to data that the decision service (and more importantly the backend rule engine) expects.

The BPEL process is deployed to Oracle BPEL Process Manager during deployment time.

The decision service enterprise archive is deployed to the application server.

The BPEL process instance invokes the JAX-RPC decision service at run time, which then interacts with the backend rule engine, executes rule sets, invokes functions, and so on. Results are eventually returned to the BPEL process.

18.2.3 Contents of Decision Service Configuration File

The decision service configuration file (decisionservices.xml) defines the contract between the various components involved in the interaction of the decision service with the design time and a backend rule engine.The decision service configuration file consists of two parts:

The first part specifies metadata about the rule engine connections.

The second part provides the metadata for specific interaction patterns with a backend rule engine.

ruleEngineProvider — Specifies metadata about a backend rule engine connection. Apart from the rule engine provider, information on the rule repository is specified. You distinguish between these types of repositories:

File — The rule repository is stored in a file or directory.

WebDav — The rule repository is stored in a WebDav location.

decisionService — Consists of a name, an optional target namespace, and a mandatory reference to the rule engine to use for the interaction. A complete interaction with the rule engine is specified, which includes the catalog and catalog version to use, and the rule set to execute. Various interaction patterns are supported. Apart from the name of the pattern, the pattern signature is specified in terms of input and output facts or function names.

18.3 Use Cases for Integration of Business Processes and Business Rules

Oracle BPEL Process Manager and business rules are complementary technologies. Oracle BPEL Process Manager focuses on orchestration of systems, services, and people. Business rules focus on decision making and policies.

Some examples of where decision service can be used include:

Dynamic processing — Rules can perform intelligent routing within the business process based on service level agreements or other guidelines. For example, if the customer requires response within one day, send the loan application to the StarLoan loan agency only. If the customer can wait longer, then route the request to three different loan agencies.

Externalize decision points in the process — There are typically many conditions that must be evaluated as part of a business process. However, the parameters to these can be changed independent of the process. For example, you provide loans only to customers with a credit score of at least 650. This value may be changed dynamically based on new guidelines set by business analysts.

Data validation and constraint checks — Rules can validate input documents or apply additional constraints on requests. For example, a new customer request must always be accompanied with an employment verification letter and bank account details.

Human workflow — Rules are frequently used in the context of human tasks in the business process:

Policy-based task assignments dispatch tasks to specific roles or users. For example, a process that handles incoming requests from a portal can route loan requests and insurance quotes to a different set of roles.

Load balancing of tasks among users – When a task is assigned to a set of users or a role, each user in that role acquires a set of tasks and acts on them in a specified time. For new incoming tasks, policies may be applied to set priorities on the task and put them in specific user queues. For example, a specific loan agent is assigned a maximum of 10 loans at any time.

18.4 Integration of BPEL Processes with Business Rules

Oracle BPEL Process Manager provides the following design-time components that enable you to integrate BPEL processes with business rules.

18.4.1 Create Rule Engine Connection Wizard

The Create Rule Engine Connection wizard enables you to create a connection to a rule engine. This connection enables you to browse and select rule sets and functions available in rule dictionaries of a rule repository in the business rule engine. You only need to create one connection to the rule engine. Once created, this connection is shared between multiple BPEL projects.

Select Connection Navigator from the View main menu in Oracle JDeveloper.

Right-click Rule Engines and select New Rule Engine Connection.

Click Next on the Welcome window.

Enter a name. When creation of the rule engine connection is complete, this name displays in the Connection Navigator under Rule Engines.

Select the type of repository in which the rule sets and functions are stored in the repository of the business rule engine. For this release, the Oracle Business Rules Rules Engine is supported.

You can create a WebDav connection by right-clicking WebDAV Server and selecting New WebDAV Connection in the Connection Navigator.

Click Next.

The Test Connection window appears.

Click Test.

If the connection to the business rule repository is successful, the following message appears:

Success

If the connection is unsuccessful, click Details to view the reason for failure. Take appropriate corrective actions.

Click Finish.

The connection name displays in the Connection Navigator under Rule Engines. If you need to edit the connection, double-click the connection name to display configuration details.

18.4.2 Decision Service Wizard

The Decision Service wizard enables you to integrate your BPEL process with a business rule (for example, a rule set or function) that you created in the Oracle Business Rules Rules Engine. This enables you to make business decisions based on these rules.

18.4.2.1 Selecting an Invocation Pattern

The Decision Service wizard enables you to select an invocation pattern that describes how to interact with the business rule engine.

Drag and drop a Decision Service from the Services list of the Component Palette onto either side of the designer window beneath the header Services.

Enter a name in the Service Name field. When complete, this name is used as the partner link name. A WSDL file of the same name is also created.

The Namespace field is automatically completed with your entry from the Service Name field. You must have a unique namespace for each WSDL in your project. This is because some BPEL variables are generated from elements in the WSDL files.

Select an invocation pattern for invoking the rule set or function. The wizard creates rule sessions based on the invocation pattern you select. You do not have the option of selecting between stateful or stateless rule sessions.

If you have not created a connection to the rule engine, you cannot access the rule sets and functions in the rule repository. Click the first icon in the upper right to start the Create Rule Engine Connection wizard.

An alternative to creating a connection to a file-based rule repository is to directly import a file into a project. Note that each BPEL project must physically copy the repository file to the project at the time of Web service creation. After the file is copied, any changes to the original file are not reflected in the Web service. Click the second button in the upper right to browse for the file to import. The file must be a valid Oracle rule repository file. Otherwise, an error appears.

Click OK.

You are returned to the Select a Ruleset or a Function window.

18.4.2.3 Specifying Input and Output Facts

Based on the type of invocation pattern you selected, the Select a Ruleset or a Function window displays a table with different details at the bottom of the window.

18.4.2.3.1 Rule Sets

The table displays the facts in the data model of the catalog from which you selected the rule set. You select the facts to assert (that is, set the value from the BPEL variable to the fact) and retrieve the results to return. Note that the columns that appear are based on whether the selected pattern asserts facts, retrieves facts, or does both.

Specify the input (assert) and (optionally) the output (watch) facts. The assert facts enable you to assert a fact to the rule set or function (send factual data to the business rule engine). The watch facts enable you to return results from the rule set or function. Watch facts only appear if you selected an invocation pattern that retrieves results.

The Check here to assert all descendants from the top level element check box enables you to assert all the descendants of the selected rule set or function. For example, assume that a purchase order rule set contains three fact types. If this check box is selected, the purchase order and all three fact types are asserted. If this check box is not selected, only the purchase order is asserted.

Click Next.

18.4.2.3.2 Functions

The table displays the input parameters and parameter types to return.

18.4.2.4 Importing Schema Files

The wizard attempts to identify all the schema files in the repository that must be imported into this project. Based on this attempt, this window can display the following status messages:

If the Decision Service Wizard finds the schema files to import, the directory paths to the files display at the top of this window. No action is required on your part.

If the Decision Service Wizard cannot find the schema files to import, the directory paths to the files display at the top of this window. You must manually copy these files to the specified directory.

If this XSD schema file includes or imports other schema files, ensure that those files are copied into the bpel\rules\xsd subdirectory of your BPEL project indicated on-screen. Ensure that you use only relative directory paths for these schema files.

Click Next.

The decision service partner link is created. A directory named decisionservices is also created in the BPEL project. A directory with the same name as the service name is created inside the decisionservices directory.

18.4.3 Decide Activity

The decide activity enables you to create a BPEL process activity that invokes the decision service partner link you created with the Decision Service wizard. This activity also enables you to create copy operation assignments between the fact data in your rule set or function and BPEL variables.

When complete, a decide activity consisting of assign and invoke activities to the decision service partner link is created.

18.4.3.1 Mapping Input and Output Facts to BPEL Variables

Drag and drop a Decide activity from the Process Activities list of the Component Palette into your BPEL process.

Enter a name.

Select the decision service partner link you created. If you have not created a decision service, click the first icon to the right of the Decision Service field.

Select the operation of the invocation pattern to perform. The operations available for selection are based on the invocation pattern you selected in Step 3.

If you selected Execute Ruleset

Assert facts only — Select the rule engine facts you want to assert (send factual data to the rule engine) in the future. You assign the required data for the facts with a BPEL assign activity. The underlying rule session must be stateful. Otherwise, the asserted facts are not visible to subsequent rule engine invocations.

Retrieve results — Retrieve a result from the business rule engine. The values of these results may have changed by past execution of a rule set acting on these facts. The wizard assumes that it has a stateful rule session in its cache from which a result can be retrieved. This is the case if the invocation pattern Assert facts and execute rule set operation was executed before in the BPEL process.

Assert facts and execute rule set — The same as Assert facts only, except that the rule set is executed after the facts are asserted. The wizard creates (or uses) a stateful rule session. Otherwise, the result of executing this pattern is lost. No results are retrieved from the business rule engine.

Assert facts, execute rule set, and retrieve results — The same as Assert facts and execute rule set, except that the results are retrieved from the business rule engine. You map the results of rule set execution to BPEL variables with an assign activity. The rules session remains active. This enables you to reuse previously asserted facts.

Assert facts, execute rule set, retrieve results, and reset the session — The same as Assert facts, execute rule set, and retrieve results, except that the results are reset for the next time that you invoke the Web service. Resetting the session clears the previously asserted fact values.

If you selected Execute function

Execute function — Executes a function. Functions are also defined in dictionaries. For rule sets, you select input and output facts. For functions, there are a fixed set of input parameters and a single return value.

Execute function and reset the session — The same as Execute function, except that a stateful rule session is created for this pattern. All fact values are reset after retrieving the return value of the function.

Click Assign Input Facts, then click Create to create mappings for the input facts. This enables you to assign BPEL variables to the facts to be asserted or to the function input parameters.

This enables you to create assignments that map BPEL input variables to automatically created BPEL variables that correspond to the input (assert) fact type shown in "Specifying Input and Output Facts" (for this example, Ratingrequest).

If you selected an invocation pattern that retrieves results, click Assign Output Facts, then click Create to create mappings for the output facts. This enables you to assign values from a function return value or rule set result to a BPEL variable.

This enables you to create assignments that map automatically created BPEL variables that correspond to the output (watch) fact type shown in "Specifying Input and Output Facts" (for this example, Rating) to BPEL input variables.

Click OK when complete.

A decide activity consisting of assign and invoke activities to the decision service partner link is created.

18.5 Methodology for Rule Set Modeling and Integration with a BPEL Process

Rule sets are a group of business rules that are typically evaluated together and generated as a single unit. This section describes two methodologies for modeling rule sets in a rule author.

After you model a rule set, you can integrate it with a BPEL process in Oracle JDeveloper. You must have an existing rule repository prior to creating a decision service partner link in Oracle JDeveloper.

Use different names for elements and complex types. Although the XML schema specification allows the same name for an element and a type, the JAXB class generator does not support it.

Use different target package names for every XML schema imported into the rule author. As part of JAXB class generation, a factory class ObjectFactory is created. If you import a second XML schema and specify the same target package name, the JAX generator overwrites the factory class from the first import. This results in unexpected behavior from the rule engine.

As a result of using JAXB for fact types, rule modeling needs to happen on the XML schema type level (complexType level). This is because for XML elements, JAXB generates marker interfaces only and the rule author cannot introspect the attributes and methods of these interfaces for rule modeling.

As part of the data model, RL functions can be specified. It is a convenient way to simplify rule action handling by externalizing the logic of a rule action into a RL function. In this case, the purpose of the rules is to accept a rating request for which rules are applied. The result of rule execution is a new rating object consisting of the data calculated by the rules. Therefore, it is convenient to create an RL function that creates a new rating object and asserts it with the rule engine.

Select assertRating from the Function list. This is the function created in Step 16.

Provide values for the function parameters. For this example, ratingrequest, credit_rating, credit_risk, and credit_max_amount). The values for ratingrequest and credit_max_amount cause the rule to be invoked and can be used in the rule action part.

It is a good practice to model a rule with no if statement pattern (simply accepting the fact) and an action that generates a well-defined result for the case where no other rule is invoked. For example:

Set the priority to -10 in the Priority field to ensure that this rule is not invoked if other rules match the pattern of the fact instance.

Accept the fact (request is a TRatingRequest in the If section) without specifying any additional test pattern.

Provide a dummy result that can be checked later from Oracle BPEL Process Manager (Call assertRating(request, 0, "Unknown", 0.0) in the Then section).

Click the flashlight icon to the right of the Output Schema Element field.

The Type Chooser window appears.

Expand and select Imported Schemas > CreditRatingTypes.xsd > rating.

Click OK.

Click Finish.

This completes the BPEL project creation wizard. A new BPEL process template is created for you with a receive activity accepting a ratingrequest element and a reply activity sending out a rating element.

18.5.4.3 Task 3: Create a Decision Service Partner Link

Ensure that Services is selected in the drop-down list of the Component Palette section in the upper right section of Oracle JDeveloper.

Drag and drop a Decision Service onto the right side of the designer window anywhere beneath the header Services.

The Select a Ruleset or a Function window appears. This window enables you to select an invocation pattern.

Enter the following details:

Field

Value

Service Name

CreditRatingService

Note: When complete, this becomes the name of the partner link.

Namespace

http://xmlns.oracle.com/myLoanProcess/CreditRatingService

Note: This field is automatically completed with your entry in the Service Name field.

Click Show All Versions at the bottom of the window to display all versions of rule dictionaries in the specified repository in the business rule engine. Business rule engines can contain multiple rule dictionaries and versions.

The Copy XSD Files window shows the directory path to the CreditRatingTypes.xsd schema file for the wizard to import. If the wizard cannot find this file, you must manually copy it to the rules/xsd directory of the SampleProcess BPEL project.

Click Next, then Finish.

A partner link of the name you specified in Step 3 is created. This partner link provides the interface between the BPEL process and the business rule engine.

You now map BPEL input variables to automatically created BPEL variables that correspond to the Ratingrequest input (assert) fact type.

Click Create.

The From section shows the BPEL variables of the process and the To section shows the facts selected for the partner link interaction. Since you reused the XML schema file of the fact types in your BPEL process, you can assign the top level ratingrequest element from the BPEL input variable inputVariable to the fact to assert.

You now assign the results of executing the rule set to a BPEL variable. For the assignment of output facts, the From section displays the facts as modeled in the decision service partner link interaction and the To section lists the variables of the BPEL process.

EAR deployment descriptors are generated and stored in the META-INF subdirectory of the enterprise archive.

A Java server page file GetDecisionServiceInfo.jsp is generated and stored in the public_html directory of the Web archive.

The decision service-dependent WSDL file DecisionService.wsdl is generated and stored in the WEB-INF/wsdl directory of the Web archive. All dependent XML schema files are also copied to that directory. Dependent schema files include the definitions for the Web service messages and contract and the XML schema files for the XML fact types of the business rule engine.

The decision service configuration file decisionservices.xml is generated and copied to the directory WEB-INF/classes of the Web archive.

The rule repository location is resolved:

If the rule repository is a file repository, the repository file is copied from its original location to the WEB-INF/repository directory of the Web archive and the configuration file decisionservices.xml is modified to reference the new location.

If the rule repository is a WebDav repository, the configuration file is not edited.

JAXB generation steps:

A list of XML schema files for the XML fact types being used in the partner link is obtained.

Oracle JAXB generator is used to generate JAXB classes for the XML fact types in the directory WEB-INF/classes of the Web archive.

Web service deployment descriptors and the JAX-RPC mapping file are generated in the directory WEB-INF of the Web archive.

The decisionservices.xml decision service configuration file includes the necessary information to generate an interaction pattern-specific WSDL.

18.6.2 Deployment

The decision services modeled in a BPEL project are deployed with the BPEL process. As part of BPEL process deployment, the following steps are performed for all decision services in the project:

The Java compiler (javac) is used and all Java classes are compiled in the subdirectory WEB-INF/classes.

A Web archive DecisionService.war file is created in the ear enterprise archive subdirectory of a decision service. The Web archive consists of all files under the war directory of a decision service.

An enterprise archive DecisionService.ear file is created in the top level directory of a decision service. The enterprise archive consists of all files in the ear directory of a decision service, plus the Web archive created above.

The enterprise archive DecisionService.ear is deployed to the underlying J2EE container using the administrator tools of the specific container.

The J2EE context root of a decision service DecisionService is as follows:

There are several implications of deploying decision services as self-contained enterprise archives. The most important is that every decision service can be managed separately and independently of its invoking BPEL process using Oracle Enterprise Manager 10g Application Server Control Console.

For example, with the AutoLoanDemo sample included as part of Oracle BPEL Process Manager, the AutoLoanFlow BPEL process consists of two decision service partner links:

18.6.3.2 Oracle BPEL Control Support

You can monitor and diagnose decision services through Oracle BPEL Control. A decisionServiceDetails property is added to the BPEL suitcase that refers to the configuration information of a decision service partner link.

Log into Oracle BPEL Control.

Click the AutoLoanFlow BPEL process in Oracle BPEL Control.

Click Descriptor.

The Descriptor tab shows the process descriptor of the AutoLoanFlow process included with the AutoLoanDemo sample:

18.7 Advanced Decision Service Features

This section describes advanced decision service features for which limited or no user interface support is provided. Instead, you manually edit deployment description and configuration files to use these features.

18.7.1 Using WSIF Bindings

As described in "Decision Service Components", decision services are JAX-RPC Web services. Therefore, SOAP is the protocol to use with a decision service. However, you can configure the BPEL process to use the decision service in a WSIF context.

Perform the following procedures:

Remove the wsdlRuntimeLocation property for a decision service partner link from the bpel.xml deployment descriptor file of the BPEL process.

18.7.2 Enabling Logging of Oracle Business Rules Rule Session Events

The Oracle Business Rules Rules Engine defines several rule session events for monitoring. (See Oracle Business Rules Language Reference Guide for additional details.) The decision service provides the option to enable these events and log the output to the Oracle BPEL Process Manager log file.

The events are enabled through properties in the decision service configuration file (decisionservices.xml). Table 18-2 describes the properties that can be set.

Table 18-2 Decision Service Configuration File Parameters

Property

Description

watchRules

Information about rule invocations (execution of activations)

watchActivations

Addition or removal of activations from the agenda

watchFacts

Assertion, retraction, or modification of facts in working memory

watchFocus

Pushing or popping of the rule set stack

watchCompilations

When a rule's conditions are added to the network, information about how the condition parts are shared with existing rules is printed. Ò=Ó indicates sharing.

18.7.3 Customizing assertXPath

Oracle Business Rules can specify an XPath expression when asserting facts. This reduces the number of assertions and provides a convenient mechanism to assert multiple facts with a single assert statement.

This functionality is available in Oracle JDeveloper. Select Check here to assert all descendants from the top level element on the Select a Ruleset or a Function window in the Decision Service wizard. When you select this option, a default XPath "//*" is created for the fact to assert. This causes all descendants of the fact element to assert during run time.

You can customize the XPath expression manually by modifying the decision service configuration located in the following file:

You can customize the attribute xpath="//*" before deploying the decision service.

18.8 Example of BPEL Process Integration with Business Rules

The section describes how to design and integrate a BPEL process with the business rules of a business rule engine. This example is part of a larger tutorial that also describes how to design this BPEL process to use human workflow. Only the part describing BPEL process integration with business rules is included in this section.

Click Show All Versions at the bottom of the window to display all catalog versions of rule dictionaries in the specified repository. Business rule repositories can contain multiple rule dictionaries and versions.

18.8.5 Task 5: Create a Decide Activity

You now create a decide activity to invoke the decision service partner link you created with the Decision Service wizard. The decide activity enables you to create copy operation assignments between the fact types in your rule set (now included in the partner link) and BPEL variables. You provide an input fact to the rule set and then retrieve the results. This enables you to invoke rules from the BPEL process.When complete, a decide activity consisting of assign and invoke activities to the decision service partner link is created.

Drag and drop a Decide activity below the receiveInputreceive activity in the designer window.