Introduction

BizTalk uses the persistence points to save the orchestrations state to the SQL Server, allowing BizTalk to recover from this points when an error happens.

This is very important when we design our orchestrations because each persistence point involves a lot of SQL Server work and affects the performance.

Also, we need to understand the persistence points in our orchestrations because when an orchestration is suspended and we resume it, the orchestration starts the work again from the last persistence point achieved.

Which are this Persistence Points?

In a usual scenario, the persistence points in an orchestration are in these points:

1) End of a transactional scope (atomic or long running)
2) At the Send Shape, except when the shape is inside of an atomic transaction.
3) At the end of the orchestration
4) Executing other orchestrations with Start Orchestration shape.

Also in these points:

5) When an orchestration instance is suspended.
6) When the orchestration instance is finished.
7) When the system shutdowns in a controlled manner.
8) When the engine determines it wants to dehydrate.

These persistence points induce latency in the execution of our orchestration because BizTalk has to save the state at this points on database and this trips to the SQL Server increase the latency of the execution

↑Back To Top


Testing

Now, let's play with Persistence Points and Resume Instances feature.

The application will be very simple, an orchestration that invokes a .Net library that divide the input where we have two code versions.

Version 1 fails if we send 0 as second parameter:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
 
 
namespace PersistencePoints.Libraries
{
    [Serializable]
    public class DivideFunction
    {
        public double DivideMethod (int num1, int num2)
        {
            return num1 / num2;
        }
    }
}

Version 2 checks if we send 0 as second parameter, then returns 0 and not fail:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
 
 
namespace PersistencePoints.Libraries
{
    [Serializable]
    public class DivideFunction
    {
        public double Divide(int value1, int value2)
        {
            if (value2 == 0)
                return 0;
 
 
            return value1 / value2;
        }
    }
}

↑Back To Top


Without Persistence Points between Receive and Send

First we will see the BizTalk behaviour when executing an orchestration without Persistence Points between Receive and Send


This orchestration is very simple, only we invoke the .NET class on "Call Divide Component" Shape, with the input values that we receive on the Input Message.

In this scenario, if there are any error after receive shape, when we Resume the instance, we restart the orchestration from the beginning.

First we will try with my Version 1 of the C# component. If I send a correct input:

Value 1 = 10
Value 2 = 10

The execution between traces is this:


If we send this input message:

Value 1 = 10
Value 2 = 0

The orchestration will fail and the instance will be Suspended after the receive:


At this moment, if we update the GAC with the Version 2 of the C# component, restart de Host Instance and Resume the Instance, it will restart the work at the beginning:


↑Back To Top


Send Shape between Receive and Send


Let's see how is the BizTalk behaviour when we add a Send Shape between Receive and Send. This new shape is a persistence point in the middle of our orchestration.


In this scenario, if there are any error after Receive_1 and before Send_1, when we Resume the instance, we restart the orchestration from the beginning. If the error is after Send_1, when we Resume the instance, it will continue after Send_1.

If we try with  Version 1 of the C# component with incorrect input:


At this moment, if we update the GAC with the Version 2 of the C# component, restart de Host Instance and Resume the Instance, it will continue the execution after Send_1:


↑Back To Top


Send Shape between Receive and Send in an atomic transaction scope


If we add a Send Shape between Receive and Send in a atomic transaction scope, the new Persistence Point is not the Send Shape added, now is the end of the Atomic Scope.


In this scenario, if there are any error after receive shape, when we Resume the instance, we restart the orchestration from the beginning.
If we use Version 1 of the C# component with incorrect input:

At this moment, if we update the GAC with the Version 2 of the C# component, restart de Host Instance and Resume the Instance, it will restart the work at the beginning:


↑Back To Top


Conclusion

We don't take care of Persistence Points usually when we are developing, but a bad orchestration design will introduce some unnecesary latencies and performance problems.


A typical example is if we have two Send Shapes together:

Orchestration persistence

On the left we have two persistence points and on the right we have only one, then on the left we are doing an unnecesary trip to the SQL Server to save the state and obviously this affects the performance of our orchestrations.


See Also

A great place to start learning about the BizTalk product is BizTalk Server Resources on the TechNet Wiki 

↑Back To Top


References

Information available at following websites was referred while writing this article.

  1. Using DebugView with BizTalk for debugging 
  2. Understanding Persistence Points in Biztalk Orchestration
  3. Orchestration Handling of Suspended Messages