Share via

BizTalk Server: Suspend Shape and Convoy

  • Article

Introduction

I am discussing the Suspend shape together with Convoys and going to show that using them together is undesirable.

In the previous article I investigated the Instance Subscriptions and how they could create zombie situation. 

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 stopped or not enlisted? 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.

Let's go back to the case from the 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 was suspended. Third Sample message has started a new orchestration instance and have been consumed by this orchestration, right? Wrong!

The first orchestration is stopped on the Suspend shape but it is still enlisted. Now its dangerous zone, the "zombie zone" is expanded to the interval between the last receive and the moment of termination or end of this orchestration. The new orchestration instance for this convoy will not start till this moment. How fast operator finds out this suspended orchestration? Maybe hours, maybe days. All this time the first orchestration is still enlisted and is gathering the convoy messages. We can resume the orchestration but we cannot resume these messages together with orchestration. If orchestration is resumed, all these messages are not processed, they are terminated.

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 analyze these situations and raise a 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)”.

Recommendation

  • Do not use a Suspend shape inside the convoy orchestrations.

See Also

Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.