About Business Rules
Business rules allow nontechnical users to change the behavior of business processes at specific decision points. You can change the logic of the rule instantly, using the Rule Editor in the Management Portal. There is no need for programming or diagramming skills to change the rule, and there is no need to modify or compile production code for changes to take effect. The following figure shows how business rules work.
Suppose that an international enterprise runs a production that processes loan applications. The decision process is consistent worldwide. However, each bank in the enterprise has its own acceptance criteria, which may vary from country to country. Business rules support this division of responsibility as follows:
The developer of the business process identifies a decision point, by naming the business rule that will make the decision on behalf of the business process. The developer leaves a placeholder for that business rule in the Business Process Language (BPL) code by invoking the Business Process Language (BPL) element <rule>. The <rule> element specifies the business rule name, plus parameters to hold the result of the decision and (optionally) the reason for that result. Suppose we call this rule LoanDecision.
Wherever the <rule> element appears in a BPL business process, a corresponding rule definition must exist within the production. A user at the enterprise, typically a business analyst, may define the rule using the browser-based online form called the Rule Editor. This form prompts the user for the simple information required to define the business rule called LoanDecision. InterSystems IRIS® saves this information in its configuration database.
Any enterprise user who is familiar with the Rule Editor and who has access to it in the Management Portal can modify the rule definition. Modifications are simply updates to the database and can be instantly applied to a production while it is running. Therefore, it is possible for business analysts at various regional locations to run the Rule Editor to modify their copies of the rule to provide different specific criteria appropriate to their locales.
At runtime, upon reaching the BPL <rule> statement the business process invokes the rule named LoanDecision. The rule retrieves its decision criteria from the configuration database, which may be different at different locales. Based on these criteria, the rule returns an answer to the business process. The business process redirects its execution path based on this answer.
For ongoing maintenance purposes, the business process developer need not be involved if a rule needs to change. Any rule definition is entirely separate from business process code. Rule definitions are stored in a configuration database as classes and are evaluated at runtime. Additionally, rule definitions can be exported and imported from one InterSystems IRIS installation to another.
In this way, enterprise users such as business analysts can change the operation of the business process at the decision point, without needing the programming expertise that would be required to revise the BPL or class code for the business process.
A rule definition is a collection of one or more rule sets. A rule set is a collection of one or more rules. Each rule set has an effective (or beginning) date and time as well as an ending date and time. When a business process invokes a rule definition, one and only one rule set is executed.
You have several options for specifying a rule workflow using business processes, data transformations, and business rules. For a discussion of the options, see “Comparison of Business Logic Tools” in Developing Productions.
The remaining chapters in this book describe how to define business rules including how to create and use rule sets using the Rule Editor as well as how to invoke rules using BPL and using business process routing engines.
Rules as Classes
The Interoperability > Build > Business Rules (or Rule Editor) page enables enterprise business analysts to shape the logical decisions made by a business process in a structured way without requiring programming skills.
Additionally, Studio enables business process developers to work with business rule definitions as classes, for example:
/// Business rule responsible for mapping an input location
Class Demo.ComplexMap.Rule.SemesterBatchRouting Extends Ens.Rule.Definition
Parameter RuleAssistClass = "EnsLib.MsgRouter.RuleAssist";
XData RuleDefinition [ XMLNamespace = "http://www.intersystems.com/rule" ]
<ruleDefinition alias="" context="EnsLib.MsgRouter.RoutingEngine" production="Demo.ComplexMap.SemesterProduction">
<ruleSet name="" effectiveBegin="" effectiveEnd="">
<rule name="" disabled="false">
<constraint name="source" value="Semester_Data_FileService"></constraint>
<constraint name="msgClass" value="Demo.ComplexMap.Semester.Batch"></constraint>
<send transform="" target="Semester_Data_FileOperation"></send>
<send transform="" target="Semester_FixedStudent_BatchCreator"></send>
You can open a business rule as a class in Studio, edit the document, and save the changes. Changes saved in Studio are immediately available in the Rule Editor page. However, you may have to refresh the page to see them.
Package Mapping Rule Classes
Given that rules are classes, you can map rules to other namespaces. If you do so, you must recompile all the mapped rule classes in each namespace where you use them to ensure that the local metadata is available in each namespace.
For details, see “Package Mapping” in the chapter “Packages”.