Danny Varghese: CRM 2011 Context Depth Issue

[Blog bot]

Источник: http://varghesedanny.com/2012/08/20/...t-depth-issue/
==============

With CRM 2011 events now being transactional, i.e. when an error occurs, the requested change is rolled back, this has posed its own unique set of problems.  Here’s one I faced recently…

Background Information:

Let’s say a user enters information on a form on any entity and clicks save.  Like any other .NET web application, the data entered by the user is then submitted to the database.  Validation occurs, and if valid, the data is submitted and then finally committed to the database.  The resulting values (including any calculations done by CRM plug-ins) are returned back to the form for the user to see.

In CRM 4.0, all the values entered on a form are submitted to the database as a collection of properties (field names and values).  If any validation errors occurs, the collection of properties containing the values the user entered is NOT submitted, but rather the collection of properties before any changes are submitted.  This seems very strange, but I encountered this while writing a plug-in for a customer and after seeing some odd behavior, contacted MS support and that was the explanation they gave me.  Essentially there was no transaction rollback feature.

In CRM 2011, they fixed this issue by enabling transaction support.  That is if someone enters information into a form, it’s submitted to the database for validation.  If validation fails, the entire transaction is rolled back.  Enabling the use of transactions recently added some more complexities at a client I was at recently.

Business Scenario:

Let’s say a user was creating an invoice, and then invoice details.  As part of this client’s requirements, there was heavy customization on these entities on create and update what would update the entity itself, the parent entity, and other related entities.  The core of their business operations were in the order processing entities.

When a user clicks save, the context.depth (an integer value used by CRM to track how many calls to the CRM web service is being made in a single transaction) is 1.  CRM uses the depth value to prevent an infinite loop, because for each call to the CRM web service, the depth is incremented by 1.  Now let’s say within that transaction, a plug-in is fired to update another record, the depth value is increased to 2.  If the depth value keeps increasing and reaches a CRM 2011 on-premise configured limit of 8, an error is thrown saying there’s an infinite loop. This was an issue for our client because of the heavy processing that was needed on the order processing entities.

Solution:

Eventually I had to reach out to my friends in Microsoft because I never had to deal with this before.  Apparently in CRM 2011 online, the limit is configured at 16.  For on-premise, the limit is by default 8.  After talking to MS support, they had recommended us increasing the limit to 16 to match the online version.  To do this, we ran a simple SQL update statement against the CRM database:

UPDATE DeploymentProperties
SET IntColumn = 16
WHERE ColumnName = ‘MessageProcessorMaximumDepth’

That did the trick!  Of course any updates to the database directly is unsupported, but I found it interesting that an MS support agent recommended for us to do this.

Hope this helps someone!




Источник: http://varghesedanny.com/2012/08/20/...t-depth-issue/