What if you need to import a bunch of BizTalk vocabulary rules (.xml files) into the Biztalk BRE (Business Rule Engine)? You don’t want to do it one at time using the Business Rule Deployment Wizard. The real question, is why Microsoft didn’t provide a batch version of that tool that does all the same features, or incorporate those features into the BTTask command.

Microsoft used to provide a tool called ImportExportRuleStore.exe. A reference to this tool can be found on Tallan Blog.

When you search on Microsoft site or MSDN, you can no longer find it nor download it, although there are some .exe copies of it on the old CodePlex site (under the BiztalkBatchBuild project). However, I didn’t want to download an un-trusted .exe. Apparently Microsoft never provided the source for it.

BTDF (BizTalk Deployment Framework) surely has some way to do import rules as well, but I didn’t dig through it. If they do, it’s probably in an MSBuild file.

At least part of that utility now seems to be replaced with a tool called “Microsoft.Practices.ESB.RuleDeployer.exe” in the Microsoft ESB directory (if you have that installed).

You can specify parameters of “-v filename.xml” to import a vocabulary.

See related blog where I have a PowerShell script to batch import all vocabulary files in a directory.

While the GitHub says it’s only for BizTalk 2013-R2 and lower, it’s just C# code that should work with any version of BizTalk, unless BizTalk makes some breaking changes in future releases. But it’s unlikely they would do that, as many customers have pipeline components and business rules.

Visual Studio 2015 Builds

To get it to work with BizTalk 2016, download the code from GitHub, and open it with Visual Studio 2015. Open the solution called BREPipelineFramework.sln. For each of the four projection in that solution, right click “properties” and set the .NET framework to 4.6 as shown below.

NOTE: I had to rename BREPipelineFramework.PipelineComponent.BRPEPiplineFramework.Component, a ridiculously long name, to something shorter, such as: BREPipelineFramework.PipelineComponent. The compile was given me an issue about exceeding the max file size. So in other words, my GitHub repository was something like C:\users\myname\Source\Repos\BizTalkPipelineFramework, and the subfolder structure within that just made some of the names a little too long.

I will add any additional notes here as I work with installing on BizTalk 2016.

Run GACUtil on these .DLLS

I used my PowerShell version of GacUtil to deploy the following four DLLs:

$dllpath1 = "c:\Users\MyName\Source\Repos\BizTalkPipelineFramework\BREPipelineFramework\BREPipelineFramework\bin\Debug\BREPipelineFramework.dll"
GacDll $dllPath1 

$dllpath2 = "c:\Users\MyName\Source\Repos\BizTalkPipelineFramework\BREPipelineFramework\BREPipelineFramework.Helpers\bin\Debug\BREPipelineFramework.Helpers.dll"
GacDll $dllPath2 

$dllPath3 = "c:\Users\MyName\Source\Repos\BizTalkPipelineFramework\BREPipelineFramework\BREPipelineFramework.SampleInstructions\bin\Debug\BREPipelineFramework.SampleInstructions.dll"
GacDll $dllPath3

$dllPath4 = "c:\Users\MyName\Source\Repos\BizTalkPipelineFramework\BREPipelineFramework\BREPipelineFramework.PipelineComponent\bin\Debug\BREPipelineFrameworkComponent.dll"
GacDll $dllPath4 

Create a Test Application Import Pipelines Assembly

I created a new BizTalk Application called BizTalk.Common, and imported the resource/assembly:
c:\Users\nealw\Source\Repos\BizTalkPipelineFramework\BREPipelineFramework.BizTalk2016\BREPipelineFramework.TestProject\bin\x86\Debug\BREPipelineFramework.TestProject.dll

This project contains the .btp Pipeline files that could be used for testing.
I chose not to run the full BizUnit test, as I didn’t want to take the time to install BizUnit, at least or today.

I then created a Receive Port and Location, and I was able to see and pick the pipelines from the BREPipelineFramework.TestProject:

Import Vocabulary and Policies

Import the BizTalk Business Rule Vocabularies:

“c:\Users\MyName\Source\Repos\BizTalkPipelineFramework\BRE Artifacts\Vocabularies\BREPipelineFramework.JSONInstructions.1.0.xml”

When I tried this, I got the error:
“Unable to load assembly BREPiplineFramework.JSON”. Earlier, I had not compiled this because we had not immediate need to do JSON. So at this point, I went back and compiled it and GACed it (after setting it’s .NET framework to 4.6 and building it).

then Import the BizTalk Business Rule Policies:
“c:\Users\MyName\Source\Repos\BizTalkPipelineFramework\BRE Artifacts\Policies\BREPipelineFramework.JSONPolicy.1.0.xml”

But then I realized there was a whole directory of vocabularies to import (25 files in this directory):
“c:\Users\MyName\Source\Repos\BizTalkPipelineFramework\BREPipelineFramework\BRE Artifacts\Vocabularies\..”

So I did some research, and found the Microsoft.Practices.ESB.RulesDeployer.exe replacement for the old ImportExportRulestore.exe utility. If you don’t have the ESB Toolkit installed, then you might have to manually import all 25 files.

So I wrote a little PowerShell to loop through the files in the directory and call that utility:

#
#  Import an entire directory of vocabulary files into BizTalk BRE (Business Rule Engine) 
# 
cls
$sqlServer = "DLBizTalkDev1" #not sure this is supported in this utility 
$commandPath = "e:\BizTalkServer2016\ESB Toolkit 2.4\Bin\Microsoft.Practices.ESB.RulesDeployer.exe"

$vocabDir = "c:\Users\nealw\Source\Repos\BizTalkPipelineFramework\BREPipelineFramework\BRE Artifacts\Vocabularies"
$files = Get-ChildItem -Path $vocabDir -Filter "*.xml"

foreach($file in $files)
{
   $processedCounter = $processedCounter + 1 
   Write-Host "Filename=$($file.Name)"
   $cmdResults = &"$commandPath" -v $($file.FullName)
   Write-Host $cmdResults 
 }

Rules (with static C# routines, such as PolicyChaining, or C# code that adds nodes to the XML), are working fine on XP but not on 2003 (or working on machine and not another). For example, we have a condition of 1=1, which should always fire, but if a static C# routine is found in the actions, then the rules does not fire.


See Richard Seroter’s blog. There is a registry setting that must be set to allow business rules to call a static C# method.

http://blogs.msdn.com/richardbpi/archive/2005/11/14/492489.aspx

Also note, if you change a C# program, and even re-GAC it, to get the Business Rule Composer to “see” the changes, you have to close and re-open the Business Rule Composer if you are using the test policy feature.

If you download the Policy-Chaining sample for BizTalk, it has an automated way of updating the registry setting. In it’s setup.bat.

@ECHO
@ECHO Setting the StaticSupport registry key to ONE
@REGEDIT /s AddStaticSupport.reg

The AddStaticSupport.reg include the following statements:
REGEDIT4

[HKEY_LOCAL_MACHINESoftwareMicrosoftBusinessRules3.0]
“StaticSupport”=dword:00000001