Over the course of the past few weeks, I found several different ways to completely break the Business Rules Engine. The common error I received is “Failed to Load”. I received this inside the Policies, Vocabularies, and when Importing the rules from XML.



The error looks something like this:


<IMG src="https://www.stephenwthomas.com/pics/BRE_FailedToLoadPolicy.JPG" P?


So why did this happen?


It seems to be caused from two reasons. Either one of the .net classes used inside the rules or vocabulary has changed (example: you are calling a method called AddCat(String) and now it is AddCat(int)) or the .net assembly is not in the GAC. The second is easy to fix by GAC’ing the .net components used in the rules. The first is more difficult.



To correct the first cause of the Failed To Load problem I have found two ways. Neither is very elegant.



The first way to get the vocabulary or policy to load is to manually edit the changed values inside the exported XML version of your rules. It seems the best thing to do is actually remove the whole function that is causing the problem. Now, this approach does not work very well unless you have your rules exported as XML.



The second way to correct this problem does not require the rules to be exported. It is to change the .net code back, re-GAC it, close the rules composure, reopen it, remove the uses of the code you want to change, save your rules, change your .net code, GAC it, change your rules to use the new .net code. Simple!



The moral of the story is to be cautious once you start using .net components inside the rules engine. If you need to make changes to methods used inside the rules, either version your .net code or plan ahead for your changes by removing the usage prior to making the change in the .net code.



Some other things to think about are:



– When working with a remote rules store, all .net components used must be installed locally in the GAC. Yes, this means that any business user who wants to view or update any rules through the rules composure must have all the .net components on there desktop. Not only that, they have to be the current version of the .net assemblies or the rules will not load.



– When working with Collections and ArrayLists you need to create your own Add method. You do not have access to the .Add property on the .net object.



– When deploying rules to the rules store the .net components have to be installed on the local computer.



Do not let this scare you away from using .net components inside your rules or to call your rules purely from .net. The Business Rules Engine has a lot of powerful features and best of all it is included with BizTalk Server 2004. Using .net helper classes and objects can greatly simplify rule development and decrease development time.



Updated: Sorry, original post said increase development time. I think using .net could help decrease development time.