WABS Integration Pattern – Dynamic Router

Continuing from my previous blog on WABS Patterns, we will implement another enterprise integration pattern in this series.

We will continue utilizing the WABS features set that are available in the current version.  As and when new bits come out, our blog series will be updated to reflect the changes.

The patterns that we will address in this post will be Dynamic Router.

For this pattern each message recipient will define the rules on the type of the messages it can handle and process.   The message will be routed to the right message recipient when the message parameters are matched against the rules.

For Windows Azure infrastructure, Topic and the Queues provides this functionality.   We will use Azure Topics and create subscriptions and extend that by including the custom code in Bridges.

Scenario

Contoso accepts orders for multiple brands of products they sell from many different partners across the country and around the globe.  Contoso partners could be sending order data either via FTP or via web-services.  Along the way the message must be dynamically routed based on the metadata information.  Their order fulfillment is often based on the region for logistics and distribution purpose.  This is done by looking up the data value from the message at runtime and promoting the properties to Brokered Message  using custom code in the bridge for routing messages.   Since the message are promoted at runtime dynamically, from within the bridge there is no need to manually set the properties and it’s value at design time.  Once the order is dynamically determined, all orders are placed in separate holding areas for further processing by the back end line of business system.   Each regional fulfillment center will then subscribe to these order messages and process them appropriately.

BizTalk Server Approach

To implement this pattern as BizTalk Server Solution we should

1. Create schema to receive the message.
2. Orchestration will subscribe to the message
3. Orchestration will promote the message properties, in our case Region
4. Message properties specific to routing (like address and transport type) will be set on Dynamic send port in orchestration
5. Dynamic send port will route the message based on the transport protocol and the address set

WABS Integration Services Approach

The figure below represents a BizTalk Service Project.

Just like BizTalk Promoted properties, we do similar processing with Brokered Messages objects that contain the properties collection for routing the messages. As can be seen, we have Bridges that allow input into our process:

OrderMetaData

OrderMetaData is an XML Bridge that is surfaced through an FTP Source.  The source allows a pull from an FTP site.   FTP source pulls the Order data with some metadata.

Figure  below shows the OrderMetaData configuration

Message received on Bridge is an XML message with schema as below:

We are extending the dynamic features available on Azure Topics by implementing the Brokered Message properties collection (equivalent of promoted properties in BizTalk).  Our goal is to dynamically assign the values to properties at runtime.  To implement that we have created a metadata record on an order that will identify the Property Key(s) that need to be promoted at runtime for the Azure infrastructure recipient.

Bridge custom code

The OrderMetadata Bridge is extended to include custom code to promote the properties at run time.  Custom code on the bridge is available on Decode, Validate, Enrich, Transform and Encode stage.

Custom code can be created on either before message enters into the stage (OnEnter) or after message exits the stage (OnExit).

Following screenshot displays the custom code inspector (On Enter) properties for the Enrich Stage within Bridge.  There are step by step instructions on creating custom code in bridge on MSDN.

A few key points to keep in mind while creating custom code for Bridge:

1. Fully qualified assembly names (with strong name) need to be entered as a Type on Code Inspector.
2. Copy Local needs to be set to true.
3. IMessageInspector (of Microsoft.BizTalk.Services namespace located in Visual Studio Extension directory – Common7IDEExtensionsMicrosoftMicrosoft Azure BizTalk Services SDK) must be implemented.
4. Logic in Task.Factory.StartNew method must be implemented.

The following is the custom code implementing the IMessageInspector.   The code that is reading the input message that was received on the bridge and based on the metada key, finds out the value of the actual data element.

The code above is generic enough to promote the properties based on Metadata key(s).   Alternatively a schema could have been modified to promote all the properties of an message based on a specific record (say Messageheader).

Routing and Filtering

Once the enriched message exits the bridge, it is sent to Azure topic regionroute. Topics give us the ability to add subscriptions on the fly and hence creating the message recipient dynamically.

Topic is created with 2 subscriptions

• Subscription Illinois with Default rule of “region=’IL’

• Subscription Washington with Default rule of “region=’WA’

Once the artifacts are deployed they can be viewed and verified in BizTalk Services portal as shown below :

Tracking

I like to use Service Bus Explorer tool to look into the Azure infrastructure.    Exploring the message into subscription, it can be noticed that message custom properties contains the promoted value for the metadata Key defined which was used to route to right recipient.

Below is the detail tracking information on all the activity performed when the bridge was executed.

Upon clicking on detail on one of the tracking activity, it will show the detail message information. In the case below it shows the all custom message inspector that was executed on ordermetadata bridge.

The message was finally routed to regionroute topic:

Pre-Requisite: 

Install Windows Azure BizTalk Services SDK.  Developer SDK features the support for BizTalk service Project template in Visual Studio.

Provision BizTalk Services.

Required information to Deploy BizTalk Services Project.

Testing:

FTP Route:

1. Drop orderinstanceIL.XML (region = IL) or orderinstanceWA (region = WA) into FTP Source Location (free FTP hosting is available at DriveHq.com)
2. Ordermetadata brige will pickup the data from FTP Source
3. XML message received will be used to promote the properties into Brokered Message collection based on the metadata key
4. It will be sent to regionroute Topic
5. Based on the rules defined data will be routed to appropriate topic subscription.

Conclusion

This example showed how the WABS and Azure technology provides some new (Topics with rules) and existing (Promoted properties) features in the Windows Azure Cloud.  The queues and topic infrastructure give us a much more dynamic way to route and subscribe to messages in our integration solutions with WABS feature to implement custom code in the bridge.