Playing with Persistence Points in Biztalk Orchestrations

Today I want to share how BizTalk uses the persistence points and what to expect when an orchestration is suspended and we resume it.

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

1) End of an transactional scope (atomic or long running)
2) At the Send Shape, except when the shape is inside of a 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.

This persistence points induces latency in the execution of our orchestrations, because BizTalk has to save the state in this points on database and this trips to the SQL Server increase the latency of the execution.

Now, let's play with Persistence Points and Resume Instances feature. My 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:


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


SCENARIO 1: Executing 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 I 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 I send this input message:

Value 1 = 10
Value 2 = 0

My 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:

SCENARIO 2: Executing orchestration with Send Shape between Receive and Send

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.

First I will try with my 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:

SCENARIO 3: Executing orchestration with Send Shape between Receive and Send in a atomic transaction scope.

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

First I will try with my 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:

I hope this article helps to understand the Persistence Points in BizTalk.

Here are other useful links:

http://blog.aggregatedintelligence.com/2012/05/using-debugview-with-biztalk-for.html
https://blogs.msdn.microsoft.com/sanket/2006/11/12/understanding-persistence-points-in-biztalk-orchestration/
https://seroter.wordpress.com/2007/01/02/orchestration-handling-of-suspended-messages/