I’d like to share experience of large OpenRules customers who create and maintain enterprise-level knowledge repositories. Such repositories usually contain two major components: 1. Decisions and Rules 2. Tests
All these components may have a complex folder/sub-folder organization that on the terminal level usually contains Excel files. The tests and test data with expected results are typically created in Excel tables utilizing OpenRules tables of the types “Datatype”, “Data”, and “DecisionTableTest”. These tables are used as an input for the Decisions and Rules during QA (quality assurance) processes. Contrary, in the Production environment the same Decisions and Rules use Java objects passed to the OpenRules Execution Engine from the actual IT system.
Thus, the same Decision and Rules are used for both QA and Production processes as described on the following diagram:
A typical OpenRules Knowledge Repository has the following file structure:
- Knowledge Repository
The file Main/Decision.xls contains the main table of the type “Decision” with the name of the highest level decision. It also contains the following Environment table:
This table includes the common Glossary and all decision and rules files distributed between sub-folders corresponding to different business functions. It also includes a reference to the standard OpenRules templates and to OpenRules methods defined in the standard library “com.openrules.tools”.
Sometimes, a Glossary can consist of several smaller glossaries defined for different business functions, e.g.
Usually the file BusinessFunctionNDecision.xls contains its own Environment table that includes all xls-files used by this business function including their own glossaries (if any).
The file Main/Production.xls is the main file that supports the production mode. Usually it contains contains the following Environment table:
It imports all java classes that specify types of objects used by Decisions and Rules. Here as an example we use one statement “import.java” that imports the Java package “com.company.product”. the actual Environment table may include many import-statements.
The file Tests/QA.xls is the main file that supports the QA mode. Usually it contains the following Environment table:
Instead of data types which in Production mode are defined in Java classes, here we use Datatypes defined in Excel file Datatype.xls. Instead of instances of Java objects that usually come from an application database, it uses data instances defined in Excel Data tables in the file Data.xls. An it also uses the test cases with expected results from the file TestCases.xls.
CONCLUSION. The described organization allows our users to create and maintain complex OpenRules-based knowledge repositories in such a way that same Decisions and Rules are used without any changes in both QA and Production modes.