In the event of a change in BizTalk, you normally deploy at a specific time/date all your changes when there is no “traffic”. This is because you first have to remove the Schemas, Maps and Orchestrations before you can deploy the changes. Therefore all the processes in BizTalk that make use of these artifacts have to be stopped and can not run. Especially when you use a Canonical Data Model (CDM) it can be difficult to deploy changes because Maps and Orchestrations in different processes use the same Canonical Schemas.
One of the advantages of the ESB toolkit is that you can easily deploy modified Maps and XSD schemas but how does it work?
Designing processes in an ESB that makes use of a CDM
Orchestration-based and messaging-based services in an Itinerary don’t depend on Schemas and Maps like “regular” Orchestrations do. So in the event of a change, there’s much less disruption with this model.
| In the following diagram are three different message types shown that are mapped and routed in the ESB to the specific applications. Each message type is processed by an itinerary. | ||
| In this scenario, you have 4 BizTalk Applications. The “ESB” Application is a generic Application with the Receive Ports and the custom Itinerary Services because they are generic and designed for multiple Message Types. | ||
| The "ESB.UBL" Application contains all canonical .XSD schemas. The .XSD schemas can be put in one “UBL.Schemas” Project in Visual Studio. | ||
| For each system that needs to be linked, there is a separate Application in BizTalk with the specific Schemas and Maps. | ||
|
|
||
| For each Message Type is a separate Itinerary. The ProcessOrders Itinerary in this example has 2 custom RecipientList Services to map and route the messages to Dynamics AX and the Warehouse. | ||
Change in a Map
Orchestrations are not bound to a specific map because transformations are performed by the MapHelper class. Therefore they don’t have to be removed when deploying a change.
Deployment steps:
- Disable specific Receive Locations.
- Only disable the Receive Locations that receive the messages that uses the changed Map.
- Only remove the maps from the BizTalk BizTalkMgmtDb (with BizTalk Administration Console)
- Don’t remove the Assembly from the GAC so other maps can still be executed.
- When using the Deployment Framework you can also remove the .XSD schemas from BizTalk that are in the same Solution in Visual Studio as the changed Maps.
- Deploy the changes.
- Restart the BizTalk Host Instances.
- Start the disabled Receive Locations.
Change in a .XSD schema
Orchestrations are not bound to a specific .XSD schema because the used Message Type is a XmlDocument. Therefore they don’t have to be removed when deploying a change.
Deployment steps:
- Disable specific Receive Locations.
- Only remove the maps from the BizTalk BizTalkMgmtDb (with BizTalk Administration Console)
- Don’t remove the Assembly from the Global Assembly Cache (GAC) so other Maps can still be executed.
- Only remove the XSD schemas from BizTalk BizTalkMgmtDb
- Don’t remove the Assembly from the Global Assembly Cache (GAC)
- Deploy the changes.
- Restart the BizTalk Host Instances.
- Start the disabled Receive Locations.
Conclusion
Orchestration-based and messaging-based services in an Itinerary don’t depend on Schemas and Maps. When Schemas and Maps are removed from BizTalk, the ESB still can process the messages and map to the other message types because the maps are still in the GAC. This can be very useful in an 24*7 environment where it’s crucial that it is possible to deploy changes without stopping other processes that do not depend on the changed Schema or Map.
Deploying changes with the ESB Toolkit is very powerful so you have to be careful and know what you are doing!