BizTalk: Sample: Context routing and Throttling with orchestration

Posted by Leonid Ganeline on Geeks with Blogs See other posts from Geeks with Blogs or by Leonid Ganeline
Published on Sun, 27 Feb 2011 23:04:53 GMT Indexed on 2011/02/27 23:25 UTC
Read the original article Hit count: 318

The sample demonstrates using orchestration for throttling and using context routing.

Usually throttling is implemented on the host level (in BizTalk 2010 we can also using the host instance level throttling). Here is demonstrated the throttling with orchestration convoy that slows down message flow from some customers. Sample implements sort of quality service agreement layer for different kind of customers.

The sample demonstrates the context routing between orchestrations. It has several advantages over the content routing. For example, we don’t have to create the property schema and promote properties on the schemas; we don’t have to change the message content to change routing.

Use case:

 The BizTalk application has a main processing orchestration that process all input messages. The application usually works as an OLTP application. Input messages came in random order without peaks, typical scenario for the on-line users.

But sometimes the big data batch payloads come. These batches overload processing orchestrations. All processes, activated by on-line users after the payload, come to the same queue and are processed only after the payload. Result is on-line users can see significant delay in processing. It can be minutes or hours, depending of the batch size.

Requirements:

On-line user’s processing should work without delays. Big batches cannot disturb on-line users. There should be higher priority for the on-line users and the lower priority for the batches.

Design:

Decision is to divide the message flow in two branches, one for on-line users and second for batches. Branch with batches provides messages to the processing line with low priority, and the on-line user’s branch – with high priority.

All messages are provided by hi-speed receive port.

BTS.ReceivePortName context property is used for routing. The Router orchestration separates messages sent from on-line users and from the batch messages.

But the Router does not use the BizTalk provided value of this property, the Router set up this value by itself. Router uses the content of the messages to decide if it is from on-line users or from batches.

The message context property the BTS.ReceivePortName is changed respectively, its value works as a recipient address, as the “To” address for the next recipient orchestrations.

Those next orchestrations are the BatchBottleneck and the MainProcess orchestrations.

Messages with context equal “ToBatch” are filtered up by the BatchBottleneck orchestration. It is a unified convoy orchestration and it throttles the message flow, delaying the message delivery to the MainProcess orchestration.

The BatchBottleneck orchestration changes the message context to the “ToProcess” and sends messages one after another with small delay in between. Delay can be configured in the BizTalk config file as:

                <appSettings>
                                <add key="GLD_Tests_TwoWayRouting_BatchBottleneck_DelayMillisec" value="100"/>
                </appSettings>

 

Of course, messages with context equal “ToProcess” are filtered up by the MainProcess orchestration.

 

---

NOTES:

• Filters with string values: In Orchestrations (the first Receive shape in orchestration) use string values WITH quotes; in Send Ports use string values WITHOUT quotes.
• Filters on the Send Ports are dynamic; we can change them in run-time. Filters on the Orchestrations are static; we can change them only in design-time.
• To check the existence of the promoted property inside orchestration use the Expression shape with construction like this:
        if (BTS.ReceivePortName exists myMessage) { …; }
  It is not possible in the Message Assignment shape because using the “if” statement inside Message Assignment is prohibited.
• Several predefined context properties can behave in specific way. Say MessageTracking.OriginatingMessage or XMLNORM.DocumentSpecName, they are required some internal rules should be applied to the format or usage of this properties. MessageTracking.* parameters require you have to use tracking and you can get unexpected run-time errors in some cases. My recommendation is - use very limited set of the predefined context properties.
• To “attach” the new promoted property to the message, we have to use correlation. The correlation type should include this property. [Here is a good explanation by Saravana ]

The sample code is here [sorry, temporary trubles with CodePlex].

 

© Geeks with Blogs or respective owner