BizTalk – Creating shared application at a later stage
July 13, 2010 Leave a comment
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.
- Create shared application project for X, which contains the reusable schemas and build assembly. I keep it in a separate solution of shared artifacts.
- Identify the VS projects in Application A, which contain schema for X. Delete/exclude-from-project the schemas for X.
- 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.
- Identify the shared schemas in use by A by looking at the maps.
- Create a dummy map and refer the shared schema from the referenced shared assembly.
- 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).
- 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)
- 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|
|Links or functoids||NO||YES|
|Change Port Type of Rcv Port||YES||YES|
|Add Root Record||YES||YES|
|Add Distinguished Field||YES||YES|
|All||Artifact Type Name||YES||YES|