BizTalk 2004 side-by-side deployment example

by | Nov 1, 2005 | BizTalk Community Blogs via Syndication | 0 comments

Anyone tried to get side-by-side deployment to work in BizTalk 2004? Anyone found any examples? I know I couldn’t, so here’s my attempt at it.


The business scenario is as follows:



  • A long-running orchestration instance version 1.0.0.0 is awaiting a correlating response from a business partner – in the case of my client this will typically take 4 to 6 weeks
  • The orchestration is upgraded to version 1.1.0.0, side-by-side with version 1.0.0.0
  • New orchestration instances should instantiate under the new version 1.1.0.0
  • Existing orchestration instances should rehydrate by correlation under the old version 1.0.0.0.

Assumptions about the sample application:



  • Zipfile can be extracted to C:\temp\VersioningTest (if not, you’ll need to change the binding files manually before importing them)
  • BizTalk management database is called BizTalkMgmtDb and is on the local server (if not, change each project’s properties)
  • The default in-process host BizTalkServerApplication exists (if not, you’ll need to change the binding files manually before importing them)

Download this zipfile and extract it to C:\temp so that it expands to C:\Temp\VersioningTest\*.*


Open C:\Temp\VersioningTest\Source\V1.0\Version 1.0.0.0.sln and examine the orchestration. It looks like this:



Pretty simple stuff. The business process you will be performing is as follows:



  • a client application (this means you) drops a message into the Msg_from_client folder to initiate the business process
  • Project1.TestOrchestration instantiates, inserts a comment into the message noting which version processed it, then drops it into the Msg_to_partner folder
  • the partner application (this means you again) moves this message from the Msg_to_partner folder to the Msg_from_partner folder
  • Project1.TestOrchestration rehydrates by correlation, inserts a comment into the message noting which version processed it on the way back, and drops this message into the Msg_to_client folder

Deploy the solution, refresh BizTalk explorer, and you should see the following two assemblies:



  • VersioningTest.Project1(1.0.0.0)
  • VersioningTest.Schemas(1.0.0.0)

In BizTalk Deployment Wizard, import the assembly binding from file C:\temp\VersioningTest\Source\V1.0\Bindings_v1.0.xml and then start orchestration VersioningTest.TestOrchestration, accepting all the defaults to start the associated send and receive ports.


Testing version 1.0.0.0


Copy Test_message_1.xml from C:\temp\VersioningTest\Messages\TestMessages to C:\temp\VersioningTest\Messages\Msg_from_client.


This will get picked up, and a message will appear in C:\temp\VersioningTest\Messages\Msg_to_partner. Open this message, and view the text inside the InboundComment element that confirms it was processed by version 1.0.0.0 of the orchestration.


The business process is now waiting for its partner application to respond. Remember that in the long-running business process we are modelling, this response could take weeks or even months to arrive. To provide this response, move the message from C:\temp\VersioningTest\Messages\Msg_to_partner to C:\temp\VersioningTest\Messages\Msg_from_partner.


This will get picked up, and a message will appear in C:\temp\VersioningTest\Messages\Msg_to_client. Open this message, and view the text inside the OutboundComment element that confirms it was processed by version 1.0.0.0 of the orchestration:



Side-by-side deployment


In the above test, the partner application took as long to respond as it took you to copy a message from Msg_to_partner to Msg_from_partner. Imagine instead that this process takes weeks or even months, and in the meantime, an orchestration upgrade to version 1.1.0.0 occurs. New orchestration instances should instantiate the new version 1.1.0.0, but existing instances should drain out under version 1.0.0.0.


To prepare for this test, copy the first three test messages (Test_message_1.xml, Test_message_2.xml and Test_message_3.xml) from C:\temp\VersioningTest\Messages\TestMessages to C:\temp\VersioningTest\Messages\Msg_from_client, and ensure that you get three messages in C:\temp\VersioningTest\Messages\Msg_to_partner, with values for the ID element of 1, 2 and 3, and also with InboundComment element values indicating that they were processed by version 1.0.0.0 of the orchestration. Also check HAT’s Operations – Service Instances – Orchestrations view, and you will see these three active (and perhaps dehydrated) instances awaiting a response.


Now open C:\Temp\VersioningTest\Source\V1.1\Version 1.1.0.0.sln, and examine the differences: the Project1 assembly version number has changed, as has the version number inserted into the comments in the messages.


Right-click the Project1 project and select Deploy. Refresh BizTalk explorer, expand assemblies and orchestrations, and you will see the two versions:



In BizTalk Deployment Wizard, import the assembly binding from file C:\temp\VersioningTest\Source\V1.1\Bindings_v1.1.xml.


Now here’s the bit you have to get exactly right:



  1. Unenlist the old version – without terminating the active instances
  2. Enlist and start the new version
  3. Resume the suspended instances of the old version (since unenlisting the old version automatically suspended them all)

To do so, first refresh BizTalk Explorer, then right-click VersioningTest.TestOrchestration and select Unenlist – confirm, ensuring you do not terminate active instances. Then, start VersioningTest.TestOrchestration(1), accepting all the defaults. Then, go into HAT’s Operations – Service Instances – Orchestrations view, and resume the three suspended instances.


Test: old instance correlates and is processed by version 1.0.0.0, before any new instances of version 1.1.0.0 exist


Move the message with ID = 1 from C:\temp\VersioningTest\Messages\Msg_to_partner to C:\temp\VersioningTest\Messages\Msg_from_partner, and when it appears in C:\temp\VersioningTest\Messages\Msg_to_client open it up:



 You can see it was processed on the way back by version 1.0.0.0.


Test: new instances are processed by version 1.1.0.0


Copy Test_message_4.xml and Test_message_5.xml from C:\temp\VersioningTest\Messages\TestMessages to C:\temp\VersioningTest\Messages\Msg_from_client, and examine them when dropped into C:\temp\VersioningTest\Messages\Msg_to_partner:




You can see they were each processed on the way in by version 1.1.0.0.


Test: old instance correlates and is processed by version 1.0.0.0, whilst a new active instance of version 1.1.0.0 exists


Move the message with ID = 2 from C:\temp\VersioningTest\Messages\Msg_to_partner to C:\temp\VersioningTest\Messages\Msg_from_partner, and when it appears in C:\temp\VersioningTest\Messages\Msg_to_client open it up:


<IMG

Submit a Comment