Mitch’s reminder to himself regarding Biztalk pipeline components in turn reminded me of a humorous situation the other day at work. Its long, a little involved and not that funny so here goes….
The development environment
The environment for the current project is pretty well set up on the whole. Each developer has a nicely spec’d Windows Server 2003 box with all the servers etc set up and running. Each night we do a build that is automatically migrated to the testing system for the automated functional and performance tests to run against, and for manual testing the following day. One of the Microsoft server products we use is Biztalk. Each developer has a Biztalk server instance, although only those who are doing biztalk work actually configure it and deploy the integration stuff we’ve built.
The problem…
A few days ago our testing Biztalk instance started to behave very odly. This was not that strange - we were in the middle of a development phase, multiple people were working on Biztalk stuff, and Biztalk orchestrations are extremely difficult to unit-test. Our testers had opened a defect and I was assigned to fix it. Seemingly good messages we dropped on to the file system (Biztalk can receive messages in lots of different ways, ours were coming in on the file system), and were disappearing, but not flowing through into our testing system. Not only that, the weren’t even showing up in Health and Activity Tracking (HAT, Biztalk’s message tracking tool), and there were no errors in the event log. This behavior was reproducible but didn’t happen in a deterministic way. Sometimes a message would go in fine, and the next time I copied it in it would be consumed but just disappear. I started by copying the receive location in question, pointing it to a different directory on the file system, and sending messages in. The problem didn’t occur with the duplicate receive location…hmmm….something funny going on here. I stoped the biztalk service and copied some messages into the “broken” receive location. The messages DISAPPEARED! You guessed it! there was another Biztalk instance pointing to the same location on the file system and it was a “competing consumer” (although certinaly not by design).
The solution
It turned out that in order to save time setting up his Biztalk environment one of the other developers had used the deployment script we use every night to deploy our biztalk stuff to the test environment. This script includes configuration of send and receive ports etc, and because we were using a UNC name for the file system location his development biztalk setup was now grabbing files from the same location as the test system. An easy fix, and certainly not what I’d been expecting.