Introduction to Decision Components Decision Service Architecture

11 Working with Decision Components in SOA Applications 11-1 11 Working with Decision Components in SOA Applications Oracle SOA Suite provides support for Decision components that support Oracle Business Rules. A Decision component is a mechanism for publishing rules and rulesets as a reusable service that can be invoked from multiple business processes. A Decision Component is a SCA component that can be used within a composite and wired to a BPEL component. Apart from that, Decision Components are used for dynamic routing capability of Mediator and Advanced Routing Rules in Human Workflow. This chapter includes the following sections: ■ Section 11.1, Introduction to Decision Components ■ Section 11.2, Working with a Decision Component ■ Section 11.3, Decision Service Architecture

11.1 Introduction to Decision Components

A Decision component is a Web service that wraps a rule session to the underlying decision function. A Decision component consists of the following: ■ Rules or Decision Tables that are evaluated using the Rules Engine. These are defined using Rules Designer and stored in a business rules dictionary. ■ Metadata that describes facts required for specific rules to be evaluated. Each ruleset that contains rules or Decision Tables is exposed as a service with facts that are input and output. These facts must be exposed through XSD definitions. For example, a credit rating ruleset may expect a customer ID and previous loan history as facts, but a pension payment ruleset may expect a value with the years of employee service, salary, and age as facts. For more information, see Section 11.2.1, Working with Decision Component Metadata . ■ A Web service wraps the input, output, and the call 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. 11-2 Oracle Fusion Middleware Users Guide for Oracle Business Rules You can create a variety of such business rules service components. For more information, see Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

11.2 Working with a Decision Component

Using Oracle JDeveloper with Rules Designer these tools automatically generate all required metadata and WSDL operations. The Decision component can be integrated into an SOA composite application in the following ways: ■ Create a Decision component as a standalone component in the SOA Composite Editor. In this scenario, the Decision Service is exposed on the composite level and thus can be invoked from any Web service client. For more information, see Getting Started with Oracle Business Rules in the Oracle Fusion Middleware Developers Guide for Oracle SOA Suite. ■ Create a Decision component in the SOA Composite Editor that you later associate with a BPEL process. In this scenario the Decision Service is not exposed on the composite level. However it can be wired to any other component within the composite, such as BPEL, Oracle Mediator, and Oracle Human Workflow. For more information, see Getting Started with Oracle Business Rules in the Oracle Fusion Middleware Developers Guide for Oracle SOA Suite. ■ Create a Decision component within the Human Task editor of a human task component. This integration provides the following benefits: ■ Dynamic processing: provides for intelligent routing, validation of policies within a process, and constraint checks. ■ Integration with ad hoc human tasks: provides policy-based task assignment, various escalation policies, and load balancing of tasks.

11.2.1 Working with Decision Component Metadata

A Decision component is defined by the following files: ■ Decision Service Metadata .decs File ■ SCA Component Type .componentType File ■ Decision Component Entry in composite.xml Typically, Oracle JDeveloper generates and maintains these files.

11.2.1.1 Decision Service Metadata .decs File

Every Decision component within a composite comprises one business rule metadata file. The business rule metadata file provides information about the location of the component business rule dictionary and the Decision Services exposed by the Decision component. One Decision component might expose one or more Decision Services. For example a CreditRating Decision component might expose two services, CheckEligibility and CalculateCreditRating. In Oracle Fusion Middleware 11g Release 1 11.1.1, the Decision Service metadata comprises the decision function name that is being exposed as a Web service. For projects that are migrated from older releases of Oracle SOA Suite, the Decision Working with Decision Components in SOA Applications 11-3 Service metadata typically has more information depending on the interaction pattern used in 10.1.3.x. The business rule metadata file business_rule_name.decs defines the contract between the components involved in the interaction of the business rule with the design time and back-end Oracle Rules Engine. This file is in the SOA Content area of the Application Navigator in Oracle JDeveloper for your SOA composite application. Table 11–1 describes the top-level elements in the Decision service .decs file. Table 11–1 Decision Metadata File .decs Top-level Elements Element Description ruleEngineProvider The business_rule_name.decs file ruleEngineProvider element includes details about the rule dictionary to use: ruleEngineProvider name=OracleRulesSDK provider=Oracle_11.0.0.0.0 repository type=SCA-Archive pathAutoLoanCompositeoraclerulesAutoLoanRules.rulespath repository ruleEngineProvider The repository type is set to SCA-Archive for Decision components. This indicates that the rule dictionary is located in the service component architecture archive. The path is relative and interpreted differently by the following: ■ Design time — The path is prefixed with Oramds:. Metadata service MDS APIs open the rule dictionary. Therefore, the full path to the dictionary is as follows: Oramds:AutoLoanCompositeoraclerulesAutoLoanRules.rules ■ Runtime business rule service engine — The business rule service engine uses the Oracle Business Rules SDK RuleRepository API to open the rule dictionary located in MDS. The composite name prefix, for example AutoLoanComposite is removed from the path and the metadata manager assumes the existence of oraclerulesAutoLoanRules.rules relative to the composite home directory. decisionService A Decision service is a Web service or SOA enabler of business rules. It is a service in the sense of a Web service, thus opening the world of business rules to service-oriented architectures SOA. In 11g Release 1 11.1.1.5.0, a Decision service consists of metadata and a WSDL contract for the service. The business_rule_name.decs file decisionService element defines the metadata that describes business rules exposed as a Web service. In general, a Decision service includes the following elements: ■ Target namespace ■ Reference to the back-end Oracle Rules Engine this is the link to the rule dictionary. Note that OracleRulesSDK is the reference name that matches the name of the Oracle Rules Engine provider in ruleEngineProvider element. ■ Name CreditRatingService in the following example ■ Additional information about the dictionary name and ruleset to use ■ List of supported operations patterns Apart from the operations patterns, the parameter types or fact types of operations are specified and validated later at runtime. Therefore, every Decision service exposes a strongly-typed contract. 11-4 Oracle Fusion Middleware Users Guide for Oracle Business Rules

11.2.1.2 SCA Component Type .componentType File

An SCA business_rule_name.componentType file is included with each Decision component. This file lists the services exposed by the business rules service component. In the following sample, two services are exposed: CreditRatingService and LoanAdvisorService. ?xml version=1.0 encoding=UTF-8 ? -- Generated by Oracle SOA Modeler version 1.0 at [52407 9:27 AM]. -- componentType xmlns=http:xmlns.oracle.comsca1.0 service name=CreditRatingService interface.wsdl interface=http:xmlns.oracle.comcreditratingRatingwsdl.interfaceIDecisionSer vice service service name=LoanAdvisorService interface.wsdl interface=http:xmlns.oracle.comloanofferAdvisorwsdl.interfaceIDecisionServi ce service componentType

11.2.1.3 Decision Component Entry in composite.xml

An entry in composite.xml is created for a decision component. For example, component name=OracleRules1 implementation.decision src=OracleRules1.decs component The business rules service engine uses the information from this implementation type to process requests for the Service Engine. From an SCA perspective, a Decision Component is a new implementation type.

11.2.2 Working with Decision Components that Expose a Decision Function

You can use a Decision service to expose an Oracle Business Rules Decision Function as a service. A decision function is a function that is configured declaratively, without using RL Language programming that you use to call rules from a Java EE application or from a BPEL process. Example 11–1 shows a business_rule_name.decs file decisionServices element that defines the metadata for an Oracle Business Rules Decision Function exposed as a service. Example 11–1 decisionService for Decision Function Execution ?xml version=1.0 encoding=UTF-8 standalone=yes? decisionServices xmlns=http:xmlns.oracle.combpelrules name=PurchaseItems ruleEngineProvider name=OracleRulesSDK provider=Oracle_11.0.0.0.0 repository type=SCA-Archive pathPurchasingSampleProjectoraclerulescomexamplePurchaseItems.rulespath repository ruleEngineProvider decisionService targetNamespace=http:xmlns.oracle.comPurchaseItemsPurchaseItems_DecisionService_Validate PurchasesDF ruleEngineProviderReference=OracleRulesSDK name=PurchaseItems_DecisionService_ValidatePurchasesDF catalogPurchaseItemscatalog pattern name=CallFunctionStateless arguments callcom.example.PurchaseItems.ValidatePurchasesDFcall arguments Working with Decision Components in SOA Applications 11-5 pattern pattern name=CallFunctionStateful arguments callcom.example.PurchaseItems.ValidatePurchasesDFcall arguments pattern decisionService decisionServices In this case, the decision function ValidatePurchasesDF itself is specified entirely in the PurchaseItems.rules file. For more information, see, Chapter 6, Working with Decision Functions .

11.2.3 Using Stateful Interactions with a Decision Component

To provide a stateful Decision service you create a decision function and specify that the decision function is not stateless. To do so you deselect the Stateless checkbox in a decision function. Note the following details about stateful interactions with a decision component also see Figure 11–2 : ■ Rule sessions from the cache and those from the pool are mutually exclusive: – The rule session pool is for simple, stateless interactions only – The rule session cache keeps the state of a rule session across Decision service requests

11.2.4 What You Need to Know About Stateful Interactions with Decision Components

A Decision Component running in a Business Rules service engine supports either stateful or stateless operation. The Reset Session stateless checkbox in the Create Business Rules dialog provides support for these two modes of operation. When the Reset Session stateless checkbox selected, this indicates stateless operation. When Reset Session stateless checkbox is unselected, the underlying Oracle Business Rules object is kept in memory of the Business Rules service engine at a separate location so that it is not given back to the Rule Session Pool when the operation is finished. Only use stateful operation if you know you need this option some errors can occur at runtime when using stateful operation and these errors could use a significant amount of service engine memory. When Reset Session stateless checkbox is unselected, a subsequent use of the Decision component reuses the cached RuleSession object, with all its state information from the callFunctionStateful invocation, and then releases it back to the Rule Session pool after the callFunctionStateless operation is finished.

11.3 Decision Service Architecture

A Decision service consists only of the service description. All other artifacts are shared within a decision component as shown in Figure 11–1 . 11-6 Oracle Fusion Middleware Users Guide for Oracle Business Rules Figure 11–1 Decision Service Architecture The heart of runtime is the Decision service cache, which is organized in a tree structure. Every decision component owns a subtree of that cache depending on the composite distinguished name DN, component, and service name. In this regard, Decision services of a decision component share the following data: ■ Metadata of the decision component – Fact type metadata – Function metadata – Ruleset metadata ■ Rule session pool – One rule session pool is created per decision component – The rule sessions in the pool are pre-initialized with the data model Oracle RL and the ruleset Oracle RL already executed – New rule sessions are created on demand – Rule sessions can be reused for a configurable number of times – The initial size of the rule session pool is configurable ■ Stateful rule session cache – A special cache is maintained for stateful rule sessions. For more information, see Section 11.2.3, Using Stateful Interactions with a Decision Component . ■ Deployment artifacts – Decision component deployment can end up in class generation for JAXB fact types. The classes can be shared across the composite. Figure 11–2 shows how both stateless and stateful rule sessions interact with the rule session pool and how stateful rule sessions interact with the stateful rule session cache during a Decision service request. Working with Decision Components in SOA Applications 11-7 Figure 11–2 Stateless and Stateful Rule Session Usage for a Decision Service Request 11-8 Oracle Fusion Middleware Users Guide for Oracle Business Rules 12 Using Oracle SOA Composer with Oracle Business Rules 12-1 12 Using Oracle SOA Composer with Oracle Business Rules Oracle Business Rules lets you create rules at design-time with the Oracle Business Rules Designer Rules Designer extension to Oracle JDeveloper. Rules Designer is an editor that enables you to create and edit rules with Oracle JDeveloper, and store the rules in a rules dictionary. When a dictionary is deployed in an SOA composite application, Oracle Business Rules lets you use Oracle SOA Composer to view, edit, and commit changes to a dictionary. In addition, Oracle SOA Composer enables you to work with other metadata types such as tasks. This chapter shows you how to use the Oracle SOA Composer application Oracle SOA Composer to work with a deployed dictionary and tasks that are part of an SOA composite application. This chapter includes the following sections: ■ Section 12.1, Introduction to Oracle SOA Composer