Recently I've wanted to demonstrate using the BizTalk Rules Engine outside of BizTalk. In our post 9/11 world, everyone's probably had some contact with the heightened security and restrictions for air travel and banking transactions. Along the same lines, the Nuclear Regulations Commission often updates the rules concerning access control to nuclear power plants within the United States. Knowing the flexibilty of the BRE and the ease with which new rules can be added and deployed, I thought this was a good premise for my example.
For the purposes of this example, one of the assumptions is that a XML is provided to the system containing the information for the employee following the schema below:
Within the code this XML document is loaded into an XMLDocument variable, used to create a TypedXMLDocument variable, and then passed to Access Control policy within the BRE.
So then let’s look at the rules. The first rule to be executed is “Grant Access.” While probably not the best idea when handling real world situations, for the purposes of this example I grant access to the employee in question and then check criteria to determine if that access should be revoked.
The criteria used for this rule is just a way of making the rule execute every time. The BRE uses the RETE algorithm and other things I don’t fully understand but enjoy the benefits of nonetheless to generate an agenda of which rules to try based on the input. In this case I’ve declared a priority of 1 for the Grant Access rule to ensure that it is run before the other rules. Below is the text displayed within the Business Rule Composer for Priority:
So then we evaluate other things. Is the person requesting access currently employed? If not, deny access and add a <AccessDeniedReason> node.
Did the person pass his or her last drug test?
Was the last drug test performed within the last 60 days? Note here that the BRE calls an external function which takes in an integer represents how long drug tests should be considered valid, so if the NRC were to change it to 45 or 30 days, all one would have to do is update the parameter.
We submit the following access request and are denied access.
The following employee is granted access.
By determining whether or not the employee has access within the BRE, we’re afforded a high degree of flexibility when it comes to implementing new rules. If the NRC were to come out with a list of names that should be denied access, the developer could create a rule that would check first and last names against a database table. Source code for this example can be found here.