Вопрос по – Почему в моем рабочем процессе CRM срабатывает защита от бесконечного цикла?

8
Update

Я должен был добавить с самого начала - это в Microsoft Dynamics CRM2011

Я хорошо знаю CRM, но затрудняюсь объяснить поведение моего текущего развертывания.

Пожалуйста, прочтите схему моего сценария, чтобы помочь мне понять, какое из моих предположений / пониманий неверно (и, следовательно, что является причиной этой ошибки). Это не соответствует моим ожиданиям.

Basic Scenario

Requirement demands that a web service is called every X minutes (it adds pending items to a database index) I've opted to use a workflow / custom entity trigger model (i.e. I have a custom entity which has a CREATE plugin registered. The plugin executes my logic. An accompanying workflow is started when "completed" time + [timeout period] expires. On expiry, it creates a new trigger record and the workflow ends). The plugin logic works just fine. The workflow concept works fine to a point, but after a period of time the workflow stalls with a failure:

This workflow job was canceled because the workflow that started it included an infinite loop. Correct the workflow logic and try again. For information about workflow logic, see Help.

  Итак, в двух словах - стандартное обнаружение бесконечного цикла. Я понимаю концепцию и почему она существует.

Specific deployment

Во-первых, я думаю, что для нас вполне безопасно игнорировать содержимое кода плагина в этом сценарии. Он работает нормально, он атомарный и почти не затрагивает CRM (чтобы быть понятным, это плагин перед событием, который запускает удаленную веб-службу, ожидает ответа и затем устанавливает атрибут «дата завершения / завершения» в моем триггере). запись перед передачей целевого объекта обратно в конвейер). Пока создается запись триггера, этот код выполняется и делает то, что должен.

Не обращая внимания на содержание плагина, может возникнуть проблема, которую я не ценю, зарегистрировав плагин на этапе предварительного создания объекта ...

Так что это оставляет рабочий процесс сам по себе. Это просто. Это работает так:

On creation of a new Trigger entity... it has a Timeout of Trigger.new_completedon + 15 minutes on timeout, it creates a new Trigger record (with no "completed on" value - this is set by the plugin remember) That's all - no explicit "end workflow" (though I've just added one now and will set it testing...)

С помощью этой настройки я вручную создаю новую запись триггера, и процесс красиво превращается в действие. Бросьте вперед 1 ч 58 мин (основываясь на последнем цикле, который я запустил, помня, что мой код плагина может занять минуту, чтобы завершить работу), после 7 циклов успешного выполнения (т. Е. Создание и выполнение новых заданий рабочего процесса), восьмой сбой с вышеупомянутая ошибка.

What I already know (correct me where I'm wrong)

Глубина рекурсии по умолчанию установлена на 8, Если рабочий процесс / плагин вызывает себя 8 раз, то обнаруживается бесконечный цикл.

Глубина рекурсии сбрасывается каждый час (или 10 минут - см. «Предупреждения»; в связанном блоге?)

Настройки глубины рекурсии могут быть установлены через PowerShell или код SDK, используяВеб-служба развертывания in an on-premise deployment only (через командлет Set-CrmSetting)

What I don't want to hear (please)

"Change recursion depth settings"

Я не могу изменить настройки глубины рекурсии развертывания, поскольку это не вариант в онлайн-сценарии - в конечном итоге я буду развертывать и в CRM Online.

& Quot;Increase the timeout period on your workflow& Quot;

Это также не вариант - переиндексация должна происходить каждые 15 минут, в идеале раньше.

Update

@Boone предложил ниже, что тайм-аут глубины рекурсии сбрасывается через 60 минутinactivity а не каждые 60 минут. В этом и заключается первое недоразумение.

Обсуждая с @alex, я предположил, что CorrelationId может сохраняться между созданием сущности через рабочий процесс и рабочим процессом, который порождает ультимативы ... Ну, есть. CorrelationId одинаков как в плагине, так и в рабочем процессе, а также во всех записях, которые спулируют из этого потока. Сейчас я ищу способы отделить CorrelationId (или, возможно, создание записей) от сущности и рабочего процесса.

Рабочий процесс вызывает сам себя, поэтому вы попадаете в бесконечный цикл. Вам придется переосмыслить весь подход, увеличение глубины или времени ожидания приведет только к задержке уничтожения процесса из-за бесконечного цикла. Alex
Я полагаю, что в этом случае можно было бы отделить процесс, переместив плагин, который устанавливает «время завершения». быть асинхронным и, возможно, послеоперационным ... Я думаю, я тоже попробую. Интересно услышать ваши независимые выводы тоже :) Greg Owens
Перемещение точки выполнения плагина и / или изменение на асинхронный не только создает для меня различные проблемы (не преодолимые, чтобы быть справедливыми), но, что более важно, не имеет значения для корреляции. Greg Owens
Спасибо за твой ответ, Алекс. Ты сделал это звучащим просто, но я не думаю, что это так. Даже если мы примем, что рабочий процесс вызывает сам себя (MSCRM думает, что это так, я думаю, что это не так - рабочий процесс создает новую запись, а не явно вызывает себя снова как дочерний рабочий процесс. Я ожидаю, что это будет новым ; thread & quot; - хотя, возможно, CorrelationId плагина наследуется от родительского и передается последующим дочерним рабочим процессам), глубина рекурсии должна сбрасываться каждые 10 или 60 минут, но это не так. Greg Owens
Я полагаю, что MSCRM на самом деле распознает косвенную рекурсию, происходящую там именно благодаря CorrelationId, поэтому и начинается обнаружение цикла. Я заинтригован, немного поэкспериментирую и вернусь к вам (это на самом деле может быть полезно и мне) , кто знает, получу ли я аналогичное требование / когда? '(:) Alex

Ваш Ответ

2   ответа
3

Я бы предложил другой подход: развернуть простое приложение вместе с CRM и позволитьit вызовите веб-службу, которая, в свою очередь, может использовать конечные точки XRM для изменения записей.

UPDATE

Или, вы можете попробовать что-то вроде этого при инициализации вашей службы crm в плагине (откопал его из одного из моих плагинов), оставив ваш рабочий процесс без изменений:

CrmService service = new CrmService();
//initialize service here, then...

CorrelationToken newtoken = new CorrelationToken();
newtoken.CorrelationId = context.CorrelationId;
newtoken.CorrelationUpdatedTime = context.CorrelationUpdatedTime;

// WILD GUESS: Enforce unlimited depth ?
corToken.Depth = 0; // THIS WAS: context.Depth;

//updating correlation token
service.CorrelationTokenValue = corToken;

Я признаю, что не очень много помню об этом (код датируется около 2 лет назад), но это может помочь.

@GottDibbs Я думаю, что для меня были следующие проблемы: а) отсутствие оценки того, что значение тайм-аута является «тайм-аут после бездействия»; и b) что корреляция сохраняется между плагином и рабочим процессом, даже если они не чувствуют себя так тесно связанными, как этоin this scenario... Предложение Алекса в принципе обоснованно (или в версии 4), но я не уверен, что это будет осуществимо в 2011 году (в частности, CRM Online). Greg Owens
Еще раз спасибо, Алекс. Я знаю, что есть множество способов разработать решение, которое бы преследовало одну и ту же цель, но у каждого тоже есть свои недостатки. Я хочу полностью понять проблемы, с которыми я сталкиваюсь в этой модели, прежде чем обесценивать ее из-под контроля. Поведение, которое я здесь вижу, не соответствует моему пониманию документации. Я скорее чувствую, что этоis возможно, но могут потребоваться определенные вещи, которые будут сделаны немного по-другому. Greg Owens
+1 Хотя это более агрессивный подход, чем я мог надеяться, это, вероятно, тот путь, по которому я пошел в конце. Надеемся, что получит лучшее понимание того, почему это происходит из-за этого вопроса. Заинтригованный анекдотическим поведением Буна "60 минут бездействия" период. Greg Owens
@ Грег, я добавил код, который мог бы помочь (или нет, у меня нет способа проверить это)
3

у вас не должно быть активности в течение часа. Он не сбрасывается всего за 1 час от оригинала. Таким образом, поскольку у вас есть активность каждые 15 минут, у нее никогда не будет возможности сбросить. Я нигде не знаю, что сказано в камне ... но по своему опыту.

В CRM 4 можно было создать службу CRM (Googleсоздание службы CRM в дочернем конвейере) и сбросить идентификатор корреляции (используя CorrelationToken.NewToken ()). Я не вижу ничего такого простого в SDK 2011 года. Не знаю, сработал ли этот трюк в онлайн-среде. Совместим ли 2011 онлайн с плагинами CRM 4?

Одна вещь, которую вы могли бы попробовать, это использовать IExecutionContext.CorrelationId для очистки таблицы асинхронных операций (системное задание). Но в соответствии с метаданными, атрибут, который я считаю полезным (CorrelationId, CorrelationUpdatedTime, Depth), НЕ подходит для обновления.Maybe Вы могли бы удалить строки? Даже это не может помочь.

Хорошо продуманный вопрос, кстати. Надеюсь, мне не придется обновлять мои изменяющие корреляцию плагины CRM 4 в изолированной онлайн-среде :)
Да - это может быть трудно достичь в песочных плагинах. Я не думаю, что вы можете использовать рефлексию (которая может быть использована для доступа к приватному члену / сеттеру). В онлайн-среде вы вполне можете ограничиться внешним сервисом. Даже если вы смогли заставить код Алекса работать, вы не хотите устанавливать CorrelationId из предыдущего контекста, вы хотите использовать новый Id (в этом суть).
+1 @Boone - я нашел подтверждение (с сильным подтекстом), что "60 минут" период действительно 60 минут бездействия. Смотрите ссылку ниже - обратите внимание, что имя свойства является МинInactive секунды:link Greg Owens
(Сильный смысл) - это, как правило, лучшее, что вы получаете, лол. Я полагаю, вы собираетесь искать другой способ заставить ваши требования работать в 2011 году?
Спасибо Бун. Я не считал "один час" что означает 60 минут бездействия и все еще изо всех сил, чтобы прочитать SDK, чтобы иметь в виду это - но интересно услышать, что это ваш опыт (не удивительно, если документы неточны ...!). Я очень кратко подумал о том, чтобы сделать что-то с CorrelationId, не пройдя весь путь его регистрации и проверки в качестве причины (что я сейчас и сделаю, следуя комментариям Алекса выше), но отметил, что у него есть только геттер, поэтому его нельзя обновить. Я не верю, что плагины v4 действительны для CRM Online, поэтому уловка службы CRm также не будет жизнеспособной, как я боюсь. Greg Owens

Похожие вопросы