миграции CRM 4 до 2016, события плагина

Question

Я переношу CRM 4 в 2016, и мне нужно прояснить что-то о выполнении плагинов. В обеих версиях CRM у нас есть учетные и кодовые объекты. Счет для цитирования связан с родительским отношением 1: N. В CRM 4, когда вы назначили учетную запись другому владельцу сначала Assign и следующее сообщение Update было уволено, но только на объекте учетной записи.

В CRM 2016 я заметил, что сообщение Update (только обновление - не назначается) также запускается по котировке (и другим дочерним объектам, если отношение установлено на родительский). Также, если у котировки есть дочерние сущности, связанные с родительским отношением, сообщение об этом дочернем объекте обжалуется Update и т. Д. Есть ли способ распознать эту ситуацию (каскадное обновление) внутри плагина?

Answer 1

Существует два решения этой проблемы. Первый, и я думаю, что именно так я должен делать это с самого начала, чтобы использовать Filtering attributes. Как вы можете прочитать here:

Список атрибутов сущности, которые при изменении заставляют плагин выполнять. Значение null заставляет плагин запускаться, если какой-либо из атрибутов изменяется.

Второй частично используется ParentContext, упомянутый Henk - спасибо, что указал мне в правильном направлении! Вы должны выполнить проверки, как показано ниже. Если кто-то захочет использовать этот метод, не забудьте сначала его протестировать. Он работает в моем случае и моих плагинах, но ваши плагины могут быть зарегистрированы на разных этапах, сообщениях и сущностях, и этот метод может не сработать для вас.

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; 
} 

Answer 2

Должен быть родительский контекст, относящийся к источнику события. Вы можете пересечь свойство IPluginExecutionContext.ParentContext обратно в корневой каталог, чтобы узнать происхождение триггера. Когда вы не можете найти его там (например, когда синхронные и асинхронные операции смешаны), другого варианта я не боюсь.

Технически обновления связанных объектов выполняются в дочернем конвейере плагина. В CRM 4.0 мы можем регистрировать только шаги плагина в дочернем конвейере для Create, Update и Delete сообщений. В CRM 2011 модель событий была «упрощена», и с этой версии уже невозможно указать конвейер. Вместо этого плагины, зарегистрированные на этапах PreOperation и PostOperation для сообщений Create, Update и Delete, всегда регистрируются в дочернем конвейере.