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

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 (или, возможно, создание записей) от сущности и рабочего процесса.

Ответы на вопрос(2)

Ваш ответ на вопрос