Several colleagues and myself where asking this question a couple of days ago and no one knew the answer. Most references only state that the following list costs you a persistence point;
- End of a transactional scope (atomic or long running)
- At the execution of other orchestrations through the Start Orchestration shape
- At the Send shape (except in an atomic transaction)
- At the end of the orchestration
- When an Orchestration Instance is suspended
- When the system shutdowns in a controlled manner
- When the engine determines it wants to dehydrate
- When an orchestration instance is finished
Using performance monitor to count the number of persistence point I discovered that the orchestration did not create a persistence point for the call shape. The one persistence point is due to the send shape.
Now why where we interested in this? We wanted to call the Business Rules Engine several times in a low latency scenario and everyone thought that it would this might create a persistence point each time the rules where called. I was quite pleased with my result but I had a vague memory that back in BizTalk 2004 you needed to enclose the Call rules shape in an atomic transaction. A quick search showed me that in BizTalk 2006 this requirement was dropped. http://biztalkmessages.vansplunteren.net/2008/06/13/call-rules-shape-atomic-transactions-and-the-orchestration-designer/
Continuing my search I found that Bill Chestnut has logged a documentation bug about it. It makes a lot of sense to not add extra persistence point unnecessarily to a lot of orchestrations. You can still add an atomic shape around the call rules shape if you want one?