Installed BizTalk Server 2006 R2 – Service Pack 1 (SP1)

Installed the SP1 in our test server yesterday. It was pretty much a smooth ride with minor hurdles. I started off without reading the installation notes (as it’s in *.docx version and we still need to upgrade our MS-Word to latest version. We never felt the need of upgrading the MS-Word until now)

And these error messages didn’t provide much information to resolve. And same as the 13.6 MB log file.

Since our servers are not maintained properly in the recent time with regular reboots, I just rebooted the server and followed the instructions in the installation guide this time (Thought I would perform the installation properly this time, though the document doesn’t provide any clues for the above error).

I’ll emphasis on the followings to be considered before starting the installation:

• SP1-Updates the database schemas:
  • All BizTalk servers in a server farm or group should be updated with the service pack as this updates the database schemas.
  • Backing-up the BizTalk databases are important (as it’s the case for every service pack). If you want to uninstall the SP1 later for any reason, you must restore the BizTalk Server databases with your backup.
• I would always suggest to backup the master secret file.
• All BizTalk Server 2006 R2 hotfixes that are currently installed on the computer will be automatically removed by the service pack installation. Some of the hotfixes are part of the service pack, where some are not. So keep a note of all the BizTalk hotfixes in your server before the installation and compare it against the hotfixes which are part of this service pack(http://support.microsoft.com/kb/974563). If any of your hotfixes are not part of this service pack, you can install the SP1-compatible version later..atleast your note will help you to double check later.

  

• Installing BizTalk Server 2006 R2 SP1 does not change the version number of your BizTalk Server installation. Ours is still “3.6.1404.0” after the service pack installation. (the service packs of previous versions of BizTalk server updates the product version number) So to identify its existence later, Go to “Add or Remove Programs” check the “Show updates” check box and look under “Microsoft BizTalk Server 2006 <<Developer Edition>>” 

GAC it

Have you ever come across this error; I had an orchestration and a new requirement to update the orchestration with the BRE came in. After developing the orchestration, built the solution and deployed it in the test server. But the new code (executing the rule through Call Rule shape) didn’t reflect in the output. When I opened the orchestration debugger, there was a strange behaviour of the control flow. The control flow just jumped over the new code –the Call Rules shape, as shown in the below picture.

I have checked everything, and then later found that it’s because of the build error. When creating the executable for the application in the BizTalk administrator console, I have not added the updated assemblies in the “Resources” folder. This caused the mismatch to the User interface (UI) of the orchestration to the code behind of the orchestration. UI had reflected the newer version of the code but not the code behind!!!

Then created a new build, by properly including the updated assemblies in the “Resources” folder and GACed the updated assemblies. It worked as expected. So lesson leant is, do the basic things properly -“GAC IT”.

Calling .NET assembly or any out-of-box static methods in BizTalk Rule Engine (BRE)

Calling .NET assembly or any out-of-box static methods (like System.String.Concat etc) in BizTalk Rule Engine (BRE) is a simple stuff; there is not much documentation available for beginners.

For example, if the rule is

If CustomerType = ‘new’

THEN

WelcomeMessage = String.Concat(“Hello”, CustomerName)

In the above example, I need to use the “System.String.Concat” method from out-of-box mscrolib assembly (or any of your custom method from your helper class).

Executing from Orchestration:

Option 1:

By default, the rule engine requires you to assert all the facts, before they ca be executed. So to execute the rule which contains the .NET assembly or any out-of-box static methods, we must create an instance of the helper class and pass it as a parameter to the rules engine in the Call Rules shape.

So for the above rule, in the Orchestration

• Create an instance variable of type “String” - since we are calling the String.Concat() ( or the type of your helper class if you want to call a .NET assembly in your case)

• Passing the instance type as the parameter: In the “CallRules Policy Configuration” window, select the above created variable in the “Parameter Name” column.

Option2:

Modify the BRE’s behaviour of expecting us to assert the facts by changing the value of the StaticSupport registry key as specified in MSDN (http://msdn.microsoft.com/en-gb/library/aa950269%28BTS.20%29.aspx).

Registry key for 32-bit OS: [HKEY_LOCAL_MACHINE\Software\Microsoft\BusinessRules\3.0 ]

Registry key for 64-bit OS:[HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/BusinessRules/3.0]

For testing the rule in the BRE composer:

Follow: http://geekswithblogs.net/nsthompson/articles/ClassAndBusinessRulesEngineIntegration.aspx

I have not used the steps mentioned by Neil (in the referenced blog). I am not sure how we will use the fact retriever specific for “integrating the .NET” if you already using a fact retriever in your rule for some other purpose like caching the datatable/database connectionstring.

I have always used a test orchestration which invoked my rule. Yes, I have to deploy my rule before using the rule in the orchestration. That's the major downside of this method.