Defining a New Rule

The first step is to design the business rule. In addition to designing the logic of the OPA rulebase, your designers must consider where and when the business rule should be invoked by the product as well as what logic should occur in the product based on the output from the call to OPA.

The topics in this section describe more detail to consider when implementing a new business rule using an OPA rulebase.

Develop the Algorithm to Invoke the Rule

An important step in considering an integration point with OPA is to consider when it should be invoked within the product. In other words, what plug-in spot? For example:

Is the business rule validation that must be invoked any time a certain object changes? Then perhaps this should be implemented as a BO validation algorithm for an appropriate business object.
Is the business rule validation that determines if an object may transition to a different status? Then perhaps this should be implemented as an enter plug-in algorithm on an appropriate state for a business object.

As part of determining the appropriate plug-in spot, the designer should become familiar with the expected responsibilities of the plug-in spot and the data it receives when invoked.

Next, the designer should determine if the product already supplies an algorithm type for the desired plug-in spot that invokes OPA. For example, perhaps the product supplies an out of the box integration with OPA and the algorithm logic (the data it retrieves to send to OPA and the logic that occurs after returning from OPA) is appropriate for your business rule. However, the detailed logic performed by the product's sample rulebase does not match the business rule needed by the implementation. If so, your implementation may only require a new OPA rulebase to plug into this algorithm type.

The following points highlight more detail needed for designing a new algorithm to invoke an OPA rulebase:

Work with the business rule designer to determine what information needs to be provided to OPA. The algorithm is responsible for gathering all the information required by OPA, if it is not already supplied to the algorithm.
To invoke OPA, the product provides a web service dispatcher business service (F1-InvokeWebService). The business service requires the web service adapter name, the name of the operation to invoke (typically Assess for OPA integration) and the request and response data areas related to the operation. The algorithm must determine the appropriate web service adapter and must populate the request data area with the information required for the OPA call.

The product algorithms have typically been designed to define the web service adapter name as an input parameter. The algorithm then includes logic to retrieve the request and response data areas defined on the web service adapter. This allows for algorithm type re-use. It means that the same algorithm type may be used for different business rules implemented with different OPA rulebases, assuming that the other logic performed by the algorithm applies to the different rules.
Determine what logic should occur upon receiving the rulebase response. See the Rulebase Outcome section below for more information.

Rulebase Outcome

The type of data returned by a rulebase is configured in the request by populating the Outcome Style element for each output value (referred to as a "goal" in OPA terminology).

An outcome style of value-only tells OPA to simply return the value of the goal (output) . This is the default if nothing is specified in the request.
An outcome style of decision-report tells OPA to return a detailed report of why a particular result is given in addition to the value of the goal.

Note:
The above values are defined in the Outcome Style extendable lookup (F1-OutcomeStyleLookup).

Based on the business requirements, the algorithm must determine what should occur based on the results.

If the business requirement dictates that the decision report should be stored, the product provides a business service Create Decision Report (C1-CreateDecisionReport). This business service stores the decision report details in a special "attachment" table and returns the ID. Based on the business rules, the ID may be captured and stored with the object that requested the call to OPA. The following points provide more detail on storing a decision report.

The following information should be provided to the business service to create the decision report:

Populate the BO with F1-DecRpt
Populate the MO and prime key values to appropriate values based on the object that invoked the OPA rule. For example, if the OPA rulebase was used to validate an appeal, the MO is set to C1-APPEAL and the PK value is set to the appeal id. This allows cross referencing on the decision report to the object that created it.
Populate the Decision Report Data with the appropriate decision report node returned by the call to OPA.

The attachment id is returned. To store a link to the decision with the object that created it, the product recommendation is to create a Log Entry, if the maintenance object supports logs. The characteristic type for the log should be set to C1-DCRPT and the characteristic value should be set to the attachment ID.
Note:
The characteristic type may require additional configuration to include the log in question as one of the valid characteristic entities.

Refer to Viewing Decision Report for information about viewing the decision report.

Deploying the Rulebase

Use Oracle Policy Modeling to develop the rulebase. Once the rulebase is tested and it is compiled and built, the deployment file is created.

This rulebase should be deployed on the Oracle Web Determinations server. Note that in most implementations a separate group such as a release services group is responsible for this type of task.
As described in Configuring the Integration, besides deploying the rulebase on the server, the web service adapter logic requires the rulebase to be copied to the server directory defined in the BO option Oracle Policy Automation Rulebase Location.

Final Steps

The remaining steps for the integration involve creating the web service adapter and fully configuring and plugging in the algorithm.

Fastpath:

Refer to Configuring the Integration for more information.