Persistence Point in BizTalk 2004

Introduction

This article aims to give an overview of BizTalk 2006/2004 Persistence Point for developers.

Serialization

Serialization is the process of producing an object into a certain form of information bits. In general, serialization takes place in two scenarios:

• Data Transfer: Serializing a class or structure to transfer over the network
• Persistence: Serializing an object’s current state in a permanent storage media such as disk for later use

Modern programming languages like Java and C# provide a special library to serialize an object.

Persistence Point

What if your Internet browser closed unexpectedly when you were composing a big email?
Do you re-compose again? Let us say your email provider saves your composing mail as draft every 15 seconds automatically (e.g. Google mail), wouldn't you feel it’s a better option?
The process of saving your running orchestration state at a certain point is called persistence, in other words, storing the state into Biztalk database.

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

List of Persistence Points

Biztalk orchestration engine calls persistence operation on one of the below listed events that occurs:

• End of a transactional scope (atomic or long running)
• At debugging breakpoints
• At the execution of other orchestrations through the Start Orchestration shape
• At the Send shape (except in an atomic transaction)
• When an Orchestration Instance is suspended
• When the system shuts down in a controlled manner
• When the engine determines it wants to dehydrate
• When an orchestration instance is finished

Let us now identify persistence points in the orchestration shown below.

Diagram

The above diagram depicts the places where persistence point occurs. I will explain to you again the reason for persistence in each step.

1. No Persistence point, since the send shape is wrapped up in atomic scope
2. Atomic scope end persistence
3. Start orchestration persistence
4. Break point persistence
5. Send shape persistence; note the send shape out of atomic scope
6. End of orchestration persistence

Any .NET object used in orchestration must be marked as [Serializable], unless the object is wrapped up in atomic scope or if the objects are stateless and called by static methods or objects created /derived from System.Xml.XmlDocument.

Performance and Persistence Point

The less Persistence points you have in your orchestration, the more efficient it works. In simple terms, each persistence point hits the database to store the current instance state.
We cannot avoid such a nice feature completely in our orchestration, but it can be reduced to more database round trips using atomic scope.

Any persistence point inside the atomic scope is serialized only at the end of scope.

Performance of orchestration is really degraded, while you send more than 500 Messages to the external system using send shape loop without an atomic scope.
Do remember atomic scope is also serialized at the end.

Minimize the Persistence Point

There is no such recommendation given by Product group. But splitting your orchestration with multiple atomic scopes will minimize the persistence point. There are certain cases you cannot use atomic scope, in that case you cannot avoid persistence points.

Test Persistence Point

In order to check the number of persistent points marked per orchestration, create a new host for test TestBox say “TestHost” and deploy your orchestration in that host. (Note: Only one interface should be deployed and tested at a time). Use perfmon tool, otherwise Trigger your orchestration and Use SQL Profiler to trace and count the number calls to the bts_InsertDynamicStateInfo_<TestHost> Stored procedure.

Conclusion

In order to avoid any persistence point issue in Test phase, the developer should take care while designing an orchestration. I hope this article would help you in understanding the Persistence point in turn avoiding unnecessary database round trips.

History

• 18^th August, 2006: Initial post