Deploying changed Schemas and Maps with the ESB Toolkit with NO Downtime for other Processes

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.
Deployment_UseCase
 
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.
ESB_Applications
 
The "ESB.UBL" Application contains all canonical .XSD schemas. The .XSD schemas can be put in one “UBL.Schemas” Project in Visual Studio.
UBL_Solution
 
For each system that needs to be linked, there is a separate Application in BizTalk with the specific Schemas and Maps. 
DynamicsAX_Solution Warehouse_Solution
     
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.
ProcessOrders_Itinerary
 

 

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!

About the author

Tomasso Groenendijk lives in Netherlands and is a senior integration consultant at Motion10. He has over 15 years’ experience in software development and software design. Tomasso is specialized in application integration with a strong interest in the Windows Azure cloud platform. In 2014, 2015 and 2016 Tomasso was awarded with the Microsoft Azure MVP award. He is an active contributor to the integration community through his work on his blog, MSDN samples, TechNet Wiki and also speaking on events.

 
 
 
MVP profile Tomasso Groenendijk
 
 
Sentinet Product Specialist
 
 
BizTalk360 Product Specialist

Month List