RuleLab.Net Architecture
RuleLab.Net 
Web-based Business Rules Management
System (BRMS). Provides a Rules Designer GUI, a Business Rules Engine (BRE), an
XML Web Service, and an online Rules repository. Empowers business users with
the direct access to the Rules. Enables seamless integration with applications
supporting XML. Use it in our ASP model or host on your server.
RuleLab.Net enables business logic automation via a set of Rules stored and implemented separately from the application code. The Rules are expressed in an easily readable format and can be maintained through the internet environment. A rules-centralized repository and an application interface allow seamless integration in which business rule changes can take effect at runtime.
RuleLab.Net uses XML for interfacing with application data and expressing the Rules internally. In fact, every object of the RuleLab.Net user project is stored in an XML document that is available for download. The application data you pass to the BRE should be formatted in XML. By linking your XML data nodes with RuleLab.Net objects at design time, you can teach RuleLab.Net how to interpret your data model. This process is fully supported by the Rules Designer through an intuitive Web GUI.
The RuleLab.Net environment accommodates both system developers and business users managing the rules. RuleLab.Net consists of:
- Rules Designer, an online development and rule management environment where you can create all required rule-building blocks, define the rules, and test them on your data samples. Our easy-to-use web site arms you with the Rule Editor, Rule Browser, and other powerful screens for creating objects required for system integrity and linking with your data documents. Your Rules, as well as every other object you create in RuleLab.Net, are written into XML files that you can examine, modify, and upload back to the system.
- Rules Repository, an online SQL Server database where you store your RuleLab.Net Rules and other XML objects. It allows easy maintenance via the shared environment and rule execution via the BRE Web Service methods. Optionally, you can have your online content encrypted via a Key that only your team will know. You can always download all of your XML Rule files to your local machine, edit them directly in XML, and pass them to the BRE assembly should you decide to run the BRE locally. The Rules Designer provides basic Project support to help you organize your RuleLab.Net online XML documents, upload/download XML files, and share common definitions between multiple Rule files.
- Business Rule Engine (BRE), a forward chaining Inference Engine that processes the Rules and returns comprehensive XML results and execution logs that can be utilized in a variety of ways. You can run BRE through the Web Service, or, if you wish, you can download the BRE .NET component to install and run locally.
- Integration methods for implementing the RuleLab.Net BRE within your
application. You can choose between running the BRE locally or through the
Web Service. Linking the BRE objects with your application data is easy. Rule
Designer includes a dialog for associating your XML data document nodes
with RuleLab.Net objects (Atoms). The output of the BRE is written back
into your document, populating it based on rules that have fired. An
- Test environment where you can test your Rule processing on your XML data samples. Integrated with the rest of rule management online tools, the Test screen lets you instantly execute your Rules, review the detailed execution report and generate a Reasoning Rule backchain. We eliminate guesswork on why the Rule execution may have produced surprising results. Every step of every cycle is logged and displayed to the Rules developer down to the predicate level.
Our Rules editor and the Rules Engine allow you to know nothing about how your Rules are stored. If, however, it is beneficial for you to deal with Rule files directly, you will find that your rules and rule building primitives are stored in XML files in an easy-to-understand, open format.
At the heart of RuleLab.Net are the links between rules and application XML data. The rules that you create can only be evaluated when they are related to a context of data that you supply at runtime. The association between your data and the Rules is defined via XML References that tell RuleLab.Net about your data elements. References are built into Rule building blocks such as Atoms and Facts which in turn provide the foundation for composing the actual business rules.
The RuleLab.Net project consists of the following objects:
- XML Reference, a link between your XML data element and RuleLab.Net. It includes an XPath expression referring to a node in application’s XML data document, a unique alias that identifies this node to RuleLab.Net, type of data stored in the XML node (text, numeric, date, time, currency), and an attribute specifying whether this is node belongs to a loop within your XML document
- Atom, a group of XML References that has a meaning within your application. In RuleLab.Net, Atoms are basic rule building primitives. They serve 2 purposes: Fact templates and Data evaluation at runtime. When data is allocated through resolving References at runtime, Atoms relate your Rules to data context therefore enabling your business rule logic processing.
- Fact, data pre-assigned to an Atom in a specific context. Facts represent pieces of knowledge in a rule based system. They are stored in a repository and are utilized at runtime for comparing with Atoms related to data context.
- Natural Term, textual expression entered in plain English linked to the implementation logic. The implementation is composed of Atoms, Facts, formulas, predicates, data filters – same type of objects that the Rules consist of. Natural Terms are stored in a Vocabulary. They can be composed into a Phrase which in turn can be part of a Rule. Natural Terms can have parameters.
- Rule, a logical expression that evaluates an Atom/Fact based condition and assigns data to Atoms according to the condition evaluation result. A Rule consists of Preconditions, Conditions and Actions. Rules utilize Atoms, Facts, Vocabulary, calculation formulas, math functions, and data filters to parse and assign data values within your XML document.
Application XML data is an integral part of a RuleLab.Net project. The BRE process has one primary purpose: to return data updates to the application XML document. RuleLab.Net allows you to build the rule base around your data model, and it does that by applying the following:
- Application XML nodes get linked with Atoms. This is accomplished by uploading an application XML document template into the Rules Designer and creating an XML Reference for each node that you would like to apply Rules to, along with giving it an alias. If your data model changes, the XML Reference XPath expressions can be easily altered via the Rules Designer.
- A data type is selected for each node allowing formatted data entry in the Rules Designer and data syntax validation by the BRE at runtime. The supported types are text, numeric, currency, date, and time.
- The application XML data document is submitted to the BRE at runtime. An XML path specified for each node enables the BRE to read data from your data document for Condition evaluation as well as to write data values as specified in the Action part of the Rule.
- Missing data values, data that failed Conditions, syntax errors, and other messages that are returned by the BRE to the Application carry both the assigned alias and the XML path which lets the Application identify the data element.
RuleLab.Net provides support for loop structures as long as they do not contain nested loops. You can specify a node as a Loop Reference which allows you to create Rules with predicates such as “Any”, “Each”, “Maximum”, “Minimum” etc. and aggregate functions like “Number Of”, “Sum Of”, “Average”, and more. A Rule can also be applied separately to every group of loop items.
The default currency symbol is set to “$”. You have the option of entering another symbol via the Account Settings so that monetary fields are rendered in the Rules Designer according to your preferred currency type and monetary data assigned by the BRE is prefixed with the currency symbol.
Application database direct access
You can have RuleLab.Net
rules engine run SQL commands on your database
including selects, updates, inserts and stored procedures. The rules engine
will automatically execute your commands at runtime to move data between the
application XML and your database. Through entering SQL commands into the Rules
Designer, you can make the rules operate directly on your application’s
database.
RuleLab.Net Data Structure
RuleLab.Net stores objects of each type in an XML document. There is an XML document for XML References, a document for Atoms, and documents for Facts and Rules. Each document is written into a file. XML files are stored in the online database under your master login. They can be downloaded to your local box. Every RuleLab.Net XML file can be instantiated through the Rules Designer using the Project screen and the Editor tab corresponding to this file category.
At design time, the Rules Designer enforces many restrictions in order to maintain data integrity of the XML documents being edited. While it doesn’t prevent you from saving inconsistent information, it arms you with the validation that catches many issues. Rule developers will have to correct the problems identified by the validation before running the BRE. The result of using the Rules Designer is a set of files that should be passed to the BRE via one of the integration methods.
You can have multiple Rule files utilizing the same Reference, Atom, and Fact files. By the same token, you can have multiple Fact files referring to the same Atom XML file. At design time, you link Reference, Atom, Fact, and Rule files together into an online Project. At runtime, your application provides these 4 files as an input for the BRE. There is no Project constraint at runtime. The developer and the application are responsible for supplying RuleLab.Net XML files that logically belong together. Normally that would be a set of files from the online Project.
Rules Designer projects assist with organizing the files online. Each RuleLab.Net project is Rules-file oriented. A project includes one Rules file and 3 corresponding Reference, Atom, and Fact files. The project is only needed to link the 4 files together for online editing. When integrating, you will have to keep track of which RuleLab.Net XML files logically belong together. When running the BRE, you will supply these 4 files to initiate the BRE session. Additionally, there is an option of including a number of common Rule files with the main Rules file.
The Rules Designer is a web page that implements an integrated development environment where you can create and manage the Rules and other RuleLab.Net objects. The Designer offers an intuitive GUI, easy navigation, and powerful set of commands for Rule editing. No programming is required to build the rules. Your entire project can be composed through clicking and typing object names. Rules are presented in an easy to read syntax. When it comes to editing a rule, a full set of commands is available. The only syntax you will have to adhere to is the calculation Formula format which is easy and fairly common.
Rules Designer screens have Validate buttons that check the syntax and ensure data integrity across the files loaded into the Designer. For example, it will alert you if an Atom utilized by one of the Rules has been erased (most likely via editing offline and uploading Atoms files). Or, it will tell you that the Formula calculation result is incompatible with the Atom type it is being compared with. All error messages are click-through. Message links will take you right to the affected element.
Conditions, Preconditions and Actions
Each Rule consists of a Condition and an Action. Optionally, you can specify a Precondition that will disable rule processing if the Precondition is not satisfied. When the Rule is evaluated, it utilizes XML References to extract data values from your XML document and to write back the assigned values. Data-value extraction takes place in the Condition parsing.
Condition
The Condition is an IF-statement consisting of logical functions (And, Or, Not), comparison predicates (Equal To, Less Than, One Of, etc), data parsing functions (Sum Of, Text Length, Regular Expression, etc.), calculation formulas, Atoms, and Facts. Ultimately, the Condition compares groups of XML data references (Atoms and Facts) against each other to yield the true or false returns. If the Condition was not able to find data to evaluate its every Atom, then the Rule won’t fire. The following classification is used to describe various Condition processing outcomes:
- Rule Satisfied – all Atoms where related to data context
Rule Fired – the rule Action was evaluated and executed based on the Rules Conflict Set resolution
- Rule Not Satisfied – some Atoms could not relate their References to your XML data because referenced XML nodes where missing in your XML data document. This can be an intermediate state within multi-pass multi-cycle Inference Engine processing. Once/if the required data is assigned by other rules or your application, the rule in question will fire.
Action
Actions are groups of Atom assignments that are executed if the Rule condition is satisfied. Each Action may assign data to one or multiple XML nodes in your document. In addition, Actions can assign a value to a system variable that is utilized for Rule processing just like your XML Data Reference but is not stored within your XML document. The assignment result could be the final data assignment your application is looking for, and/or it can be data context resolution that other Rules are looking for. By assigning values to Atoms, an Action can enable other rules which would fail to fire otherwise.
If you would like the Rules to generate user messages, you can set an Atom to a text string that embeds other Atoms. The Action will replace them with data values at run time. Multiple messages instantiated by several rules can be concatenated within a single Atom string.
You may find it useful to dynamically generate user choices through building selection lists via an Action. An Action can add XML fields to the application XML document. The application GUI would then render them in dropdowns and listboxes.
Preconditions
A precondition is an optional logical statement that enables Rule Condition processing. A precondition consists of 2 parts:
- logical If-statement just like the Condition (same format)
- set of Satisfied Riles – a list of Rules that must be satisfied in order for this rule to process
You may find it useful to use a precondition in many scenarios. For example, you can control whether a particular empty data item should be treated as missing data or a blank. In other words, you can tell the Rule whether to fire or not if empty data is encountered. For data validation applications, you can use Preconditions to specify the required data that must be filled before data is analyzed by the Condition.
RuleLab.Net Business Rules Engine
The Business Rules Engine (BRE) executes the rules against application data. Rules are executed in cycles using event driven reasoning (forward chaining). The RuleLab.Net BRE implements an Inference Engine that processes the Rules. With each cycle, the BRE attempts to make all possible inferences from application data available through XML References. A rule can be evaluated by the BRE only when all data values specified in the Condition are known and when the Precondition is met. The rule fires if the rule condition evaluation was successful. As a result, the rule’s Action is executed. If the condition was satisfied, the Action parses the on-success clause, otherwise it carries out the on-failure clause. The Action may set data values that add to the set of known facts. With more facts available, new inferences become possible. The BRE continues its cycles until all inferences have been made.
When your application calls the Engine to initiate rule processing, it starts the Engine pass. Within each pass, the Engine runs in cycles until no more rules fire. Depending on rule conditions and actions, each pass may consist of multiple cycles. As long as at least one rule has fired in a given cycle, the Engine runs another cycle to evaluate the rules that have not yet fired. Once the pass is complete (no rules fire any more) the control is returned back to the application.
Your BRE session may consist of multiple passes. How many passes to initiate is entirely up to you. Only you and your application know the ultimate goals driving your system. Of course, if all rules have fired there is no point in starting another pass. But if the goals have not been reached while there are misfired rules, your application can supply the missing data and have the BRE run another pass.
With every pass, the BRE
returns an XML document containing the
Rule Priorities and Rule Conflicts
The order in which rules are evaluated is determined by the rules’ physical order and the assigned priority. The priority of rules in the main Rules document ranges from 1 to 10. Included Rules documents may feature higher priority numbers. Rules within the same priority level are executed according to their original order.
If multiple rules attempt to change the same Atom then the “rule conflict” occurs. The BRE resolves the conflict by granting the first or the highest priority rule the right to alter the object but it also returns the other conflicting rules through the State. Your application can overwrite the BRE’s default decision. For more information on custom conflict resolving, see the BRE State documentation.
When multiple rules target the same Atom, the one that will change it must be the first to fire or have a higher priority. To fire first, it should be physically (in the Rules Browser) positioned above the other rules. If a Rule within the conflict set has a higher priority but fails to fire in the cycle in which a lower priority conflicting Rule fires, then it can overwrite the target Atom within a cycle where its condition becomes satisfied.
Having higher priority, however, does not entitle a higher priority Rule to overwriting an assignment made by a lower priority Rule in one of the preceding cycles if the assigned Atom has been accessed after the assignment had been made. This situation might occur if the higher priority Rule’s condition is not satisfied in a given cycle but a conflicting lower priority one is satisfied, fires, and the assignment it makes is utilized in some other rule condition evaluation. The BRE keeps track of the assigned Atoms being utilized by subsequent Rules. The BRE will not allow changing them if the assigned value has become part of the subsequent rules evaluation process.
You have the option of
marking an Atom “overwritable” in which case the conflict issue will not apply
to it. Such Atoms can be changed by any rule at the time it is fired. For
example, you may want to mark the “total” Atom as overwritable if it can be
subsequently altered by several rules/formulas. Or, you would want to make the
“UserMessage” Atom an overwritable atom if multiple rules can add additional
text messages to it.
You can overwrite the default ruleset by selecting which rules to run and the order of evaluation. The rule selection document can be passed to the BRE at runtime as well as through the Test screen.
BRE workflow
The following steps take place at runtime when your application calls the BRE:
- The application loads up the RuleLab.Net project files: XML References, Atoms, Facts and Rules XML documents (or file names).
- The application loads its XML data document
- The application initiates BRE session by sending the RuleLab.Net files and XML data document to the BRE.
- The BRE validates application data against XML Reference types. If it finds any date, time, numeric or currency data invalid, it returns error(s) and terminates.
- The BRE extracts the rules – either from the repository or the XML document supplied by the caller – to identify the rules available for evaluation.
- The BRE runs multiple cycles until no rules fire. It resolves rule conflicts, assigns data within the Application data document, generates the BRE State document and responds with the updated data document and the State document.
- The application examines the State documents to analyze the resolved rule conflicts. If it needs to overwrite the default resolution then it alters rule action results using the info provided in the State XML. This step is optional.
- The Application examines both documents and decides whether the subsequent pass is required. If yes, it collects additional data and populates the returned XML data document with new data values, then sends it along with the State document back to the BRE.
- The process continues until the Application stops calling the BRE.
Developers --
The first step of building your RuleLab.Net application is defining the data model reflecting the business context. Assuming you already have an XML data model that needs a rule based component, the developer will have to work with business users to identify and label knowledge elements that will be utilized in the RuleLab.Net projects. They can be simply the existing XML data document nodes. Note that the aliases assigned to them in the RuleLab.Net can be made far more descriptive than the XML node name.
Business requirements to the rule based system will usually go beyond the existing XML data document. It should be expected to have more categories and relationships that would have to be formalized as Atoms and Facts. Some of them might already exist within your program code. Others will have to be worked out between the business analyst and the developer in order to fit into an automated solution.
As a result of the joint effort between business analysts and developers, a preliminary set of the building blocks - Atoms and Facts - should be created. It is a good idea to write down how each Fact should be interpreted by the system – in plain English. It will make Rules a lot more readable to business users and help you build a knowledge base. You will also need to decide how the Atom/Fact library might be utilized by multiple Rule files and preset your RuleLab.Net Projects accordingly.
Once you write up the basic building blocks of your desired rule based system, using RuleLab.Net should be easy for most developers. First you need to register and get a login. You will need to decide whether you want to have your RuleLab.Net content encrypted (this can be changed later on). Once you feel comfortable with the system, follow these steps to build your rule-based solution.
- Create XML files for storing References, Atoms, Facts, and Rules.
- Enter a list of XML References that will allow RuleLab.Net reference your XML data document. Give each a unique full text alias readable by business users. You can upload and use your existing data XML file for copying XML nodes into the RuleLab.Net Reference editor.
- Create Atom library (XML file) by entering Atoms that utilize the XML References. Give each Atom a unique alias readable from a business user’s perspective. An Atom may consist of multiple References that, when combined, make a single unit of knowledge or a Fact template. For single reference Atoms you can simply set a Reference as an Atom without creating an extra Atom entry.
- Build a Fact library (XML file) by assigning data to Atoms. For each Fact you enter you need to select an Atom that should be utilized as the Fact template. The Fact Editor lets you assign data values to each Reference exposed by the Atom. At runtime, the Facts created here can be compared against Atoms with same Reference set. You should assign each Fact a unique alias just like you did with Atoms. Since Facts represent specific pieces of knowledge, you have the option of entering Fact narrative description in plain English.
- Build the Vocabulary of Natural Terms.
- Enter your Rules utilizing Atoms, Facts, and the Vocabulary. The Rule Editor includes several popup dialogs for you to create Preconditions, select Atoms/Facts and data parsing functions, choose comparison predicates, enter data constants, formulas, etc. Except for formulas, you will only be picking predefined objects. The interpretation of your editing is displayed in an easy-to-read syntax with clickable/updatable entities. Validate and Save each Rule as you enter them.
- Review the Rule list in the Rule Browser screen. If desired, edit rules and enter Precondition dependencies on other rules – the satisfied rule set. Validate the Rules to resolve any potential conflicts and ensure that all required elements are filled.
- Go to the Test screen to run your Rules against a sample Data Document. Review the output and make corrections if needed. Use Reasoning to backtrack any assignment made by the BRE to the Rule chain that led to it. You can go between References, Atoms, Facts, Rules, and Test screens as often as you like. Just be sure to save your changes before testing the rules.
- Download your RuleLab.Net XML files. You can review, modify, and upload them back if you want. When uploaded, they replace files in the database. These files are required for integration but if you are going to run the BRE via the RuleLab.Net Web Service off our web site then you don’t have to know anything about these files besides their names.
- Integrate your application with the RuleLab.Net Web Service or the offline BRE.
- Create a policy for the updating of Rules by the business users. If the BRE Web Service integration is used then any Rule changes made online may immediately become part of the production application. Instruct business users to use the Deployment command of the Rules Designer. With the offline BRE, updated XML files will have to be downloaded either manually or automatically via the RuleLab.Net Web Service’s download methods.
- Create additional logins with restricted access and turn the Project(s) over to business analysts. Normally, business analysts will only work with Rules but they can also create/update Atoms and Facts.
|
Business Analysts –
RuleLab.Net gives you the ability to define application logic in your terms, unwire it from the program code, and modify it on the fly to support changing business requirements. Business analysts should work with the developers to produce a basic set of Atoms, Facts, Natural Terms, and Rules. The developer should integrate RuleLab.Net with the application and test it on the initial Rule set. As a result of this process, the developer should deliver the following:
Business analysts can use the system to do the following:
If multiple users are going to update the system, decide who and when should be making changes to avoid conflicts. Note that the system provides limited capabilities of protecting data from overwrite by concurrent users. There is no data locking but RuleLab.Net’s Rule Designer watches for multiple users logging in and updating same data. It gives warnings and confirms user actions accordingly.
For more information on how
to manage RuleLab.Net files online and deploy changes into the production,
see the Project Screen section. |
|
Once your team masters the initial stage of designing and integrating your rule based system, you will have a shared rule repository available for secure browsing/editing from anywhere on the internet. Your business rule changes will be picked up by your software application and applied to the runtime data.
Learn more
about the RuleLab.Net online service (ASP model)
Managing RuleLab.Net projects.
Security of the online content