BizTalk: Suspend shape and Convoy
- by Leonid Ganeline
Part 1: BizTalk: Instance Subscription and Convoys: Details
This is a Part 2.
I am discussing the Suspend shape together with Convoys and going to show that using them together is undesirable.
In previous article we investigated the Instance Subscriptions and how they could create situation with dangerous zones in processing.
Let' start with Suspend shape. [See the BizTalk Help]
"You can use the Suspend shape to make an orchestration instance stop running until an administrator explicitly intervenes, perhaps to reflect an error condition that requires attention beyond the scope of the orchestration. All of the state information for the orchestration instance is saved, and will be reinstated when the administrator resumes the orchestration instance.
When an orchestration instance is suspended, an error is raised. You can specify a message string to accompany the error to help the administrator diagnose the situation."
On the Suspend shape the orchestration is stopped in the Suspended (Resumable) state. Next we have two choices, one is to resume and the second is to terminate the orchestration.
Is the orchestration is stopped or unenlisted? You don't find a note about it anywhere. The fact is the Orchestration is stopped and still enlisted. It is very important.
So again, the suspended orchestration can be resumed or terminated. The moment when the operator or the operation script resumes or terminates can be far away. It is also important too.
Let's go back to the case from previous article. Make sure you notice the convoy and the dangerous zone after the last Receive shape.
Now we have a Suspend shape inside the orchestration.
The first orchestration instance is suspended. Next messages start new orchestration instance and have been consumed by this orchestration, right? Wrong!
The orchestration is stopped on the Suspend shape but still enlisted. Now the dangerous zone, the "zombie zone" is expanded to the interval between the last receive and the moment of termination or end of the orchestration. The new orchestration instance for this convoy will not start till this moment. How fast operator finds out this suspended orchestration? Maybe hours or days. All this time orchestration is still enlisted and gathering the convoy messages. We can resume the orchestration but we cannot resume these messages together with orchestration.
Seems the name Suspended of the orchestration is misleading. The orchestration can be in the Started (and Enlisted)/Stopped (and Enlisted)/Unenlisted state. The Suspend shape switches orchestration exactly to the Stopped state. The Stop name would describe the shape clearly and unambiguously and the Stopped state would describe the orchestration.
Imagine we can change the BizTalk.
The Orchestration editor can search these situations and returns the compile error. In similar case the Orchestration Editor forces us to use only ordered delivery port with convoys.
The run-time core can force the orchestration with convoy be suspended in Unresumable state, that means the run-time unenlists the orchestration instance subscriptions.
The Suspend shape name should be changed. The "Suspend" name is misleading. The "Stop" name is clear and unambiguous. The same for the orchestration state, it should be “Stopped” not “Suspended (Resumable)”.
Conclusion:
It is not recommended using a Suspend shape together with the convoy orchestrations.
