Business Scenario

We will imagine a fictitious organization called Your Event Sponsor that helps event organizers to find sponsors for their events. Your Event Sponsor maintains a dynamic list of all its sponsoring firms. Each sponsoring firm have their own message format for the event details. When Your Event Sponsor receives a request from the event organizers seeking for sponsors, it has to apply some business logic and then upload the event details to each sponsoring firms FTP server in appropriate format. The current business logic is same for all the sponsoring firms but could change in future. The design should provide mechanism to accommodate such changes, add/remove sponsoring firms without requiring complex or lengthy re engineering.

Classic Solution

A classic solution is to develop one physical orchestration to confine the business logic of each sponsor, transform / translate and route it to the sponsor.

The drawbacks with this solution are limited reusability and challenges in maintenance. 

So how can we design a better solution?

Proposed Solution

Figure 1 - Solution Diagram

The Manage Sponsors Process orchestration acts as a supervisor and subscribes to the Sponsor Request message sent by the event organizers to Your Event Sponsor.

Configuration Xml (Figure 2) stores the details of all sponsors such as the orchestration name and is yet active or not.

Figure 2 - Sponsor Details Configuration Xml

Manage Sponsors Process (Figure 3) reads this configuration xml. It loops through each sponsor detail and when the current sponsor is active; makes a copy of the Sponsor Request message and updates custom context properties (of Sponsor Property Schema) relevant to the sponsor. It publishes the Sponsor Request message to the Message Box.

Sponsor Property Schema has the properties Name, ProcessingOrchestration, MapName and PipelineName.

Figure 3 - Manage Sponsors Process Orchestration

Sponsor Business Process (Figure 4) orchestration(s) will cater the business logic for each sponsoring firms. We will only build one generic orchestration to fulfil the business logic for all sponsoring firms in our initial solution. It will subscribe to the messages with the promoted property ProcessingOrchestration=“GenericSponsorProcess” published by Manage Sponsors Process.

It will perform dynamic transformation, invoke pipeline for format translation (say flat-file) and dynamic routing.

Figure 4- Sponsor Business Process Orchestration

Easy on-boarding/off-boarding

This design eases the on-boarding and off-boarding of the sponsors with very little effort.

To add a new sponsor with same business logic, we just need to create the transformation / translation artifact and then add an entry into the configuration xml.

Only when there is a need for customization of business logic for the sponsoring firms, additional sponsor orchestrations may be required to be built.

Key Benefits

The key benefits delivered by the proposed solution are:

  • Shorter implementation time
  • Higher Re-usability
  • Simplified Maintenance
  • Greater Return on Investments


We demonstrated how our solution provides better benefits over a traditional solution for the scenario. Though the scenario is fictional, the pattern can be applied to solve real-world problems that involves broker pattern such as booking tickets, hotels and loan etc.

Disclaimer: The views and opinions expressed here are my own and not my company's.

See Also

Another important place to find an extensive amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki