views:

234

answers:

1

I recompiled a library of CRM 3.0 callouts and deployed them to my CRM 4.0 instance. One of my PostUpdate callout calls service.Update(). This is causing the update method to fire many times. It eventually stops due to timeout errors. This does not happen when these callouts are used with CRM 3.0.

The method signature is as follows for the entry point to this custom code.

public override void PostUpdate(CalloutUserContext userContext, CalloutEntityContext entityContext, string preImageEntityXml, string postImageEntityXml)
+1  A: 

One of the attributes on the IPluginExecutionContext is a depth. This indicates how 'deep' in the plugin 'call-stack' your plugin is executing. When you press save on the CRM Form you start at a depth of 1. Each time your post update calls update, the depth is increased.

You'll find some people will just check that the depth is equal to 1 before executing their plugin logic. This isn't right for everybody, however. If a workflow were to update this entity, then the depth would be 2 (workflow was 1, now your update is 2).

When the depth hits 8, CRM stops the execution calling it recursive. I'm not sure if you're actually hitting a timeout or this error. Its been a long time since I've seen what error they throw.

We've developed custom code throughout our solution where we have to check for recursion. I'm not in a position to share all of this, but you can have the idea if you like it.

Another couple of ideas is to add a custom attribute to your entity. Don't put it on the form. Normally that attribute wouldn't exist in your update property bag. When you call update from code that should short-circuit your update plugin next time, set the attribute. If the attribute is set, you would short circuit and not process the plugin.

Hope this helps.

benjynito
I'm using a callout not a plugin. See the line of code I've added to my question. I'm thinking about adding a new property, but it is troubling that this was not required when the callout was executed in crm 3.0
KClough
I found the issue, when I was testing in crm 3.0 the entities had the first name field populated. In crm 4.0 they didn't and the buisness logic was preventing this from looping. Thanks.
KClough