CODEWITHSUNDEEP
dynamics-crmdynamics-crm-4dynamics-crm-2016
pen2
pen2

Reputation: 769

CRM 4 to 2016 migration, Plugin events

I'm migrating CRM 4 to 2016 and I need to clarify something about plugins execution. In both CRM versions we have account and quote entities. Account to quote is connected with parental relation 1:N. In CRM 4 when you assigned account to different owner first Assign and next Update message was fired, but only on account entity.

In CRM 2016 I observed that Update (only update - not assign) message is fired also on quote (and other child entities if relation is set to parental). Also if quote has child entities connected with parental relation, Update message is fired on this child entities and so on. Is there any way to recognize this situation (cascade update) inside a plugin?

Upvotes: 2

Views: 156

Answers (2)

Henk van Boeijen
Henk van Boeijen

Reputation: 7918

There should be a parent context referring to the event source. You can traverse the IPluginExecutionContext.ParentContext property back to the root to find out the origin of the trigger. When you cannot find it there (e.g. when synchronous and asynchronous operations are mixed), there is no other option I'm afraid.

Technically the updates on the related entities are executed in the plugin's child pipeline. In CRM 4.0 we can only register plugin steps in the child pipeline for Create, Update and Delete messages. In CRM 2011 the event model was 'simplified' and since that version it is no longer possible to specify a pipeline. Instead, plugins registered on the PreOperation and PostOperation stages for the Create, Update and Delete messages are always registered in the child pipeline.

Upvotes: 1

pen2
pen2

Reputation: 769

There are two solutions for this problem. First one and I think this is how should I be doing this from the beginning is to make use of Filtering attributes. As you can read here it is:

A list of entity attributes that, when changed, cause the plug-in to execute. A value of null causes the plug-in to execute if any of the attributes change.

Second is partially using ParentContext mentioned by Henk - thanks for pointing me in the right direction! You must do checks as shown in method below. If anyone want to use this method should remember to test it first. It works in my case and my plugins but your plugins may be registerred on different steps, messages and entities and this method may not work for you.

public static Boolean IsInternalParentAssign(IPluginExecutionContext context)
{
    Boolean result = false;
    if (context.ParentContext != null)
    {
        IPluginExecutionContext parentContext = context.ParentContext;
        if (parentContext.MessageName == "Assign" 
            && context.Depth == 1
            && parentContext.PrimaryEntityId != context.PrimaryEntityId)
        {
            result = true;
        }
    }
    return result;
}

Upvotes: 0

Related Questions