BizTalk – Creating shared application at a later stage

While working with BizTalk, it not uncommon that one will be utilizing enterprise resources which are shared between multiple solutions. It all appears fine for the first application deployment, but after you deploy the second one, which also depends on the same resource e.g. a web service, you start getting errors, if you are not careful. The issue is the schema for shared resource is deployed twice in the same message box.


I tried several hacks before taking the proper route. Here are some of the hacks which didn’t work:

  • Renaming schema namespaces via xml editor – in both xsds and maps (this looks promising initially – no duplicate schema messages, but when receiving real messages, it fails)
  • Creating a separate host/host instance to isolate the two applications

The correct solution is to create a shared application (Best Practices), which contains the reusable schemas, and reference it from both applications. For new applications, it is easier to do the things right from the first time. But if you have Application A deployed already and now you want to externalize the Enterprise Resource X dependency, it will require some extra work – if you don’t want to disturb any existing maps.


Here are the steps that I captured during similar experience:

Assuming that Application A has schemas for X within its projects which you want to externalize into a separate project. This new project can be shared between both A and B.

  1. Create shared application project for X, which contains the reusable schemas and build assembly. I keep it in a separate solution of shared artifacts.
  2. Identify the VS projects in Application A, which contain schema for X. Delete/exclude-from-project the schemas for X.
  3. Add reference to the shared project assembly. Instead of project reference, I hold all dependencies in a separate folder and do assembly reference (relative path) from there.

At this point, the only thing left is to correct the schema references in existing maps of A, without modifying anything else in the maps.

  1. Identify the shared schemas in use by A by looking at the maps.
  2. Create a dummy map and refer the shared schema from the referenced shared assembly.
  3. Save the map and open it in xml editor. Note down the reference location value for the schema. For WCF services, there will be two schemas (one with data types and other data contracts).
  4. Open each existing map in application A via xml editor and replace the location value with the one you noted in previous step (usually replacing file system path with assembly name)
  5. Delete the dummy map and compile the project.

Finally, it was an interesting lesson that is usually not learned at the first BizTalk project, but at the second.



After a shared application has been deployed and referenced by other applications, changes made to shared application will introduce another layer of complexity to re-deployment.

From Jon Flander’s post, here are the changes to artifacts and whether full deployment or just gacking would work. For example, in order to add new fields in schema of shared assembly, a simple gac install worked with host instance restart.

Artifact Change Un + Re-deploy GAC + Restart Host
Maps Source/Dest schema YES YES
Links or functoids NO YES
Orch Add/Remove Ports YES YES
Change Port Type of Rcv Port YES YES
Add/Remove/Modify Shapes NO YES
Schemas Type Name YES YES
Add Root Record YES YES
Add Distinguished Field YES YES
Change elements/attribs NO YES
Pipelines Any Change YES YES
All Artifact Type Name YES YES
Assembly Name YES NO
Assembly Version YES NO

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: