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:
-
Determinations Server Location. This is the deployment
location of the Oracle Determinations server. It should be in the
format http://[server-name]:[portNumber]/[determinations server]. For example, http://myopaserver:0000/determinations-server. By default, the determinations-server directory is created
during OPA installation. However, OPA does not imposes a mandatory
directory structure, leaving it at the installation team’s discretion.
-
Web Determinations Location. This is the deployment location
of the Oracle Web Determinations. It should be in the format http://[server-name]:[portNumber]/[web
determinations location]. For example, http://myopaserver:0000/web-determinations. This definition can be used if you implement requirement to trigger
OPA web interview from the hyperlink placed anywhere on the portal
zone.
-
Rulebase WSDL Reference. This is the partial path of the
Assess
generic wsdl used for the integration. Combined
with the value of the Oracle Determinations Server and the
rulebase name it produces the full end-point URL for the rulebase
invocation. This attribute may refer to either a version-neutral or
a version-specific wsdl. Specify /assess/soap/generic/ unless
your business requirements dictate executing the historic version
of OPA rulebases. An example of a version-specific reference:
/assess/soap/generic/10.4/. Note that this definition is
applicable to all run-time interactions with OPA.
-
Rulebase List WSDL Reference. This is the partial path
pointing to the determination server’s wsdl. Combined with the value
of the Oracle Determinations Server attribute, it produces
the full URL of the wsdl. This wsdl described the
odsServer
service that the system invokes to retrieve list of rulebases
deployed on the Oracle Determination Server
-
Installed OPA Version. This is the exact version of OPA
instans participating in the integration. The precise version number
is necessary to ensure the compatibility of the generated data model
with the current installation. It should be in a format of N.N.N.N, for example 10.4.4.21
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 product supports the ability to generate rulebase data model
that is structurally similar to the data area’s schema.
- The product supplies a context-sensitive dashboard zone that contains
an action button that is triggering the generator. The zone also displays
the information about previously generated data models. The information
is displayed as a hyperlink that points to the OPA Rulebase Data Model
search. Another dashboard zone provides a complimentary ability to
view the plug-in spot schema.
- The product supplies a business service C1-DataAreaInvokeOPA to facilitate
the call to OPA. It is responsible for transforming the data into
the format compatible with OPA webservice request and includes logic
based on the outcome returned by the rulebase. Either updated xml
or an error message are returned. Business service input allows to
specify if call to OPA should return a decision report. You can specify
that decision report is either stored immediately as an attachment
or returned to the caller as a raw xml.
The following points explain the configuration steps required
by an implementer to implement a data area validation via rulebase.
- Generate the rulebase data model and save it locally with extension xsrc.
- Create a new OPA rulebase and add the data model file as properties
file. Develop, test and deploy the rulebase.
- Implement the call to the business service C1-DataAreaInvokeOPA, sending in
the data area and the rulebase name.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]