Defining a Rule with Pre-generated Model

The topics in this section describe more detail to consider when implementing a new business logic using an OPA rulebase with pre-generated data model.

Understanding the Generated Data Model

The generated data model reflects the structure of the source entity. Each entity name corresponds to the xml node name and may be prefixed with the succession of parent node names and node type “qualifiers”, such as section, line, table, list, group or tablerow. This is done in order to ensure the uniqueness of the entity names within the generated model.

Each entity that represents the actual data-bearing elements, has two value-holder attributes, one for an original input value and one for the value determined as a result of the rulebase execution. The input value is named xxx_​submitted_​value, the output is named xxx_​determined_​value.

Develop the OPA Rule

In OPA development environment create a new project, select Properties folder on the project explorer three and use the option Add Existing File to add the generated data model file as a properties file. Perform an initial sanity check: compile the rulebase and verify that the generated data model contains no errors.

Set up the initial values for the attributes that will be referenced by the validation logic. To validate or pre-calculate the values you may need to perform various mathematical and logical operations with the values. Note that OPA does not automatically sets either blank values for text or zeroes for numeric attributes. Instead, it defaults all of them to a the special value unknown. This value is not equivalent to a null and cannot be evaluated or compared with other regular values, hence you may need to perform an explicit initialization of the attributes whose values are not provided. This example illustrates the initialization of a numeric attribute in the OPA rule:
Total Gross Sales' Determined Value  
0 The total gross sales' submitted value is unknown.
The total gross sales' submitted value otherwise

Implement form data validations and calculations. The ultimate goal is to determine whether the data is valid, to correct the invalid values and/or provide the calculation results. The rulebase may also raise form exceptions. For that purpose, you should populate the entity’s attribute named xxx_​error_​message with the actual error text.

Certain limitations apply:
  • Do not alter public names of the entities and attributes. It will break the integration. You can modify the generated entity's text to make the entity more usable and intuitive. For example you may turn the generated "lineItems section’s firstPrepayment" into "the first prepayment". This simplifies the rule writing process and makes you rule much more readable..
  • Do not remove entities and/or value-holder attributes from the generated model. The integration logic populates the webservice request with all the values available in the system. The corresponding entity and/or attribute must be defined on the receiving side.
  • Data model changes should be made in both systems. If the business requirements dictate changes to the data model, similar changes should be made to the model’s source object’s structure.
  • The output error message size should not exceed 250 characters. This is an internal integration limitation.

Rulebase Outcome

The rulebase outcome comprise multiple determined values, validation error(s) and error indicators. Make sure your rulebase’s output meets the expectations of the corresponding integration component:

  • A form rule algorithm C1-OPAVLAPRL expects the error_​severity and rule_​outcome indicators to be populated with numeric values. These values are mapped to the standard form rule parameters Exception Class and Rule Action and further interpreted by the product’s form rule engine. The error messages returned by OPA are captured as form exceptions.

  • A business service C1-DataAreaInvokeOPA expects that OPA returns a single error message and treats it as a regular application error. .

The product integration supports retrieving a single decision report associated with the root data model entity. This entity has a boolean attribute named xxx_​contains_​error that should be set to true or false by the rulebase.

If requested, the integration component stores the decision report and links it to the “owner” entity via log..

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.

Final Steps

The remaining steps for the integration involve configuring the components that invoke the rulebase.

Fastpath:

Refer to Configuring the Shared Data Model Integration for more information.