Overview
This section contains information pertaining to the implementation of business rules within a typical data processing system. The biggest benefit of using rules technology is that it allows product designers to open up certain areas of the systems’ functionality to customization.
General control flow
The following diagram depicts a typical implementation of business rules in a system. Engineering teams should be able to implement and embed rules anywhere within the product’s workflows.
Workflow Steps
Since the rules, embedded in the workflow steps can be exposed for editing, it could be said that the systems’ workflow is customizable as well. This interpretation however might be misleading. The workflow is the actual application and business rules executed by the working steps represent some or all of the detailed logic of the steps.
​
The workflow itself wouldn’t be exposed for editing. For instance, product designers wouldn’t let anyone change the configuration of the workflow depicted in the above diagram by removing “step 2”. System users could be allowed to change “rule 1” that would be executed within the context of “step 2”, and since the results returned by this rule would affect the control flow after the rule is executed, the customization of the workflow would be achieved.
Rules
Since changing rules could either directly or indirectly change the logic of the workflow the responsibility of managing rules should be delegated with great care and access to the management functions should be governed by the security layer. Following sections delve deeper into this topic.
Invoking Rules
The two options for invoking rules are:
-
Embedding. Rules engine class is instantiated, and the rules are loaded and executed within the context of the calling object.
Note that all objects are operating within the space security context of the hosting process.
​
-
Calling web service. Rules engine class is instantiated within a separately running and managed process the access to which is exposed via web service methods.
​
Object of the application and web services are operating in different process spaces and security contexts. Thus, the security, networking and process life cycle configurations become significant considerations.
Managing Rules
When planning the rules-based system and the many ways that could be employed to manage rules, the architecture, security and testing are among the topics that need to be considered.
Hierarchical Structure
Rules, very much like files or batch scripts in the file system are usually organized in sets. Drawing parallels between rules database and file system is easy because the sets could be as folder structures, hierarchically organized. There is however a significant difference between rules and files. Rules could be executed by the rules engine as sets. This is one of the characteristics of rule sets that makes rules so flexible and the desired mechanism for product customization.
Zero or more rules could reside in sets. Below diagram illustrates this concept.
For instance, if a product ships for 4 subsets and one of them (set_step_4) is empty, no rule would be executed at “step 4” as shown in diagram 1. Customer would have the option to create one or more rules in this set, thus altering the default product behavior.
Repository
Internally, the rule scripts should be stored in database systems as text. The record structure that would contain the scripts should include the following fields:
Automatic Versioning
Every time the script is modified, a new copy of the script should be created with a unique identifier generated (guid) and the version number incremented. This structure will be sufficient to support the following features:
-
Rollback
-
Comparing different versions of the same script
-
Keeping track of script changes including the identification of users responsible for making changes
-
Relating execution of test cases to specific versions against which the tests were performed
Handling and supporting this feature would depend on the repository technology that would be selected. Following is a list of recommendations:
​
-
RDBMS
2. NoSQL
​
{
"scriptName" : "unique_name",
"versions" : [
{
"scriptID" : "guid",
"createdTimestamp" : "date_time",
"createdBy" : "user_id",
"version" : "seq_version_number",
"repoID" : "source_repo_token",
"testCases" : [
{
"caseID" : "guid",
"caseName" : "case_name_text",
"caseDescription" : "descriptionText",
"createdTimestamp" : "date_time",
"createdBy" : "user_id",
"version" : "seq_version_number",
"caseExecutes" : [
{
"execID" : "guid",
"execTimestamp" : "exec_date_time",
"inputParams" : "text",
"results" : "text",
}]
}]
}]
}
As an option, an entry could be created in source code repository (Git, TFS, SVN, etc.) for the versioned rule scripts.
Editing
Designing business rules requires certain amount of technical knowledge and training. Someone tasked with designing the rule would need to understand:
-
Business requirements
-
Data structures (metadata of the facts and resulting data)
-
Programming language and rule structures supported by the rules engine being implemented
-
In case of XengineXperts rules engine it would be JavaScript, XML and JSON
-
In case of JBoss Drools rules engine it would be Java, mvel, XML and JSON
-
-
Object-oriented programming in general terms (general knowledge, no deep expertise required)
As it most likely that the rules with which the products would be distributed would be designed and tested by engineering teams, meeting the requirements listed above would present no problems. However, the non-technical users who might be responsible for maintaining the rules might not possess the necessary training and technical knowledge to carry out the necessary programming tasks. For this reason, the system should provide the UI to accommodate both technical and non-technical user groups.
The following diagram outlines the life cycle of a rule and the stages that it might be going through within the organization.
Both expert and basic edit modes require that the system would grant access to perform rule management functions for:
-
Creating new rules
-
Changing existing rules
-
Configuring rules
-
Configuring overrides for rules and sets
-
Activating and de-activating rules and sets
Expert Editing Mode
An expert user would be able to utilities the facility of X-ruleStudio, Eclipse or similar IDE when creating and editing rules.
Basic Editing Mode
A user without a sufficient training in programming would require an assistance of the system when creating new or modifying existing rule scripts.
Overriding
The ability of the rules engine to override rules on any level is what actually makes rules a powerful concept.
​
Here is a common scenario:
-
A product is built and tested by the engineers and QA testers and has gone through all sorts of processes and now it’s released and deployed. One of the internal functions, let’s say a function that calculates salesperson’s commission, is built as a rule.
-
This particular rule’s script is written by an engineer and the formula on which the product’s business owner agreed is a simple calculation based on some percentage, let’s say 10% flat rate.
-
Several weeks after the product was installed a business manager decides that this rule shouldn’t use flat percentage but instead the percentage should fluctuate depending on the season and perhaps other factors.
-
Because the rule that came with the product is locked against any changes, which is a normal practice, business manager would need to create a new rule implementing his/her new algorithm. After it’s tested and the manager is satisfied with test results, he/she would direct the rules engine to override the original rule with the new one.
-
At any point the override setting can be removed, and the original rule could be reverted to, thus restoring the original functionality. “Override” is what takes rules-based products to the level of “self-service”.
Following is a list of overriding use cases:
-
Rule overrides another rule
-
Rule overrides a set
-
A set overrides a rule
-
A set overrides another set
Security Configuration
All access to rules management functions should be governed by the security layer. In order to create a flexible, granular and yet tightly controlled authorization system the rights and rules should be implemented.
Rights
Access rights should include “core” system rights that would be supplied with the default system configuration and “custom” rights that would be added and managed by the user community.
Core rights
Here are some sample rights:
-
allowed_to_create_rules
-
allowed_to_change_rules
-
allowed_to_override
-
allowed_to_create_folders
-
allowed_to_move_folders
-
allowed_to_rename_folders
-
etc.
Custom rights
Users with sufficient privileges (usually administrators) would create and maintain custom rights and control their assignments to systems and objects that would be used as facts. These assignments could control referential integrity for the rules engine to either allow or deny access to the facts.
​
For instance, when object of type Claim for which custom rights allowed_to_change_claim has been defined is sent to a set of rules for processing, the system would need to verify that the rules requiring modifications are operating with the context of the user for whom this right has also been defined.
Roles and Users
Within the context of rules, roles are merely collections of access rights. It is no advisable that more than one identity store be configured and maintained by any organization. The system should be able to consume user profiles by synchronizing its settings with security systems employed by the enterprise as a whole.
Testing Changes
After the rule script is changed it needs to be tested, just like any other software component. Unit tests should be performed using the data that would trigger various execution paths of the script producing both positive and negative results. Once the new version of the script satisfies and passes unit tests, the workflow step(s) or the workflow in its entirety would need to be tested.
Test Cases
Designing test cases requires detailed understanding of the business requirements, data structures that would be used as facts, and even the details of workflow steps. Objects that would be used as facts would need to be catalogued in the database and related to the specific versions of rule scripts. The system should be able to support running of either unit or integration type test cases, in both manual and automated modes.
