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 220.127.116.11 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 18.104.22.168, side-by-side with version 22.214.171.124
- New orchestration instances should instantiate under the new version 126.96.36.199
- Existing orchestration instances should rehydrate by correlation under the old version 188.8.131.52.
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 184.108.40.206.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:
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 220.127.116.11
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 18.104.22.168 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 22.214.171.124 of the orchestration:
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 126.96.36.199 occurs. New orchestration instances should instantiate the new version 188.8.131.52, but existing instances should drain out under version 184.108.40.206.
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 220.127.116.11 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 18.104.22.168.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:
- Unenlist the old version – without terminating the active instances
- Enlist and start the new version
- 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 22.214.171.124, before any new instances of version 126.96.36.199 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 188.8.131.52.
Test: new instances are processed by version 184.108.40.206
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 220.127.116.11.
Test: old instance correlates and is processed by version 18.104.22.168, whilst a new active instance of version 22.214.171.124 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: