The Vergosity Framework contains a business rule engine that allows you to implement simple or complex rules. Here is some information about business rules and how Vergosity implements an inference rule engine. This section will describe the anatomy of the Vergosity Rule Engine.
What is a Business Rule
A business rule defines or constrains some aspect of business – it will usually resolve to true or false. This is fairly straight forward – it is either this or that. It can be a comparison of values. A rule might check a target value to determine if the value is within a specific range. Business rules simply evaluate one or more conditions against a target to determine if the target meets the conditions. Sounds pretty straight forward, and it is. The Vergosity Framework’s Rule Engine is also straight forward and allows you to use a set of defined rules already implemented or you can define your own custom rules.
Simple Business Rules
A simple business rule usually determines if the target (the item under consider for the rule, or the input for the rule evaluation) meets a single condition. The rule engine contains a set of simple rules, such as:
The evaluation of the rule is what provides instructions to your business logic. During the runtime of the application, different rules will be evaluated. The decisions rendered by these rules provide decision points in your business application.
The target of the rule is the object under consideration. For a Password Format rule, the target will be the string value that represents the password. The criteria of the rule will be applied at the rule target. Can a rule have more than one target? Certainly, a rule could render a decision based on the evaluation of one or more targets supplied to the rule. However, it is more common to have a single target for a rule.
The criterion is the heart of the rule. It is used to determine how the rule’s decision is to be rendered. For example, the Password Format rule mentioned earlier could contain the following criteria:
- length is between 6 and 10 characters,
- must include alpha and numeric characters,
- and must include at least one (1) uppercase alpha character.
The implementation of the rule will have to consider the rule’s criteria against the rule’s target. If the target meets the rule’s criteria, the rule is rendered true.
The name of the rule can be used to describe the purpose of the rule. For example, a rule named “Password Format” implies that we are evaluating a password’s format. From the rule name we do not know what the criteria is for a valid password format. We are mostly concerned with a descriptive name for the rule. If the name contained criteria information and the criteria of the rule changed internally, the name would no longer reflect the rule’s purpose. Therefore, create rules names that are descriptive. Try not to include the criteria or evaluation information in the rule name.
- Password Format: This rule determines if the password matches the specified format (i.e., valid characters, invalid characters, required uppercase or lowercase, required numeric characters).
- Authenticated User: A rule of this name indicates that the rule evaluates that a specified user is authenticated or is not authenticated.
- Customer Has Credit: This rule evaluates that the specified customer either has credit or does not have credit.
The rule message is the information that is returned when the rule decision is false or no. It may also provide details about the rule target. For example, if we are considering the Password Format rule, a rule message might be: “The password is not valid. The password must contain at least one (1) numeric value and at least one (1) uppercase alpha character.” It allows you to provide a message to an audience. The message may be logged in the application’s event log with other details or may be used to display to the end user.
From my experience, I think there should be a friendly message, used for end users. For application events, you will want to use a completely different type of message one that may contain more details. You will want to provide enough detail information that makes the event log item useful. However, be careful not to include sensitive information about your user or application: passwords, database connection strings, or other secure information.
The Vergosity Rule Engine only allows for a single message. I think it would be beneficial to have an end user message for rules that could be used to provide information back to a user interface. A lot of my development is in the middle tier of an application. Any rule messages logged to the application event log is purely for debugging or monitoring application performance. Take the necessary time to create meaningful rule messages. A descriptive message with pertinent details in the application’s event log can save many hours of debugging when there is a problem. I have seen some very generic messages without a lot of detail that are purely useless when you are trying to handle an application issue.
Composite Rules (or Complex Rules)
A Composite Rule is a rule that contains a rule set – or a set of rules to evaluate in a single container of one rule. It may be a rule set of several simple rules discussed previously. It may be a rule set of simple rules in addition to one or more composite rules. You can think of a Composite rule as a collection of either Simple or Composite rules or both. This provides a powerful mechanism in your business logic. This means that you can compose (notice the wording here) a rule using other rules. Therefore, once you begin developing custom rules (either simple or composite) you immediately have the ability for rule reuse and rule composition. The evaluation of the rule set is handled by the rule engine, you only need to define what rules should be evaluated against the target(s).
Let us take our Project.Name value into consideration as a Composite rule. This means that we could compose a Composite rule using a set of Simple rules and call it ProjectNameIsValidRule. This composite rule will use the following Simple rules:
- Evaluate for null or empty string (StringIsNotEmptySpace).
- Evaluate for a range in the string length (Range<T>).
- Evaluate for a match against a regular expression (RegularExpression).
Now that we have a basic understanding of what a rule is, we can start building our own rules. If you do not need to or do not want to create custom rules, you can use the ones already defined in the Vergosity Framework.