BizTalk RFID ships with the Business Rules Framework (commonly called the Business Rules Engine or BRE). BRE is a rules execution engine that allows you to dynamically create, publish, deploy, and execute policies without having to stop and restart running business processes. There is actually much, much more to BRE than my one sentence overview, but that is not what this post is all about.

In BizTalk RFID land, we can call our business policies within RFID Processes using the OOTB RuleEnginePolicyExecutor component. We can use business rules to filter and enrich RFID tag event data. Having created the policy, we add and configure an instance of the RuleEnginePolicyExecutor component to our RFID process. We configure the component to specify any database and/or xml facts to pass to the executing policy.

A good friend to business rule developers working with BizTalk RFID processes is the RfidRuleEngineContext class. It contains a number of properties and methods that make working with tag read event data very easy. An instance of this class is always passed to the executing policy by the RuleEnginePolicyExecutor component.

Ok, so there is some context for the post...

The Problem:

The other day, I had a BRE policy that, amongst other things, was updating SQL tables in some rule actions. I was calling the BRE policy from a BizTalk RFID process and all was working fine, until I noticed the database changes were not being made. I checked the process log file and verified the SQL update rule actions were firing...but the database facts were not being updated. Why?

Tip: Troubleshooting BRE policy execution within a RFID process is made easy by setting the process log level to Verbose. This writes all BRE tracking info to the process log file.

In BizTalk Orchestrations, when we update database facts in rule actions, we had to manually commit the changes on the SQL Data Connection (using an expression shape, not the call rules shape).

The Solution:

In BizTalk RFID we can use the RfidRuleEngineContext.UpdateDataConnections method to commit all changes on the SQL data connection(s) used during policy execution (the database fact we configured at design time). Keep in mind the message handling reliability setting (sometimes called the Tag Processing Mode) of your RFID process. If you have set message handling reliability to Transactional, BizTalk RFID will create a transaction scope over all event handlers in the process. That is, if any event handler fails, the transaction is aborted.

Mick's Tip: Include enlist=false; in your connection string when configuring the RuleEnginePolicyExecutor if you do not want your SQL data connection to participate in the transaction.

The Business Rules Engine is a powerful tool in your BizTalk RFID toolbox. If you have never used it before, check out the Walkthroughs for Creating and Using Policies in RFID Processes in the online help. There is also a great sample in the SDK as well.