Introduction - KISS vs. KTOS
If KISS stands for "Keep It Simple Stupid", then KTOS stands for "Keep The Orchestration Simple".
Designing a robust and extensible orchestration is the key to any successful BizTalk implementation. This article describes a simple pattern which frees the Orchestration from a Transform Shape.
Scenario and the problem to be solved
Consider a scenario where a Purchase Order (PO) needs to be processed and a Purchase Order Acknowledgement (POAck) needs to be transmitted. Every incoming PO has a particular format which needs to be transformed into, an internal PO format, in order to be able to process it. Similarly, every outgoing POAck has a different format which needs to suit the receiver. The problem is how to add new incoming PO and outgoing POAck formats to the system once the system is operational.
The BizTalk Solution
The BizTalk Orchestration should abstract itself from any other external schemas. The Orchestration has knowledge of only one schema known as "UniversalPO". All incoming external PO schemas need to be mapped into this UniversalPO, and similarly, all the outgoing POs need to be mapped into appropriate POAcks.
The solution has been divided into three main parts; the PurchaseOrder project is the core of the solution. PO_CompanyA references the PurchaseOrder project, and the two maps are added: one transforms the external PO into Universal_PO and another transforms Univeral_PO into POAck as required by the external system. The Orchestration diagram below presents a better picture.
Main Orchestration
This Orchestration processes the PO by calling an external .NET component known as BizRules which is present in the Global Assembly Cache (GAC).
BizRules .NET component
The class diagram for the BizRules.NET component is shown below...
Send Port configuration
The transformation map specified in the "Send" Port converts "UniversalPO" into "POAck".
Receive Port configuration
The transformation map specified in the "Receive" Port converts "PO_A" into "UniversalPO".
Solution Explorer
Follow these steps to add a new PO format
In order to support a new PO format after the BizTalk solution is deployed, the following needs to be done...
- Add new external, incoming, and outgoing schemas in a new project.
- Two maps are required to be added, one for converting the "external PO" into "internal PO", and another for converting the "internal PO" into "POAck" as required by the external system.
- Add the maps in the new Receive and Send Ports.
Summary
In this article, we have seen how to structure our BizTalk artifacts in order to ensure painless (post-deployment) maintenance of a BizTalk Solution. Generally speaking, being aware of the dependencies of the project will ensure avoidance of re-compilation and re-deployment.
Takeaways
- All promoted properties and distinguished fields must be initialized with the default values in the schema.
- Generally, all schemas must be placed in a separate project/DLL, and all related Orchestrations must also be placed in a separate project/DLL.
- It is generally observed, in many cases, that map transformations are done within the Orchestration; this is unnecessary, and the same can be achieved in the Send and Receive Ports as demonstrated in the article.
