When migrating from BizTalk 2004 (or possibly 2002) to 2006 one might feel tempted to do some refactoring at the same time, fixing things you (or somebody else) could have done better the first time. If the migration is done from a large BizTalk solution, you probably want to make sure everything works as it did before, without spending to much time testing. After all, it’s "just" a migration project.
So if what you are looking for, is some kind of regression testing, leaving your developers to focus on the migration task, you might find this post useful.
The basic principle here is letting messages, passing through the old environment, also passing through the new 2006 solution, and ending up being validated to match each other. It is important to understand that this testing process will only test the content of the message and not any possible connectivity problems. It will require you to deploy your 2006 ports using the File adapter on both receive and send port side. Upon deploying your solution to the production environment these ports would need to be changed to whatever binding you used before. An other important thing to understand is that this process only works with one-way ports.
To make this happen we need to add a pipeline component at the beginning of every pipeline in the old environment. This component will archive the incoming message to the location where the Receive Location in the new environment will pick it up. Hopefully you can achieve this by copying every pipeline to one new Visual Studio 2003 project, and add the pipeline component to the new pipelines.
The archive component should be designed to require as little system resources as possible, why it uses a Forward only event streaming manner, which basically prevents the stream from being read more than once. To learn more about ForwardOnly streaming, have a look at Johan's blog post.
Having the updated pipeline assembly, all we need to do is to (1) add an additional Send Port with identical filter settings, and (2) change the pipeline to the updated one, and (3) set the archive path to where ever you set the receive location to in the 2006 environment.
When you’ve done this, the orchestration will pick up the files from the Send Port locations and check if they are identical. The result will be sent to the database, along with the actual messages, for later use.
The orchestration is generic and can be used for every scenario. It has an parallel shape which will prevent it from continue until it receives two files with identical names. To ensure the names comes out with the same name, the pipeline component mentioned above, will promote the ReceivedFileName property (file-property namespace) if it is not set. This will be the case when the original message, for instance, is received from an MQ adapter.
It will then proceed and send the incoming messages to an archive, where you can later pick them up if you need to analyze its content. Next is a decision shape where the actual matching is done. The result will be inserted into a database table, which you may later query to get all failed messages (if any).
If you find this post of interest, let me know, and I'll post the source code.