Developing Business Rules
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 an enterprise runs a production that processes loan applications consistently across an international enterprise. The decision process is consistent worldwide, but banks must adjust the local acceptance criteria 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 a 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.
InterSystems IRIS provides four types of business rule definition:
Each type has an associated rule assist class that controls how the editor works and provides a Rules Assistant in the right pane while you are editing.
You create rules for a definition that are grouped into rule sets. Each rule definition has one or more rule sets. Each rule set is associated with a beginning and ending effective date and time. Each time a process invokes a rule, one and only one rule set is executed.
Note that there is overlap among the options available in business processes, data transformations, and business rules. For a comparison, 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.
The Interoperability > Build > Business Rules page provides a structured way for enterprise business analysts to shape the logical decisions made by a business process, without needing any programming skills.
However, a business process developer can instead work with business rule definitions as classes, using Studio. The following figure shows this format.
/// 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 visible in the Rule Editor. If you do not see your changes, simply refresh the page.
Package Mapping Rule Classes
Since they are classes, you can map rules to other namespaces. If you do map rule classes, you must recompile all the mapped rule classes in each namespace where you use them to insure the local metadata is available in each namespace.
For details, see “Package Mapping
” in the chapter “Packages” in Defining and Using Classes
Content Date/Time: 2019-10-14 06:57:37