You can share rules between rulebases with a common data model by building one rulebase as a module and then linking to this module from another rulebase.
This may be useful where there are:
Multiple teams working on one main rulebase read more Modules allow teams to work independently on sub-components of a ruleset and combine their work into a single rulebase.
Common rules that are used by several rulebases read more Modules allow rule developers to import a common set of rules and screens into other rulebases, avoiding the need to create and maintain common questions in multiple places.
Core rules that are deployed in different ways for distinct audiences read more Modules allow rule developers to create core determinative rules in one location while using separate Oracle Policy Automation projects to easily create distinct user experiences in deploying those rules for separate audiences.
Different combinations of the same rules used by multiple rulebases read more Modules allow rule developers to more easily model source material in which different combinations of the same criteria are used for multiple goals.
TIP: To see an example of a complete rulebase with a module, open and run the Income Support Benefit example rulebase project provided in the Examples folder in the Oracle Policy Modeling installation folder.
In the Project Explorer in Oracle Policy Modeling, select the folder that you would like the module link to be placed in (eg the Modules folder), right-click and select Add Module Link...
In the Open dialog box, browse to the module file (.rmod) that you want to link to. (The .rmod file is created when you build a module and is located in the output folder for the module's project.) Then click Open. The module's compatibility with the project will be checked (see Validation of a module upon linking below) and then, assuming there are no errors that need to be addressed, the module link will be added.
Once a module is imported, it will display in Oracle Policy Modeling as a read-only single source file, which will show the data model that was imported, including the complete definition of the entity, attribute or relationship as defined in the module. It will also show a set of rules that indicate the relationship between the base level and inferred entities, attributes and relationships and the data model items that prove it, but not any details of exactly how they are proved.
A key difference between adding modules, as opposed to other documents, is that adding a module doesn't copy it into that folder, but rather creates a link to the location of the module. The link location will be relative to the project's xprj file where possible, or absolute if necessary. This allows a module to be linked to without every person who works on that project having to have exactly the same file structure.
TIP: If you want to remove a link to a module from your project, you should right-click the rmod file in the Project Explorer and select Remove from Project. If you select Delete instead, the rmod file itself in the module's project will be deleted.
Validation of a module upon linking
In the process of adding a link to a module, Oracle Policy Modeling validates that:
The definition of any attributes/entities/relationships that already exist in the project match exactly, so that the corresponding attributes, entities and relationships can link together. If the data models match, it merges the rulebase and module. Any conflicts will result in build model errors which will need to be rectified before the project can be built.
The rule language of the module is the same as the rule language of the parent project. If they are different the module will not be imported. (It is OK for the project region to be different in the module and the parent project.)
A module with the same name does not already exist in the project.
Use entities, attributes and relationships imported from a module
When a module is imported into a project all the entities, attributes and relationships that are defined in the module’s public interface appear as if they were defined in a properties file in that project itself and can be used like any other item defined in a properties file. There is, however, one important restriction in that items imported from a module cannot be edited from within the parent project. To make changes to the module you need to edit the module's project and rebuild it. Similarly, you cannot make changes in the parent project that override the module's attribute, entity and relationship definitions. Consequently, if you additionally define an imported entity, attribute or relationship in a parent project you cannot define anything other than the text of that item.
Text substitution
Since you cannot alter the definition of an attribute imported from a module, substitution attributes will only apply up the chain and not down it. This means that any substitution attributes defined and exported from a module will apply to any other project that imports it. However, the reverse is not true, ie defining a substitution attribute in the parent project will not apply to any attributes defined in a module.
In order for second person substitution to work it has to be turned on in the main rulebase project and every module it includes. For example, say your rulebase consists of the following:
Now if the attribute 'the person' is defined and exported from Module 1, then it will also need to be defined as a second person attribute in both Module 2 and MyRulebase.
NOTE: Defining attributes or relationships in multiple modules and then importing them into a project can lead to inconsistent text substitution (or sentence forms) being displayed.
Define attributes, entities and relationships in multiple modules
If an attribute, entity or relationship is exported from multiple modules (or the module and its parent rulebase) then their definitions, including any metadata must match exactly. This means that you would need to change and redeploy multiple modules if you ever wanted to update the definition of the attribute/entity/relationship. (Having an attribute or relationship defined and exported from multiple modules in a project can also result in unexpected behavior in terms of text substitution and sentence forms.)
The recommended approach is therefore to define each entity/attribute/relationship only once and then import them into every other project that needs it.
For example, say a rulebase imports modules A and B, both of which need to use an attribute called 'the person'. Instead of defining that attribute in both modules A and B, it should be defined in another module which is then imported into both A and B.
Include the rules from an imported module
Including a rule from an imported module in a project is simply a matter of using the publicly-named attribute (from the module) in a rule (in the parent project). Note that you don't have access to anything inside a module that has not been exported (eg intermediate attributes), either to prove or to use in rule premises. You can have attributes with the same text in the parent rulebase and the imported module but unless the one in the module has been exported, these will not be auto-aliased together and you will end up with two attributes with the same text at runtime.
Use the translations provided in an imported module
Any translations provided in an imported module are exported. This means that a project using the module does not have to recreate existing translations for the contents of the module. These translations cannot be edited, however, from within the parent rulebase - any changes must be made in the module itself.
All modules imported into a project must also support all the languages the project does. (A module may support more languages than the project does but it cannot support less.)
TIP: The languages supported in a module can be viewed in the parent project by right-clicking the module link in the Project Explorer and selecting Properties.
Build and load a rulebase containing modules
You build a rulebase that contains modules in the same way you build a normal rulebase (ie Build | Build). This process creates a build-time copy of the module's interface file in the rulebase, which is later validated against the runtime version of the module's interface file. (At runtime you can update an individual module without having to update all the rulebases (or modules) that rely on it provided that the changes do not alter the interface definition of the module. See Deploy changes to a single module for more information.)
When you load the rulebase (ie in the debugger, regression tester, Web Determinations or Determinations Server), all the rules from all the modules are combined to form the final rulebase that is then checked for consistency, logical loops, multiple proven attributes etc. This means that:
you cannot have rule fragments that cross over module boundaries, and
your data models must align, and
logical loops and multiply proven attributes must be considered for the unified rulebase, not just for the individual modules.
Validation at runtime of a rulebase containing modules
In addition to the build time checks, a rulebase that contains modules is also validated by the engine when it is loaded. The validation checks that are carried out mirror those done by Oracle Policy Modeling at build time, with the following notes:
Maximum/minimum/regular expression validations get compiled out as custom properties so they will be reported as mismatches in custom properties if they are out of sync.
None of the properties relating to text substitution or text overrides get validated at runtime. Consequently, it is inadvisable to define attributes in more than one module or rulebase (see above). The engine does additional validation to ensure that the module's interface has not been modified since all the rulebases and modules that rely on it were compiled.
Since the engine, like all runtime validation, only reports the first error it encounters it is advisable to re-compile your head rulebase project after updating a module to detect any errors.
Data matching at runtime
Entities, attributes and relationships are defined by their ID and are compared according to the following criteria:
For an attribute to be considered the same it must have the same ID, base text (including parse) and data type.
For an entity to be considered the same it must have the same ID and text.
For a relationship to be considered the same it must have the same ID, reverse ID, text, reverse text, type, source entity and target entity. Additionally, the concept of primary direction is important such that a relationship defined as:
ID
Source
Text
Type
Reverse text
Target
Reverse ID
children
the child
the applicant's children
One-to-Many
the applicant of the child
the applicant
childsapplicant
will not be considered the same as a relationship defined as:
ID
Source
Text
Type
Reverse text
Target
Reverse ID
childsapplicant
the applicant
the applicant of the child
Many-to-One
the child
the applicant's children
children
Additionally, attributes, entities and relationships cannot change its inferencing type from base to inferred or vice versa.
Redeployment
It is possible to make changes to a module and deploy it without having to redeploy everything that uses it, if and only if the changes do not alter the external data model. In other words, the changes must be limited to changing the internal logic of the module. If the change affects the external data model, then you will need to rebuild and redeploy every rulebase/module that depends on it. (For more information see Deploy changes to a single module.)
Debug a rulebase containing modules
A rulebase containing modules is considered a single rulebase and you therefore debug it as you would any other rulebase (see Debug a rulebase for more information).
When you run the rulebase in the debugger, any attributes, entities and relationships that were not exported from your modules are shown with an ID of the form <module name>.<module document id>. For example, SimpleBenefits.b7@Rules_BenefitRules_doc is the attribute 'b7@Rules_BenefitRules_doc' that was not exported from the Simple Benefits module.
These attributes are shown in the debugger for completeness (eg so that you can see a proper decision report).
