Organizing BizTalk Applications
Just wanted to share a little bit of BizTalk trivia. BizTalk 2006 added
the ability to create separate applications. For somebody with a
programming background, like myself, a Biztalk application is
conceptually very different from, say, a .NET application. A .NET
application runs inside of its own process and has its own memory space.
A BizTalk application is more of an organizational tool. It provides a
convenient way of grouping together BizTalk artifacts, and makes it
easier to stop and start a group of ports. However, all BizTalk
applications are run within the same process.
That little bit of background information makes explaining this next
part easier. Since everything runs in the same process, you have to be a
little bit careful when you share artifacts between applications. For
example, if you have two orchestrations that both use the same schema,
you need to be sure that only one version of that schema is deployed.
(Based on the XML namespace and the root node name combo that BizTalk
uses to uniquely identify a schema.) If you deploy the same schema more
than once, BizTalk will have trouble matching an instance to the correct
schema and you will get all kinds of weird errors in the Event Log.
To avoid this problem, make sure you organize your shared artifacts into
separate assemblies, and have the projects that use them all reference
those assemblies. This is also nice, because if one of your shared
schemas needs to be modified it only needs to be modified in one
assembly, and then all the projects that reference it will get those
changes. You might also consider deploying shared artifacts into a
separate application to make it easier to keep track of them. (The
default “BizTalk Application 1” that gets created during installation is
a good candidate for this.) Hopefully this little tip will help others
who are new to BizTalk avoid some of the pain that comes with the large
learning curve.