On one of the projects im associated with we have recently upgraded from BizTalk 2006 to BizTalk 2006 R2 for our next release.
In doing this we needed to upgrade our development environment and a number of testing environments. Fortunately the testing envronments are not managed by our team so we didnt need to have too much involvement in this other than providing guidance and support.
In the development environment we needed to upgrade a number of developer machines and also some build servers. We also needed to support some cycles of testing which were still happening on the non R2 machines.
Two things which you might want to consider if you are doing the same is as follows:
1. The importance of Continuous Integration
One of the first things I did was to setup the appropriate build servers to implement continuous integration so we were building and testing our code on both BizTalk 2006 and 2006 R2 at the same time.
One of the benefits of this was that it allowed me a chance to be able to deploy code which was tested in both environments and to give us more time to rebuild the developer machines.
In theory there shouldnt really be many issues for this upgrade in terms of the code we had already implemented, but using CI would help us mitigate the risk.
Before we had begun the upgrade I had setup a machine to POC running our code in a 2006 R2 environment. Although we expected this to be trouble free I did find two small problems which needed addressing (1 a BizTalk thing and one not)
Problem with a custom pipeline component
The first problem I came across was in a custom pipeline component we have. This component helps implement a custom debatching solution in a process where we implement the splitter pattern (i will probably post something about this in the future). This component basically accepts a big message comming in, does some stuff and then replaces the message with a small trigger message which is sent to the messagebox.
The message we send out matches a schema and we set some custom context properties and the appropriate message type property. This message is then collected by an orchestration and the process continues.
While this had worked fine previously in 2006. When I ran this in BizTalk 2006 R2 I would get an error from the orchestration when it collects the mesasge and initiates the orchestration. The problem indicates that the schema strong name is incorrect.
I have come across this before and by changing our pipeline component to add the schema strong name of the message to the context (BTS.SchemaStrongName) the whole thing then worked again.
This is obviously caused by something that has changed between versions and was a simple enough fix.
Problem with one of our tests (Serialization)
The second problem was also pretty straightforward. When running the tests for one of our applications the SoapHttpRequestResponse step from BizUnit started to get an error which it hadnt previously got. This was caused because there must be some changes in the serialization functions of the ,net framework (we now have .net 2 SP1, .net 3 SP1 and .net 3.5, where we used to only have .net 2). Basically the problem was that the developer hadnt included the namespace as defined in the WSDL. While it used to work when the step used it, it now didn't
In conculsion so far the impact on our code by this upgrade has been very small and the couple of problems we have had have been eaily solved.
The one takeaway is probably my to use CI and BizUnit as it makes it much easier to detect problems before you deliver code outside of your team for testing.