Some processes I have been implementing recently are long-running by nature. Between start and completion of the orchestration, several days can pass. This is because user intervention is required in another system.
I classified the orchestrations as "long-running". The main scope of those orchestrations, created to catch any exceptions, was also set to "long-running".
Because I required orchestration variables in a specific part of the orchestration, I was forced to create a nested (small) scope, with “atomic” transactional behaviour. That is the only option that allows the use of those variables. Because I am nesting scopes, and because the deepest scope is atomic, all surrounding scopes can only be long-running.
Classifying a scope or orchestration to “long-running” gives the BizTalk runtime engine an important hint about the expected duration of instances of the orchestration. Without knowing the exact backgrounds or terminology, I concluded that the runtime engine will change the state of a “long-running” type orchestration instance to “dehydrated” quickly. This means that the orchestration is saved in the management database until it is reactivated (or “rehydrated”).
The process of dehydration and rehydration causes overhead. An running orchestration instance, waiting for a long time without being dehydrated, causes a small but permanent load to the system. Classifying an orchestration as “long-running” will cause the BizTalk runtime engine to choose “early dehydration” as the best option for this instance.
Usually, long-running orchestrations are created to wait for multiple inputs (convoys), using correlations. Very often, multiple instances of the orchestration can be active at the same time.
Note that a long-running orchestration does not terminate by istelf. You will have to do this yourself, in runtime (via HAT) or as part of the design. At this moment. the only usable option I have seen is to include a terminate-shape in the orchestration.
When multiple instances of the same orchestration can coexist, it is sometimes hard to determine what is happening when you are testing your developments.
A very convenient tool was developed and published by Stephen Thomas. Note that this tool is only for testing purposes. I did not use the Visual Studio solution (.sln) at all. Instead, I copied the contents of the .sql file to a new query (query builder) in the HAT. The query shows which "virtual subscriptions" to correlations are active at a certain moment. When an orchestration instance is started that activates a correlation set, the orchestration becomes visible using the query. You can also see to which actual values (for instance document number, order number) the correlation has subscribed. Excellent for testing and monitoring prior to go-live.