If you’ve downloaded the BizTalk Patterns Wizard in the last few days – please download it again. My internal QA dept (that would be me) failed and there was a bad dll in the last msi. Download it here.
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).
In BizTalk (2004/2006) pipelines are really a hybrid artifact. Some artifacts (like orchestrations) are compiled artifacts – meaning that the runtime just uses the compiled type to execute the orchestration. The effect of this is that you can change the code of the compiled artifact and affect the runtime behavior of your application by recompiling, placing the newly built assembly into the GAC and restarting your host (see my post on when you can do this versus having to undeploy and deploy). Pipelines – even though you compile them with Visual Studio into a compiled type are treated differently by BizTalk. The data they contain (which objects you want to run at which pipeline stages) is just really configuration – so the deployment step sucks the data into the configuration database, which makes pipelines really more of a configuration artifact than a compiled artifact.
In BizTalk Server 2004 it is possible to read in this configuration data from the ExplorerOM and modify it (on Receive Locations it is the ReceivePipelineData property and on Send Port’s it is the SendPipelineData property) essentially allowing you to make custom pipelines without having to recompile. This feature is there, but not well documented – and of course required you to write custom code to pull out the XML data for each Receive Location or Send Port you wanted to modify and modify the XML using one of the XML APIs in .NET.
In 2006 – next to each pipeline in the BizTalk Administration Console there is an editor button which brings up a property grid which lists all the properties of all the objects configured in that pipeline. Now you can change the behavior of a pipeline by modifying the properties during configuration (which you could do in 2004 – but only through custom code). This will cut down on the number of pipelines you will have to create for you apps, as well as make it possible to reconfigure a pipeline at runtime much more efficiently.
When running the BizTalk Web Services Publishing Wizard – there is a new check box on the port selector page that says “Merge all selected ports into a single web service”. There seems to be a limitation that all ports have the same message exchange pattern – but this is a really small but IMO significant improvement.