BizTalk Orchestration – Understanding Persistence points

In BizTalk Server, an orchestration is more than just a workflow; it is a durable process. To ensure that a business process doesn’t vanish if a service restarts or a server fails, BizTalk uses Persistence Points.

What are Persistence Points?

Often ignored, but really important, persistence points in BizTalk Server are the key issue in dealing with Orchestration Performance. The SQL Server does the bulk of the job at the backend to keep the BizTalk server running. BizTalk Server has this inherent behavior of saving the orchestration state to SQL Server so as to quickly and easily recover from any failures. Persistence points are those points in the orchestration that save the orchestration state to the database.

Persistence Points induce latency in Biztalk Orchestrations, though you cannot avoid them; understanding them would help in using them efficiently

The orchestration engine saves the state of a running orchestration instance at various points. If the engine must rehydrate the orchestration instance, start from a controlled shutdown, or recover from an unexpected shutdown, the engine runs the orchestration instance from the last persistence point, as if nothing else had occurred.

List of persistence points

Orchestration engine persists your running instance based on how you designed your orchestration. There are a few events or stages that trigger the persistence operation called persistence points:

• Persistence at the BizTalk Engine level
  • When an Orchestration Instance is suspended
  • When the system shuts down in a controlled manner
    • The system shuts down under controlled conditions. Note that this does not include abnormal termination; in that case, when the engine next runs, it will resume the orchestration instance from the last persistence point that occurred before the shutdown.
  • When the engine determines it wants to dehydrate
  • When an orchestration instance is finished
• Persistence in the orchestration level
  • The end of a transactional scope is reached (atomic or long-running)
    • The engine saves the state at the end of a transactional scope. Therefore, the point at which the orchestration resumes is defined unambiguously. Compensation can be performed correctly if it is necessary.
    • The orchestration will continue to run from the end of the scope if persistence was successful; otherwise, the appropriate exception handler will be invoked.
    • If the scope is transactional and atomic, the engine will save state within that scope
    • if the scope is transactional and long-running, the engine will generate a new transaction and persist the complete state of the runtime.
  • At the execution of other orchestrations through the Start Orchestration shape
    • The orchestration starts another orchestration asynchronously. Note: Call orchestration shapes do not cause persistence points
  • At the Send shape
    • The only exception to this is when a message is sent from within an atomic transaction scope.
  • At debugging breakpoints

Performance and persistence point

In simple terms, the fewer persistence points you have in your orchestration, the more efficient it works. Each persistence point hits the database to store the current instance state.

The state includes

• The internal state of the engine, including its current progress.
• The state of any .NET components that maintain state information and are being used by the orchestration.
• Message and variable values.

Tips to increase performance by minimizing persistence points

• We cannot avoid such a nice feature completely in your orchestration, but we can reduce the number of database round-trips using an atomic scope.
  • Any persistence point inside the atomic scope is serialized only at the end of the scope.
  • Splitting your orchestration with multiple atomic scopes will minimize the persistence point
  • The performance of orchestration is really degraded, while you send more than 500 messages to the external system using a send shape loop without an atomic scope.
  • Do remember that the atomic scope is also serialized at the end.

Serialization

All object instances that your orchestration refers to directly or indirectly (as through other objects) must be serializable for your orchestration state to be persisted. There are two exceptions:

• You can have a non-serializable object declared inside an atomic transaction. You can do this because atomic scopes do not contain persistence points.
• System.Xml.XmlDocument is not a serializable class; it is handled as a special case and can be used anywhere.

Caution: In order for a .NET object to be persisted, it must be marked as serializable.

Persistence points are your safety net, but they are also a performance cost. By understanding where they occur, you can design orchestrations that are both resilient and high-performing.

Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.