BizTalk Server: How to do it Test but not in Production

Best practices

Over the years people working with BizTalk do things more and more the best way when it comes to make a difference between test and production, all though most changes should be done equally or at least as close to equally there are a few things that isn't intended to be in production, but keeps ending up there.

This article will cover these things, with reason why you shouldn't do it, and possible impacts it may give you. Everyone is welcome to contribute to this article as it grows bigger with more and more relevant "best practices" on this specific topic.

Artifact tracking

One of the things I keep seeing over and over again is the massive use of artifact tracking. I don’t mean this is a bad thing, as long as you know where to use it and where it shouldn't be.

Artifacts in BizTalk can be a lot of things, but most of them have the ability to perform some sort of tracking. Receive Ports, Pipelines, Send Ports, Orchestrations, Business rules, Maps and Schemas all have options for tracking. But what is this tracking data really used for?

In most cases the tracking data is used for tracking data during development to look for changes or see where problems or changes happen. But when it comes to production do you still need debugging data, in a perfect world all bugs should have been eliminated at this moment, but we all know this rarely happens. But do we still need the tracking information.

If you turn of the three first tracking options on the orchestration (all the event tracking) you won’t have the Orchestration Debugger and the data won’t be stored. But is debugging intended for orchestrations in production?

Impacts

Slow performance

Keeping to much artifact turn on will slow down performance due to fact that the host will have too much information to move from one database to another one, there is a reason that turning global tracking off is one of the most efficient ways to improve performance for you BizTalk environment.

Large databases

The more you are tracking the more data will fill up your databases, the TrackingData tables in the messagebox contains information that are supposed to be moved to the tracking database, and the tracking database itself contains numerous tables with information regarding all the artifacts you have tracked. This will increase the sizes of your databases and you will end up with large databases.

Recommendation

My professional recommendation regarding artifact tracking is to turn it completely off in any production environment. This will lower the load of your BizTalk databases and make sure that the BizTalkDTADb won’t grow enormous.

In the end it will give you a better performance, this is my two cents, and I recommend you check your production environment and solve any artifact tracking you have. You will be amazed by the findings!

Testing in production

Applications shouldn't be tested in production environments, the reasons are numerous. Artifacts like ports and orchestrations that are intended for testing should be removed from the application before you take them into the production environment. Not only that applications should never be tested in production, even though the system you are testing the application for don't have a valid test environment you should install the application in test, test it and move it to production and making sure any "test" ports or other artifacts should be deleted.

Impacts

Test are polling from many environments

If you happen to start test and production both the applications will start picking up files from test, or delivering of production files to the test system.

No control

You will end up with no control over what should be turned on or off and what shouldn't be there. Its important to have a good overview of your environment, implementing problems like this should not occur.

Recommendations

The recommendation is to keep test and production separate, keep all artifacts that are designed for test out of the applications in production, by this i mean test copy ports etc.

See Also

Another important place to find an extensive amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.