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].
