It has interesting behavior and it is not always what we are waiting for.
An orchestration can be enlisted with many subscriptions. In other word it can have several Receive shapes. Usually the first Receive uses the Activation subscription but other Receives create the Instance subscriptions. [See “Publish and Subscribe Architecture” in MSDN]
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].
Let's experiment started.
There are three typical scenarios.
First scenario: everything is OK
Activation subscription for the Sample message is created when the orchestration the SampleProcess is 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: no consumers
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 of Messaging, and we can see its Error Description:
The second service instance has the ServiceClass of RoutingFailureReport, and we can see its Error Description:
Third scenario: something goes wrong
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 of 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 received 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 starts 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.
