Keep The Orchestration Simple (KTOS) - A BizTalk Pattern

• Download source files - 57 Kb

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 PO's need to be mapped into appropriate POAck.

The solution has been divided into three main parts, the PurchaseOrder project is the core of the solution. The PO_CompanyA references the PurchaseOrder project and the two maps are added, one transforms the external PO into Universal_PO and another transforms the 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 the "UniversalPO" into "POAck".

Receive Port Configuration

The transformation map specified in the "Receive" port, converts the "PO_A" into "UniversalPO".

Solution Explorer

Follow the 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 the 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.
• Adding the maps in the new Receive and Send Ports.

Summary

In this article we have seen how to structure your BizTalk artifacts in order to ensure painless (post-deployment) maintanence of the 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 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 same can be achieved in the send and receive ports as demonstrated in the article.