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