BizTalk: Sample: Context routing and Throttling with orchestration

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 use the host instance level throttling). This sample demonstrates the throttling with orchestration convoy, that slows down a 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.
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.
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 one 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. Ideally we should use two receive ports or two receive locations and BizTalk set up the context property for us. If we use the same context for both messages (the same port and location), we need to use orchestration to modify the context property using content of the messages or something else.
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:

                                <add key="GLD_Tests_TwoWayRouting_BatchBottleneck_DelayMillisec" value="100"/>
Of course, messages with context equal “ToProcess” are filtered up by the MainProcess orchestration.

  • 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 ]
  • Say we have two correlation types, each with one parameter inside. If we want to correlate to both parameters simultaneously, we cannot use both correlation types, we have to create the correlation type with both parameters and use this type. Otherwise only one correlation type would be chosen for correlation, that means only parameter would be used for correlation.


Print | posted on Sunday, February 27, 2011 3:04 PM


# re: BizTalk: Sample: Context routing and Throttling with orchestration

left by Ryan CrawCour at 3/23/2011 6:38 AM Gravatar
this is pretty cool! i was going to ask why you chose the router to change the context properties, could you not do multiple receive ports / locations for some reason?
other than that, i quite like the BatchBottleneck process ...

# re: BizTalk: Sample: Context routing and Throttling with orchestration

left by Leonid Ganeline at 3/23/2011 8:05 AM Gravatar
Hi Ryan,
All messages come to one receive location several "hops" before this router orchestration. This sample is just a small part of a whole picture.

# re: BizTalk: Sample: Context routing and Throttling with orchestration

left by chinna at 8/10/2011 3:01 AM Gravatar
can u provide this example with complete application

# re: BizTalk: Sample: Context routing and Throttling with orchestration

left by Leonid Ganeline at 8/10/2011 9:36 AM Gravatar
To chinna: If you look at the end of the article, there is a link to the source code. :)
Post A Comment