There seems to be some confusion regarding upgrading Orchestrations. Doug Girard has documented this in a blog post here
, but recent webcasts indicate to the contrary. I thought I'd save others some time and confirm that Doug's absolutely right, upgrading an Orchestration version is a fact of
- deploying and binding the new version
- unenlisting the current Orchestration (which doesn't suspend running Orchestration instances, but in fact removes instance subscriptions for the Orchestration)
- starting the new version
If you drop in a message between steps 2 and 3, BizTalk will fail with a "No Subscriptions Found" exception in the EventViewer. This means that to ensure your system will be able to pick up messages correctly, step 2 and 3 need to be executed within the scope of a transaction, as Doug suggests. All Orchestration actions for the v1 version will be dealt with appropriately.
Doug Girard mentions a script for performing steps 2 and 3 in a single transaction to avoid dropped messages.
The location of the script within the documentation is this
(copy+paste the location, clicking will not work).
You can also find the C# code (it's not really a script) within the contents under Operations -> Managing BizTalk Server -> Deploying and Managing BizTalk Applications -> Updating BizTalk Applications -> Deploying and Starting a New Version of an Orchestration Programmatically.
UPDATE: A colleague of mine, Martin Rienstra, mentioned that in spite of documentation to the contrary, the last two version number elements do
matter in side by side and upgrading scenarios. I've tested it and he is right.