Configuring the Shared Data Model Integration

The topics in this section describe configuration required in the product for shared data model integration with OPA and provide high-level guidelines for OPA rulebases participating in this integration method.

The idea of this integration method is that an object in the product and the rulebase may share the data structure. Firstly, the entity is designed and defined in the main system. Then the entity’s data structure is described using a special xml format and stored in a file that can be imported into OPA rulebase as a data model. The similarity of the models allows seamless exchange of the information between the product and the OPA rulebase. The webservice interaction between the product and the OPA determinations server is completely encapsulated.

Generated Rulebase Data Model

The data model has to be generated for each individual OPA rulebase invoked using this integration method. The generated file is stored as an owned attachment linked to the source object, for example Form Type or Data Area. The product provides an OPA Rulebase Data Model BO (C1-OPARulebaseDataModel) to capture the data model xml. The product also supplies the OPA Rulebase Data Model (attachment) search.
Tip:

Multiple rulebases can be built on the same data model. For tracking purposes capture the rulebase name on the Generated Data Model attachment.

Note:

The product does not support an automatic synchronization between the source entity (such as Form Type or Data Area) and the generated rulebase data model. Manually propagate the minor modifications of the source entity to the rulebase properties. Regenerate the data model if you significantly modified the Form Type structure or the data area’s schema.

Setup OPA Integration Master Configuration

The shared data model integration uses master configuration to define the connection information to the OPA server, setup parameters for the data model generator and store default configurations for the OPA-based form rules. The product provides an OPA Integration Configuration BO (C1-SelfServiceMasterConfig).

Setup OPA Integration Configuration prior to an attempt to generate OPA rulebase data model for either a form type or a data area. For configurations related to the specific OPA installation, request the appropriate values from the installation team.

The the end-point URL for the rulebase webservice invocation is constructed dynamically at run-time. The URL is composed as: [port:host]/[determitation server deployment location]/[webservice wsdl reference]/[name of the rulebase invoked], for example http://myhost:0000/determinations-server0000/assess/soap/generic/MyRuleBase.

The master configuration defines parts of the end-point URL pertaining to the OPA sever participating in the integration:

At design time the following definitions are used by the rulebase data model generator services C1-DataAreaGenerateDataModel and C1-GenerateOPARulebaseModel:
  • System Name This is an alphanumeric code that identifies the current system. It is used internally by the data model generator and indicates the product that is triggering the generation process. Specify: PSRM.
  • Attachment Business Object. This is a business object that the system uses to store the generated data model. The product provides the business object C1-OPARulebaseDataModel for this purpose.
The following definitions are used at run-time for the webservice request:
  • SOAP Action. This is the definition of the SOAP action for the OPA webservice. It is version-specific and should include the 2–parts OPA version number. For Assess webservice specify: http://oracle.com/determinations/server/10.4/rulebase/types/Assess.
Note:

It is important to keep the master configuration in synch with the actual OPA installation. Verify the configuration every time a newer version of OPA is installed.

Configuration Required for Form Validation using OPA Rulebase

Consider implementing the OPA-based Form Rule if you intention is to validate the entire form at once and implement multiple business rules, verifications and calculations. In this scenario most infrastructure components are supplied by the product and only few configuration steps and business logic implementation in OPA are required:

Configuration Required for Data Area Validation using OPA Rulebase

The product provides the infrastructure allowing to process a data area using OPA rulebase. Most components are supplied by the product, but final steps are required by each implementation. To illustrate the details, we'll assume that there is a requirement to implement an eligibility rule plug-in using OPA.

Remember that the rulebase has no direct access to the product database and may not be able to retrieve additional information. Hence the preliminary processing logic supposed to gather all the information required to determine the eligibility. This logic could be implemented using Java or scripting. Next, the data should be passed to the OPA rulebase that in turn will determine the eligibility.

Here is what’s provided by the product:

The following points explain the configuration steps required by an implementer to implement a data area validation via rulebase.

Fastpath:

Refer to Defining a New Rule with Pre-generated Model for specifics about creating a rulebase with pre-generated data model.