Переход с CRM 4 на 2016, события плагинов

Question

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

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

Answer 1

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

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

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

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 сообщения всегда регистрируются в дочернем конвейере.