BRE pipeline framework
Imagine the basic message manipulation you do in your custom pipeline code already wrapped in as a set of ready-made BRE vocabularies, and all you have to do is just to drag these vocabularies into your policy and configure its parameters.
This ingenious idea was created by Johann Cooper, an integration architect in New Zealand, back in 2012 with the target of promoting messaging solutions. You can find his original blog posts here.
Simply put, the framework abstracts the common message manipulation in BRE vocabularies based on .NET facts that are in a GACed DLL. This allows you to have a rich set of ready-made building blocks to build your messaging solutions easily and much faster.
Here are the set of the powerful feature sets grouped in BRE vocabularies
To get started you only need to:
- Install the Framework MSI
- Import the vocabularies you are likely to use from X:\Program Files (x86)\BRE Pipeline Framework\Vocabularies
- Add the pipeline component to a custom pipeline(s), preferably add the custom pipeline(s) to a common BizTalk application which is referenced by your BizTalk application(s). X:\Program Files (x86)\BRE Pipeline Framework\Bin
As mentioned earlier, the framework encourages developers to leverage messaging solutions, instead of using orchestrations when it is not actually needed. Here are some common messaging scenarios where you can use BRE pipeline framework
1.Multi system invocation
Here you can leverage the caching and context instructions to call multiple systems without using an orchestrations, the caching is used to cache some info from the original request (1), to pass it to the second system (2) request along with the response from the first system,
While the context instructions are used to suppress the original response (2) from being returned by the BizTalk engine as part of the default behavior, so I just changed the Boolean value for (BTS.RouteDirectToTP) to False, and to allow the final response (3) to be returned back, I just set the Boolean value for (BTS.RouteDirectToTP) to True.
Check this article to know more about the built-in context properties used by BizTalk engine for the request-response pattern.
2. Dynamically Set Target System Action
This is a very common case, where you need to inject the Target System Action in (BTS.Operation) context property. During some migration tasks, I have seen organizations that use orchestrations just to inflate this context property!
Again, you could simply use the Framework’s context instructions inside the receive pipeline to set this context property based on the Original message context or may be even content.
3. Conditional Nullify
This is one of my favorite features, instead of using a Null Adapter to consume unwanted messages using port-level filters, with the framework, you could have any condition or a complex set of conditions in the message content or context that decide whether to Nullify the subscribed upon message or not.
One final thing to add is that the framework’s source code is also a great reference for writing your own custom pipeline components in terms of extensible design and development, it will also provide you with guidance with regard to some common pipeline component development caveats, example, check this 2014 article by Johann regarding reading promoted properties while still in the pipeline inbound stream.
This post is far from a comprehensive look into the possible use cases that can leverage the BRE pipeline framework, I meant to shed some light on it and I strongly encourage you to start exploring this framework for building & deploying powerful messaging solutions with ease.
For further information & demos, please check my recorded session in Integration Monday, you can find it here.
If you have not worked with the BRE pipeline framework, you are missing out!