The BizTalk orchestration run-time engine is a highly optimized service that monitors and executes orchestrations. At run time, the BizTalk Orchestration Engine executes the files that you create using Orchestration Designer.
The BizTalk Orchestration Engine performs the following tasks:
-
Creating instances of and executing orchestrations
-
Maintaining the state of a running orchestration instance so that it can be restored to memory when required
-
Performing optimizations of running orchestrations to maximize scalability, throughput, and efficient use of resources
-
Providing a reliable shutdown-and-recovery system
The orchestration engine executes orchestrations by creating individual instances of the business process. The run-time engine coordinates these multiple instances to ensure that a response message gets routed to the correct orchestration instance, by using a specialized routing pattern called correlation.
Dehydration and Rehydration
When many business processes run at the same time, memory and performance can be compromised. The BizTalk Orchestration Engine solves this problem by dehydrating and rehydrating orchestration instances. Dehydration is the process of saving the state of an active orchestration instance to the MessageBox database and then removing that instance from memory. This can happen when the orchestration engine determines that an instance has been idle for a period of time. Dehydrating the instance frees up the resources that were being used by the instance.
Dehydration
The orchestration engine calculates thresholds to determine how long an orchestration will wait for various actions to take place, and if those thresholds are exceeded, it dehydrates the instance. This can occur under the following circumstances:
-
When the orchestration is waiting to receive a message and the wait is longer than a threshold determined by the engine.
-
When the orchestration is waiting for a subscribed message.
-
When a delay in the orchestration is longer than a threshold determined by the engine.
-
Between the retries of an atomic transaction.
The orchestration engine saves the entire state of a running orchestration instance to persistent storage at various points so that the instance can later be completely restored in memory. The dehydration of orchestration instances enables the orchestration engine to have more "in-flight" instances than the physical resources of the computer running BizTalk Server would normally allow. Dehydration is automatically controlled by the orchestration engine; however, you can control the dehydration threshold by changing specific BizTalk Server configuration properties.
Rehydration
Rehydration is the reverse of dehydration. It is the process of de-serializing the last running state of an orchestration from the database or restoring the saved state of an orchestration instance from disk back to memory. The orchestration engine is triggered to rehydrate an orchestration instance when it either receives a message or when a time-out expires. It then loads the saved orchestration instance into memory, restores its state, and runs it from the point where it left off.
An orchestration can be configured to run on more than one server. After an orchestration instance has been dehydrated, it can be rehydrated on any of these servers. If one server goes down, the engine continues to run the orchestration on a different server, continuing from its previous state. The engine also takes advantage of this feature to implement load balancing across servers.