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:
- 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 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:
You can see it was processed on the way back by version 1.0.0.0.
Test: new instance correlates and is processed by version 1.1.0.0, whilst an old active instance of version 1.0.0.0 exists
Move the new message with ID = 4 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.1.0.0.
Test: old instance correlates and is processed by version 1.0.0.0, after an instance of version 1.1.0.0 was processed end-to-end
Move the message with ID 3 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 instance correlates and is processed by version 1.1.0.0 after all old instances of version 1.0.0.0 have been processed end-to-end
Move the new message with ID = 5 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.1.0.0.
Summary
This test application demonstrates how you can use BizTalk's side-by-side deployment process to upgrade an orchestration that will instantiate for new orchestration instances whilst allowing existing orchestration instances to continue to be processed by the version that instantiated them.
...and a bug!
Unfortunately side-by-side deployment doesn't work with convoy orchestrations that have an initialising correlation set on the activating receive. This drove me absolutely nuts whilst I was trying to get side-by-side deployment to work, since my first test app was using a convoy, and I asked just about everyone I know to no avail. The post-SP1 hotfix 890241 for side-by-side deployments didn't help either. Eventually Stephen W Thomas suggested that I take the convoy out of the picture, and then it worked just fine. We have an open PSS case and are promised a hotfix - once we have it, I'll publish another test application for convoy orchestrations - though not documented as exhaustively as this ;)
When migrating the solution from a single server to a multi-server staging environment, my client experienced problems with MSMQT service instance times running into minutes. We were using an Alteon hardware load balancer, but all the documentation only mentioned using NLB - I could find nothing that confirmed or denied that it was possible to use anything other than NLB. An example of this woolliness is KB 898702 which states you can try using NAT devices but they're not officially supported.
Anyway, when we installed NLB instead, it worked a treat. And we got this definitive response from PSS:
We support hardware load balancing with the exception:
- We don’t support NAT
- Sticky IP must be implemented
Turns out our hardware load balancer uses NAT internally, so that was presumably our problem. Has anyone successfully used a hardware load balancer with MSMQT? I guess I don't understand how the BTS app servers could bind to its IP address given it'd be external to them...
When you add the MSMQT adapter, the host name it uses is the default host at the time - this will usually be BizTalkServerApplication - and once you've selected it, it seems you can never change it. So if you want a separate host for your MSMQT adapter, before you add the MSMQT adapter to your server group, create a host called MSMQT_host (or whatever naming convention you're using for your hosts) and set it as the default host. Now add the MSMQT adapter, and it will run under this host. Then, reselect the previous default host, and set it back to the default host.
I promised myself I was never gonna do one of these but the time has come to write down some of the things I had to google for England before I found the answers to, in the hope that I can save others from a similar fruitless fate. I hope they prove useful to you too - comments and corrections very welcome! Right, time to port the BlogLines posts across.....