BizTalk: Instance Subscription: Details

BizTalk: Instance Subscription: Details

It is interesting behavior and it is not always what we are waiting for.

Orchestration can be enlisted with many subscriptions. In other word it can have several Receive shapes. Usually the first Receive creates the Activation
subscription and other Receives create the Instance
subscriptions. [See «Publish and Subscribe Architecture» in MSDN http://msdn.microsoft.com/en-us/library/dd800438(v=bts.10).aspx]

Here is a sample process.

This orchestration has two receives. It is a typical Sequential Convoy. [See «BizTalk Server 2004 Convoy Deep Dive» in MSDN by Stephen W. Thomas http://msdn.microsoft.com/en-us/library/ms942189(v=bts.10).aspx].

Let’s experiment started.

There are three typical scenarios.

First scenario: everything is working without errors

Activation subscription for the Sample message is created when the orchestration the SampleProcess is deployed an enlisted.

The Instance subscription is created only when the SampleProcess orchestration instance is started and it is removed when the orchestration instance is ended.

So far so good, the Message_2 was delivered exactly in this time interval and was consumed.

Second scenario:

Three Sample_2 messages were delivered. One was delivered before the SampleProcess was started and before the instance subscription was created. Second message was delivered in the correct time interval. The third one was delivered after the SampleProcess orchestration was ended and the instance subscription was removed.

Note:

  • It was not the first Sample_2 was consumed. It was first in the queue but in was not waiting, it was suspended when it was delivered to the Message Box and didn’t have any subscribers at this moment.

The first and the last Sample_2 messages were Suspended (Nonresumable) in the Message Box. For each of this message we have got two (!) service instances associated with this suspended message. One service instance has the ServiceClass as Messaging, and we can see its Error Description:

The second service instance has the ServiceClass as RoutingFailureReport, and we can see its Error Description:

Third scenario:

Two Sample_2 messages were delivered. Both were delivered in the same interval when the SampleProcess orchestration was working and the instance subscription was created and was working too.

First Sample_2 was consumed. The second Sample_2 has the subscription but the subscriber, the SampleProcess orchestration, will not consume it. After the SampleProcess orchestration is ended (And only after! I will discuss this in the next article.), it is suspended (Nonresumable). In this time only one service instance associated with this kind of scenario is suspended. This service instance has the ServiceClass as Orchestration, and we can see its Error Description:

In the Message tab we will see the Sample_2 message in the Suspended (Resumable) status.

Note:

  • This behavior looks ambiguous. We see here the orchestration consumes the extra message(s) and gets suspended together with those extra messages. These messages are not consumed in term of «processed by orchestration». But they are consumed in term of the «delivered to the subscriber». The receive shape in the orchestration is not receive these extra messages. But these messages are routed to the orchestration.

Unified Sequential convoy

Now one more scenario.

It is the unified sequential convoy. That means the activation subscription is for the same message type as it for the instance subscription. The Sample_2 message is now the Sample message. For simplicity the SampleProcess orchestration consumes only two Sample messages. Usually the orchestration consumes a lot of messages inside loop, but now it is only two of them.

First message start the orchestration, the second message goes inside this orchestration. Then the next pair of messages follows, and so on.

But if the input messages follow in shorter intervals we have got the problem.

We lost messages in unpredictable manner.

Note:

  • Maybe the better behavior would be if the orchestration removes the instance subscription after the message is consumed, not in the end on the orchestration. Right now it is a «feature» of the BizTalk subscription mechanism.

Оставьте комментарий

Filed under BizTalk

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s