OpenRules Knowledge Repository for both QA and Production Processes

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
    • Decisions
      • Main
        • Decision.xls
        • Glossary.xls
        • Production.xls
      • Common
      • BusinessFunction1
      • BusinessFunction2
      • BusinessFunctionN
    • Tests
      • Datatype.xls
      • Data.xls
      • TestCases.xls
      • QA.xls
      • QA.java.xls
    • OpenRules
      • DecisionTemplates.xls
      • DecisionTableExecuteTemplates.xls

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.

Advertisements

About jacobfeldman

CTO at www.openrules.com http://www.linkedin.com/in/jacobfeldmanopenrules
This entry was posted in Decision Management, OpenRules Specific. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s