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.
Considering the last post concerned loosely coupled orchestrations, I thought it might be useful to demonstrate tightly coupled orchestrations. This method still can promote reuse as orchestrations can be called from multiple sources. We’ll use the same loan process diagram.
And here’s the layout of the master orchestration. In this case we don’t have a Send shape at the end because that’s being handled in the Archive Loan orchestration.
Orchestrations can have a few types of parameters, though I’ve only used message parameters before. Each message parameter is associated with a direction: the parameter can be passed in by value by the calling orchestration, passed out by reference to the calling orchestration, and there’s a ref option to pass in a parameter by reference.
In the PrepareLoan and GenerateLoanDocuments I create a copy of the message and assign a new status value to indicate that something has happened, since I’m not really doing any other work in the orchestration.
As the messages are being passed by reference between one another, there’s no reason for the messages to be written to the Biztalk messagebox, which can be quite a boon to performance.
Source code for this example can be found here.
At its heart, BizTalk is based on the publish/subscription model. As messages come in to the message box, BizTalk checks to see what orchestrations have subscriptions that match the criteria of the incoming message. This pub/sub model is opens up a new paradigm for developers in terms of programming. For this example we’ll use the following process diagram for lending:
A developer could create one monolithic orchestration to handle all the tasks shown above. The downside of this would be that the entire orchestration would have to be modified if steps were added to the diagram above, nor would we be able to easily facilitate reuse. Another option would be for the developer to create an orchestration for each of the steps above and then another orchestration to call the others and pass information between them. A more interesting option, however, would be to create separate orchestrations and have them activate as needed.
We can accomplish this by routing messages between the orchestrations. Messages are routed based on their context properties, so we’ll add a Status element to our basic LoanRequest schema and make it a promoted property.
After the task is completed in each orchestration, we’ll create a copy of the message and update the status to indicate that the task has been completed. After the new message has been created, it will be passed into the message box using a port that’s directly bound. The following orchestration will be checking the messagebox looking for messages where the status indicates that the preceding orchestration has been completed.
The following orchestration will have a receive port that’s directly bound to the message box. The receive shape that’s connected to this port will have a filter that’s looking for messages where the Status context property indicates that the previous orchestration has completed. For instance, we’ll look at the code in the Message Assignment block of the Prepare Loan orchestration.
Let’s also take a look at the filter expression for the Receive shape in the GenerateLoanDocuments orchestration.
So going back to the terms used at the beginning of this post, the PrepareLoan orchestration publishes a message to the messagebox which matches the subscription for the GenerateLoanDocuments orchestration and activates an instance of the orchestration. Similarly, the GenerateLoanDocuments orchestration publishes a message to the messagebox with a Status value of “LOAN DOCUMENTS GENERATED” that matches the subscription for the ArchiveLoan orchestration and activates an instance to consume the message.
As mentioned earlier, this type of model can more readily accommodate changes to the process diagram. We’ll use the updated process diagram below.
In order to handle this, we’d create an additional orchestration that handled the specifics of the Generate MIN logic and activate it with a receive shape that looks for messages with a Status of “LOAN PREPARED”. After the MIN logic has been performed, it will create a new message with a Status value of “MIN GENERATED”. Additionally, the GenerateLoanDocuments receive port filter would need to be updated so that the filter expression matched the new Status value. The direct bound ports are only logical ports and have no physical representations that can be updated within the BizTalk Administration Console, so this change can only be made at design time within Visual Studio.
This pub/sub model could also be used to promote reuse in orchestrations. Imagine that there was a new requirement that each step within the loan process be logged. To accomplish this, we could create another orchestration called LogProcess with a receive shape that had a filter on Status values of AUDIT. Each orchestration could be updated to create a message for auditing with a Status value of AUDIT and send it to the messagebox before sending the other message indicating that the orchestration had completed its task.
Source code for this example can be found here.