Using the OPA Validation Form Rule

The base product provides a Form Rule BO that is designed to handle a large range of conditional validation, C1–OpaValidation.

The BO allows a business user to specify the OPA rulebase that implements validations and calculations that apply to the form data. The form rule also defines how to interpret the outcome of the OPA rulebase invocation. You should consider using this rule BO when significant part of form data validations is suitable to be implemented using OPA. In this scenario, your implementation should generate an OPA rulebase data model for the Form Type and develop the actual OPA rulebase prior to configuring the form rule.

Fastpath: Refer to Generating an OPA Rulebase Data Model for a Form Type for specific details about data model generation. Refer to Oracle Policy Automation Integration for more details about OPA.

Rule Details

The search for the OPA Rulebase name derives the results from the OPA instance that participates in the integration. Make sure your rulebase is deployed on the appropriate determinations server.

Rule Outcome Details

Your implementation can define fine-grained rule outcome interpretation. The rulebase output includes two numeric indicators: error severity and rule outcome. You may associate the values of these indicators with appropriate Exception Classes and Rule Actions. The configuration effort should be tightly coordinated with the rulebase author.
Note: We recommend establishing a set of values for Error Severity and Rule Outcome indicators and using them for the OPA-based form validation. Then use OPA Integration Configuration to define a default rule outcome mapping. These default configurations are copied to the newly created Form Rule and can be edited afterwards..

Exception Information

Fastpath: Refer to Configuring the Shared Data Model Integration for the OPA integration configuration details.

The outcome of the rule can vary because the rulebase performs complicated business logic and multiple validations. The rule may also report multiple exceptions. Nevertheless your implementation can define a single default Exception Class and Rule Action.

Additional Notes on OPA Rulebase

Implement complicated tax policies and laws. OPA provides a platform for turning the laws and instructions into executable modules. Business analyst may use an original tax documents as a source for the policy and implement it. A majority of validations and calculations that can be performed on the actual form data, without additional database interactions, could be implemented with OPA.

Validate the entire form with OPA. The entire form is passed to the OPA Rule and it is expected to perform multiple validations and calculations and return the modified form and the set of exceptions. OPA webservice call is relatively expensive performance-wise, therefore it make sense to consolidate as much business logic as possible into one OPA rulebase.

Writing OPA Rulebase with minimal knowledge of the base product. The base product provides the integration mechanism that supports the data exchange with OPA. Thus, the OPA Rulebase author works exclusively on the OPA module.

Multiple OPA Rulebases can be written with same data model. The data model is generated once and handed over to the OPA Rule author(s). It can be used in various OPA Rules linked to the same form type.

Share OPA Rulebases across the enterprise. The integration with PSRM Self Service supports import of the form type definition and it uses OPA as a form validation engine. The rulebase data model can be generated in either product for the same form type, and the OPA rulebase based on this model can be used by both products.