After a rules policy has been deployed, it is available for use. As previously discussed, the ruleset is represented as an XML blob in the BizTalkRuleEngineDb. To execute a rules policy, this XML must be ultimately transformed into a Rete network (which we covered at the beginning of this chapter).
The first stage requires retrieval of the XML from the BRE database. An object model is then created by using the Rules API objects, which we cover in the next section (which demonstrates creation of a rule via code rather than via Rules Composer).
After the object model has been created in-memory, a Rete network is then constructed. It is then used to execute rules. The entire process is called translation, and for obvious reasons represents a preprocessing overhead. To counter this overhead, BizTalk takes one of two approaches: the Rules Engine Update Service, which is registered as part of the BizTalk install, or a BRE cache.
The Rules Engine Update Service runs on all BizTalk servers in the BizTalk group and caches the rules policy XML for any BRE invocations on a given server. This optimization means that any rules policies being executed retrieve the XML rules definition locally instead of hitting the SQL Server each time.
To allow for live rules deployment without incurring downtime (such as stopping and starting BizTalk to flush the cache), the service subscribes to policy deploy and undeploy events. When it detects changes, it updates the cache ...