BizTalk Server: Resource Dispenser – Send Port Edition

Article
1/17/2024

Introduction

From time to time, a performance related issue will come up on the BizTalk Forum that has its roots in Message flood scenarios. It seems the most common scenario is large file processing where thousands to tens of thousands of Messages are queued simultaneously to an Orchestration or Send Port.

When this happens to Orchestrations, throttling will kick in which can sometime be challenging to tune if BizTalk doesn’t make the right choices or if the system is not sized for flood scenarios. Equally challenging is overdriving a target system through a Send Port since we may have little or no influence on that system.

To flatten the peak activity in these scenarios, the app can implement a Resource Dispenser Pattern where Messages are tagged or queued for a limited number of receiving service instances, either Orchestrations or Send Ports. Unfortunately, Bing or that other search engine…what’s its name? ;), don’t seem to know of any good examples.

So, this article presents a simple Resource Dispenser Orchestration that targets a limited number of LOB Send Ports.

The Concept

The Resource Dispenser Orchestration is just a Receive/Send with a Message Assignment Shape that sets two Context Properties:

Resource – Identifies the resource being limited.
QueueId – The instance of the Resource to receive this Message.

In order to Promote these Context Properties so that can be used for Routing, the Send Port Initializes a Correlation Set.

For this sample, there are three Send Ports, each with a Filter by Resource and QueueId that picks up the published Messages.

Property Schema

The first item to implement is a custom Property Schema to tag the resource assigned Messages.

The properties must use the Property Schema Base of MessageContextPropertyBase so they can be set in the Orchestration. Resource is Data Type xs:string while QueueId is Data Type xs:int.

The Orchestration

Here are all of the Orchestration Designer items:

Setting up the Queued Message

The first step is to assign the QueuedLOBUpdate message which is just a copy from the received LOBUpdateToQueue.

The second step is to initialize an instance of .NET’s Random class. We’ll use this to generate the QueueId.

Finally, the Resource and QueueId Properties are set on QueuedLOBUpdate.

Quick note on Random’s Next() method: parameter represents the upper bound but is not included in the possible outputs. Because the default lower bound is 0, using 3 will give one of 3 possible values, 0, 1 and 2. Also, Random will not create an even distribution. Casual observation was about 40/30/30.

Promoting the Resource Properties

The Correlation Type consists of the two custom Properties, Resource and QueueId.

The Send Shape

The Send Shape initializes the Correlation Set to Promote the two Resource properties.

The Receiving Send Ports

This example considers an LOB application that can handle a maximum of 3 concurrent connections from our BizTalk app. To accommodate this, there are three Static Send Ports defined in BizTalk Administrator.

The Filter for each Send Port essential similar with the only difference in the QueueId.

The other two Send Ports use a Filter where the QueueId is filtered on 1 and 2.

In this case, the Send Port must be set for Ordered Delivery so each will have only on active instance.

Considerations

This sample uses Specify Later binding on the Receive Port in order to limit the incoming messages to one Receive Port. It cannot use MessageType only since that would create a circular path as Messages published by the Orchestration would have the same MessageType property Promoted.

This sample will create a new instance of the Resource Dispense Orchestration for each message. Applying the same properties in a Pipeline Component would be more efficient.

Share via