1. when an account's state changes (active/inactive) a plugin sets the same state to underlying records 2. same, but for the contact entity
I've registered the plugin on the SetSate and SetStateDynamic messages. This fails if an account has more then 5 related contacts. It took me quite a while to figure out what was happening, because my test account was working just fine, but had only 2 related contacts.
But I discovered that I was getting SoapExceptions that said: "This workflow job was canceled because the workflow that started it included an infinite loop." so I looked at workflows, but nothing was there.. Turns out that the same message is returned if a plugin causes an infinite loop..
But the problem is that I do not have an infinite loop, its just that I set the state of an account, which causes the same event to be fired on contacts, so CRM thinks it entered an infinite loop. To solve this, I removed the infinite loop detection (don't set the CorrelationTokenValue).
But I do'n't think that is the best solution, so how should I set this up correctly? I thought maybe I should use child pipeline, but that can only be used on Create/Update/../ and not on SetState message
Within the plugin execute method make sure the context.Depth is not larger then 1. The Depth attribute increments each time a plugin causes another plugin to execute. So you could check the contact plugin context.Depth is not larger then 2 if you want it to still fire at least once from the account plugin .
The Depth property is only auto-incremented in your code uses the context.CreateCrmService to create the ICrmService proxy. If you create it in another way then the Depth property is not maintained
One option is to not use a plugin but to use the built in cascading rules.XrmLinq - LINQ to Dynamics CRM
http://www.xrmlinq.com - The smart way to query crm
Proposed as answer bymardukesFriday, February 5, 2010 8:15 PM
Unproposed as answer byHanno ZTuesday, February 9, 2010 1:50 PM
Within the plugin execute method make sure the context.Depth is not larger then 1. The Depth attribute increments each time a plugin causes another plugin to execute. So you could check the contact plugin context.Depth is not larger then 2 if you want it to still fire at least once from the account plugin .
One option is to not use a plugin but to use the built in cascading rules.
XrmLinq - LINQ to Dynamics CRM http://www.xrmlinq.com - The smart way to query crm
I don't think that is possible? For deleting records that is true, but this customer doesn't delete records, only sets them to inactive.
Within the plugin execute method make sure the context.Depth is not larger then 1. The Depth attribute increments each time a plugin causes another plugin to execute. So you could check the contact plugin context.Depth is not larger then 2 if you want it to still fire at least once from the account plugin .
I've tested the Depth property, the value is 1 for both the account plugin and the contact plugin that is triggered (indirectly) by the account plugin, where I expected the Depth value for contact to be 2
The Depth property is only auto-incremented in your code uses the context.CreateCrmService to create the ICrmService proxy. If you create it in another way then the Depth property is not maintained
The Depth property is only auto-incremented in your code uses the context.CreateCrmService to create the ICrmService proxy. If you create it in another way then the Depth property is not maintained
that's some interesting information. I diddn't use context.CreateCrmService because my library doesn't support the ICrmService. CAn you explain how to use cascading rules, or provide a link to where I can find information on the subject?
I don't have an links to information on cascading rules, but have a look at the properties of any 1-many relationship in the CRM customisations area - it should be fairly self-explanatory.
I've looked at the cascading rules, but there is no option for setstate. But do you mean that if you set a cascading rule for delete, this also applies to setstate? If so, that's not very well documented, none of my collegues that I've asked about it knows of this behavior.
