BizTalk Versioning Strategy (4/4)

Previous part available here.

Really speaking, versioning problem is not the same for each biztalk artifacts:

Orchestrations

Orchestrations, for example, are not referenced by any other artifacts and therefore, can be updated with the Modify procedure descripted in the previous part without any risk replacing the old orchestration with the new one.

If we want to publish a new version of an orchestration keeping the old version up&running (a often necessary step in presence of long running processes) we can: BizTalk will host the new orchestration and the old one and will let us keeping both active or switch from the old to the new atomically.

Pipelines

Pipelines, as orchestrations, are not referenced by any other artifact (well, orchestration could reference pipelines in some cases even if I don’t recommend them) therefore Modify approach should suffice to replace an existing pipeline with another.

But if pipeline is referenced by ports in other applications obviously the modify will fail.

A quick workaround could be moving temporary all ports in the application containing the pipeline through the administration console, do the Modify, and move back ports to original applications.

In case the workaround will fail too one may increase the version number of the pipeline and redeploy it.

All ports will continue to use the old version and, if needed, WMI scripts can be written easily to move all ports references of the old version to the new version automatically.

Maps

Maps can be used by orchestrations (again, I’m against that kind of usage, maps should be used mainly on ports) and therefore Modify approach may or may not work.

And, as with pipelines, if maps are referenced by ports in other applications the modify will fail but, as with pipelines one may try to move every port and/or orchestrations referencing it to the same application and try to Modify.

If everything else fails one may increase map version number and deploy it.

Ports will continue to use the old map version and, if needed, WMI scripts can be written easily to move all port references of the old map version to the new one automatically.

Orchestration references are not so easy to redirect: references to the old map in fact are compiled statically inside the orchestration code therefore orchestration will continue to reference the old one and there’s no configuration settings from administration console who can help use redirecting the version.

Luckily, the same solution found for schema versioning will work also in this case: deploy a new version of the map and apply publisher policy to it.

Schemas

Schemas are usually very problematic when comes to versioning in BizTalk as seen in previous parts:

Schemas are referenced by nearly all other artifacts (Orchestrations, Maps and Pipelines too) and are usually placed in a Central application shared with several others (because usually schemas are traversal to different processes).

Because of this Modify will almost certainly fail and this makes them nearly un-updateable.

BizTalk engine allow us to deploy new version of schemas simply increasing assembly version number and this will make happy Maps and Pipelines but will break orchestrations.

Luckily the Publishing policy procedure depicted in the previous post will help us in solving this last issue allowing us to update freely every BizTalk artifact in a simple and agile way (once you get used to…).