In my last post I talked about the cool new feature in BizTalk 2006’s new Admin tool that gives easy access for doing per-instance pipeline configuration. As I mentioned that this isn’t a new feature but really just a new tool, since the feature is available in BizTalk 2004 as well as 2006.
For each pipeline (Receive Locations and Send Ports each have a Receive and Send Pipeline respectively, but if a port uses a Request-Response message exchange pattern it will also have a corresponding pipeline for the other direction, so the Receive Port will have a Send Pipeline and the Send Port will have a Receive Pipeline) the configuration database holds another piece of configuration. In the ExplorerOM this can be found as the ReceivePipelineData (on the ReceiveLocation or SendPort object) or SendPipelineData (on the SendPort or ReceivePort object) property.
This “data” is generally empty in most cases, but can be an XML document that overrides some or all of the properties of the components configured in the pipeline (note that the XML cannot add any addtional pipeline components). You can see the documentation for this feature in 2004 here.
So why is this useful? Sometimes (this can be especially true in larger BizTalk applications) you have multiple Receive Locations or Send Ports where you want to use the same components at each stage in the pipeline, but have some “instances” use the default configuration (the configuration set with the pipeline designer) but have other pipeline “instance” use slightly different configuration (maybe even just one property is different per instance). Using just the pipeline designer and the default tools built into 2004, you have to go through and create a new btp file for each of these “instances”. This can be painful especially if you have lots of pipelines to create.
The solution is to use the “PipelineData” in the configuration database to “override” the default configuration of the pipeline (again the “default” is the configuration given the pipeline in the designer when the pipeline is built). With this approach you create one physical pipeline file (btp) and deploy the resulting assembly. Then you can go to each “instance” of this pipeline (each time you configuration this pipeline to be used) that you configure and add per-instance configuration. This will allow you to change the runtime behavior of the pipeline without having to create a new btp file and deploy it. Per-instance pipelining can also be very useful when you are in the development phase as well, since you don’t have to re-compile or re-deploy a pipeline to change its properties as you try to fine-tune the exact property values you need.
My last post was about the coolness that is built into the Pathfiner MMC console that allows you to per pipeline instancing automatially. In 2004 you were stuck generating the XML by hand and using the ExplorerOM to set the correct “PipelineData” property. What better way to make this easier to do in 2004 but to emulate the tool they built for 2006? (For anyone who has read this blog for a while knows that I am all about the tools :)).
For this reason I sort of recreated the 2006 functionality for 2004. You can download the full source here -pipelineviewer.zip (442.34 KB).
Again the purpose of this tool is to allow easy per-pipeline instancing. To that end it is a windows forms application that you can use (by pointing it at a pipeline) and allows you to create a per-pipeline instance XML document that can be used to modify an existing pipeline’s components properties (again you cannot add components using this or any other means other than creating or re-compiling a pipeline).
Before I walk through the usage model – a couple of warnings:
1) If you use this tool – it will create an XML “instance” document that holds *all* the properties of the pipeline being used. The effect of this is that if you make a change to a pipeline – you will have to make a change with this tool.
2) To use this tool – you have to register a COM library (MyBizTalkSS.dll). This is necessary to get the property grid in this application to interact correctly with the editors the biztalk built-in pipeline components use (which actually is one advantage this tool has over the tool in the BizTalk MMC – since it uses the property grid – but doesn’t *yet* support the full design experience there – whether it will or not in a later beta or in the release I don’t actually know). If you open the VS.NET solution – the COM project will build automatically if you have VC++ installed. If you don’t have VC++ installed – go into the MyBizTalkbinrelease directory and register MyBizTalkSS.dll.
So let me walk through simple use case using the built-in XmlReceive pipeline (yes – per-pipeine instancing is useful for the built-in pipelines as well). When you open the PipelineViewer you get a blank screen that looks like this:
After you go to the File – Open menu you will see a list of all the pipelines you have in the configuration database (the connection to the management database is controlled via the configuration file – so if you are talking to a configuration database on another server or in a sql server named instance you’ll have to change the configuration file). You can see this dialog here:
Once you pick the pipeline you will see the stages (either for a receive pipeline or send pipeline depending on what pipeline you’ve picked) in the tree view, if you expand the stages you can see all the components that are configured at those stages:
Once you pick a component – you will see its properties in the property grid:
So for example – I could change the “Allow unrecognized message” property to true, which would allow this particular pipeline instance to behave differently than the default XmlReceive pipeline, without me having to create a btp file with the XmlDissasembler in it and then change that property and then deploy the pipeline.
The menu has the following options:
“Open” give you a list of potential pipelines.
“Add Schema” allows you to browse to an assembly that contains compiled BizTalk Schemas. The tool will add those schemas to the schema list for properties (like the Xml Dissasembler’s Document Schemas property) that use a list of schemas.
“Clear” nulls out the per-instance pipeline – resetting the pipeline to use the default values from the compiled pipeline.
“Save” saves any changes you’ve made.
“Exit” – pretty self-explanatory.
Hopefully some people will find this useful, but it was sure fun to dive more into the per-instance pipelining, and especially fun to get the property grid to work correctly outside of VS.NET (which was most of the challenge actually).