I have now released version 1.3.0 of the BizTalk BRE (Business Rules Engine) Pipeline Framework to the Codeplex project page. The goal of the framework is to leverage the business rules engine in BizTalk pipelines to evaluate conditions and perform actions against a BizTalk message’s content or context in a flexible manner which allows for an agile deployments since changes in requirements logic no longer require updates to pipeline components which can get messy (see this post for an explanation on how the framework works and how to use it). The v1.3.0 update of the framework aims to make the framework easier to use and extend the featureset of out of the box capabilities (note that this is a plugin framework so it can always be extended to cater for requirements that can’t be satisfied with out of the box features).
The first and largest improvement is that it is no longer necessary to use an InstructionLoaderPolicy (see the project documentation page for more information) to instantiate out of the box MetaInstructions before you can use them in your ExecutionPolicy. While the BRE Pipeline Framework still supports a plugin model it is no longer necessary to treat the out of the box MetaInstructions as plugins since they are now always loaded by the framework. What this means is that if the only features you want to use are simple context evaluation and manipulation then you don’t need to use an InstructionLoaderPolicy and just need to use the BREPipelineFramework.SampleInstructions.ContextInstructions or BREPipelineFramework.SampleInstructions.HelperInstructions vocabulary definitions in your ExecutionPolicy. Any pipelines that explicitly specify these out of the box components in InstructionLoaderPolicies will still work so not to worry about backwards compatibility.
Another improvement is the addition of the ThrowException vocabulary definition in the BREPipelineFramework.SampleInstructions.HelperInstructions vocabulary v1.2. This now gives you control to throw exceptions in your BRE policies when certain conditions are met. As you’ll see in the below screenshots the exception is caught and surfaced to BizTalk administrators in a very standard fashion.
Another feature that has been added is to add namespaces (with or without a prefix) to the root node of an XML message which doesn’t already have a namespace. These vocabulary definitions have also been added to the BREPipelineFramework.SampleInstructions.HelperInstructions vocabulary v1.2. I have previously discussed how custom MetaInstructions / Instructions could be written to cater for this but have now decided to cater for this out of the box.
I have also added a vocabulary definition to the BREPipelineFramework.SampleInstructions.HelperInstructions vocabulary v1.2 to help you resolve a party name by looking up the party based on alias name / qualifier / value pairs. These lookups would be done against a BizTalk Party business profile as below.
Running the below actions would result in the value BREPipelineFramework (the party name) being set to the BTS.Party context property. Note that this is based on the Microsoft CustomPartyResolution sample that you would find in C:\Program Files (x86)\Microsoft BizTalk Server 2010\SDK\Samples\Pipelines\CustomPartyResolution on your BizTalk server and illustrates how a regular pipeline component can be ported to the BRE Pipeline Framework. Note that this implementation will result in the BizTalk Management database being hit for the lookups every time the pipeline component is exercised so use this feature accordingly.
Adventures inside the Message Box 