Web Rule Basics

Web Rule is an ASP.NET and MVC server component that allows creation, modification, validation and evaluation of complex business rules. Using its web interface, business users can create rules by selecting options from a series of context-sensitive drop-down menus. This IntelliSense-like approach is unique for web-based business rule management. With Web Rule integrated into your project, it requires no knowledge of programming languages to author the most complex business rules.

The concept of Web Rule is quite simple: create a business rule online using the Rule Editor, save it anywhere as XML document and evaluate any number of instances of your source object against it using the Evaluator class.

Web Rule is not an "environment". It only provides a way to create rules and evaluate them. Contrary to most traditional business rule management systems, that come as independently installed processes, Web Rule is a server component that was designed to be an internal part of your new or existing ASP.NET or MVC web application, at least the rule authoring part of it. As such, it does not include rule debugging, versioning, rule access authorization mechanism or any other functionality that helps managing your rules. You web application is your "environment". If needed, all that functionality can be implemented by using standard APIs and tools that are built into .NET framework and Web Rule.

All this is true for rule authoring. Rule evaluation is a bit different, though. When rules are created and ready to be used, Web Rule provides an extremely easy way to evaluate your rules against source objects by any .NET process, service or program, not only web applications. You can have any number of Windows, WCF or any other types of services, running on different parts of the Globe, all receiving data from different sources. Those services can retrieve rules from the common storage and execute them against incoming objects, inspecting the result of each execution and acting accordingly, or letting actions inside of each rule carry over the processing of the object.

Another unique feature of the Web Rule control is its use of parentheses to prioritize evaluation of each condition in the rule. This dramatically simplifies the rule creation and modification process.

Below is the list of elements behind Web Rule technology that you need to understand in order to successfully author and evaluate business rules:

Rule. Web Rule supports two types of rules:
- Evaluation type:
  
  Check if ( A is equal to [10] or B has any value ) and C is greater than A
- Execution type:
  
  If ( A is equal to {[2] + B} or C is less than A ) and B has no value then Do else Do Not
Supporting multiple rule types gives applications and rule authors much greater flexibility in fine-tuning business processes. Make sure to read their respective topics here and here.

Each rule consists of rule elements which we will refer to throughout this website:
- Flow: Elements if, else if and else are flow elements. Element if is required, others are optional. Evaluation type rules use only the if flow element. In execution type, flow elements divide rule into sections. Each section must have its own action. The action will be invoked only if the entire section evaluates to true. The default English display names of all flow elements can be changed by using custom Help XML files.
- Fields: Elements A, B and C in the examples above are rule fields. They represent properties of the source object, in-rule methods or reusable rules. By default, each field or method displays its name as declared in the class. This can be changed by decorating fields and in-rule methods with the FieldAttribute or MethodAttribute respectively.
- Operators: Elements is equal to, has any value and alike are rule operators. They represent equation operators =, <, > and others. By default, operators are displayed as English phrases such as is greater or equal to instead of ≥ which makes it easier to work with for non-technical users. The default display names of all operators can be changed by using custom Help XML files.
- Values: Elements [10], {[2] + B} are field values. Rule authors can use calculations, input or other fields to set field values in rules. Values do not have their own attribute class. Their settings, such as minimum or maximum allowed value, case sensitivity, date format, and so on, are normally controlled by the FieldAttribute or MethodAttribute.
- Conditions: Condition is a combination of field-operator-value. Each rule section must contain at least one condition, otherwise the rule doesn't make any sense.
- Clauses: Evaluation type rules use only two clauses - and and or. Obviously, they act as && and || operators of most programming languages. The execution type rules include then clause. It "attaches" a particular rule action to a single flow section. The default display names of all clause elements can be changed by using custom Help XML files.
- Actions: Rule actions are used only in execution type rules. They are public void methods of the source object or any other .NET public class. Action methods can be instance or static, have overloads and be parameterless or take any number of parameters of value types or source object type. By default they are displayed as the method names they represent. Parameterless actions display no signatures (no parentheses), i.e. they appear on UI as regular fields - no need to bother rule authors with parameters if they are not needed. The Do and Do Not elements in the above rule are the examples of parameterless actions. All aspects of rule actions can be controlled by ActionAttribute, ExternalActionAttribute and ParameterAttribute classes.
- In-Rule Methods: In-rule methods play the same role as rule fields except they are actually methods of source object or any other .NET public class. In-rule methods are invoked by Evaluator class during the rule execution. Rules of both evaluation and execution type can use in-rule methods. The .NET methods they represent must return a value type (except for System.Guid and nullable enum). They can be instance or static methods, have overloads and be parameterless or have any number of parameters of value types (except for System.Guid and nullable enum) or parameters of the source object's type. Parameterless in-rule methods display no signatures (no parentheses), so they appear as regular rule fields to the rule author. All aspects of in-rule methods can be controlled by MethodAttribute, ExternalMethodAttribute, ParameterAttribute, and ReturnAttribute classes.
Most traditional rule engines call each rule condition a single rule and combine those rules in rule sets. One of the goals of a rule set is to handle the priorities of evaluation for each rule. So, a typical rule set would look like this:
```
ruleset:
	// rule # 1
	priority: 10
	when: color = "red"
	then: action 2

	// rule # 2
	priority: 1
	when: color = "green"
	then: action 1

	// rule # 3
	priority: 100
	when: color is undefined
	then: action 3
end
```
Because Web Rule handles the evaluation priority of each condition in complex rules automatically by using parentheses and/or flow elements, there is no need to combine conditions in sets. Everything inside the rule area is called rule. This simplifies rule authoring and makes it much easier to use for non-programmers. The above rule would look very different in Web Rule editor:
```
if color is equal to "green" then action 1
else if color is equal to "red" then action 2
else action 3
```
Source Object. Source objects are .NET classes your rules are evaluated against. In the BRE community these objects are also known as fact sources, fact objects, or just facts. Any .NET public class can serve as Web Rule source object, provided that it meets the following simple rules:
- For evaluation type rules, the source object itself or any of its public members have to have at least one public property of value type. Web Rule "scans" the source object for those properties and uses them as rule fields.
- In addition to that, the execution type rules require source object to have at least one public void method that would be used as rule action or reference at least one external action
Although perfectly acceptable, you would rarely use a plain .NET class as a source object for your rules. Almost all its members can be greatly customized by using attributes included in CodeEffects.Rule.Attributes namespace. Please read topics on source objects and attributes for details.
Asp.RuleEditor and Mvc.RuleEditor classes. These are the classes that encapsulate most of the functionality for rule authoring (but not rule evaluation) in ASP.NET and MVC respectively.

The CodeEffects.Rule.Asp.RuleEditor is used in ASP.NET pages and controls. It inherits from the standard System.Web.UI.WebControls.Panel, giving developers an easy way to add the Rule Editor to any control collection on their pages. Download the ASP.NET demo project to see the full implementation of this class. The minimal markup that registers CodeEffects.Rule assembly and adds Rule Editor to an ASP.NET page is very simple:
```
<%@ Register assembly="CodeEffects.Rule"
	namespace="CodeEffects.Rule.Asp" tagprefix="rule" %>

<rule:RuleEditor ID="RuleEditor1" runat="server"
	SourceAssembly="AssemblyName"
	SourceType="SourceObjectTypeFullName" />
```
Asp.RuleEditor class uses some members of its base type and implements lots of its own properties and methods. Read class' topic to get details on each member. Only three properties are required when you add control to the page:
- Server ID. As any ASP.NET server control, Rule Editor must have its own ID.
  
  SourceAssembly. This is the full name of the assembly that declares the type of source object. The easiest way to get this name is to right-click the source object's assembly in the References folder of your project and select Properties. The value you are looking for is listed as (Name) on the Properties panel. Alternatively, you can get this value as Assembly.GetAssembly( SourceObjectType ).FullName.
- SourceType. This is the full name of the source object's .NET type. Typically, it's namespace + "." + type name. You can also get it as sourceObjectInstance.GetType().FullName.
The CodeEffects.Rule.Mvc.RuleEditor is used in ASP.NET MVC applications. Normally, it's accompanied by an instance of the Models.RuleModel class as a property of view's model or object in ViewBag. Download the ASP.NET MVC demo project to see both classes in action. The MVC code required for the Rule Editor is more complicated than its ASP.NET sibling. This is because MVC pattern is not really a "component friendly" environment:
```
<div>
	@{
		Html.CodeEffects().RuleEditor()
			.Id("ruleEditor")
			.SaveAction("Save", "Post")
			.DeleteAction("Delete", "Post")
			.LoadAction("Load", "Post")
			.Rule(ViewBag.Rule)
			.Render();
	}
</div>

@{
	Html.CodeEffects().Scripts().Render();
}
```
At the very minimum, the MVC.RuleEditor has to instantiate at least these properties:
- ID. MVC uses this ID to serialize RuleModel in certain actions.
- Actions. Unless the Rule Editor is used in Ajax application or its Toolbar is disabled, MVC.RuleEditor must specify actions to load, save and delete rules and controller that declares those actions.
- Rule model. Controller has to create an instance of RuleModel class and pass it to the view.
CodeEffects.Rule.Core.Evaluator class. This class provides the functionality to evaluate rules created with RuleEditor classes. Its extremely simple implementation hides its truly remarkable capabilities. Make sure to read the details in Evaluator-related topic.
```
string rule = ruleEditor.GetRuleXml();
Evaluator<SourceObjectType> evaluator = new Evaluator<SourceObjectType>(rule);
bool success = evaluator.Evaluate(sourceObjectInstance);
```