by stephen-w-thomas | Aug 29, 2006 | Stephen's BizTalk and Integration Blog
Working with helper .net classes with BizTalk is a common task.
Sometimes it can be easy to forget to GAC the latest version of the code when you go to test the solution on your local development box. With a simple Post Build Event, you can have your code automatically put in the GAC for you.
Adding the post build event is easy. Just go to the project properties of your helper class and select Build Events.
Enter the following under Post Build Event:
"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i $(TargetPath)
Now when you build your code your dll will be GACed for you.
by stephen-w-thomas | Jan 26, 2006 | Stephen's BizTalk and Integration Blog
Recently I have been working a lot with the BizTalk Rules Engine (BRE) that comes along with Biztalk Server 2004.
Rather than the more common approach of using the BRE inside a BizTalk Orchestration passing in XML messages, I have been working with the rules engine in a pure .net scenario passing in .net objects as facts and working with a long term fact creator.
This approach uses the available API to call the BRE inside .net and passes in an array of facts to be operated on. The long term fact is used on the policy and loaded into memory the first time the policy is called. The supplied facts are passed out of the called policy with updated / changed values based on the rules inside the policy. This is very similar to a ByRef call.
I have put together simple sample that calls the BRE inside .net code using .net objects as facts and a long term fact creator. Make sure you read the ReadMe.txt file for additional set up information.
Sample: Biztalk Business Rules With .Net Components Sample
Basically, to run the sample build the two .net assemblies and GAC them. Then, load the Rule Policy XML using the Rules Engine Deployment Wizard. Run the WinForm. Note it may take up to 60 seconds for the policy to first be callable – to bypass this just restart the RuleEngineUpdateService (because you are not really working with BizTalk unless you have to restart a windows service).
The Long Term Fact will be created once each time you load the form – so if you keep hitting run the LTF gets reused. I have code commented out that will write to the event log when the LTF is created.
Have fun!
by stephen-w-thomas | Jan 26, 2006 | Stephen's BizTalk and Integration Blog
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.biztalkgurus.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.
