Обновление

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

---

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

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

Базовый сценарий

• Требование требует, чтобы веб-служба вызывалась каждые X минут (она добавляет ожидающихэлементов в индекс базы данных)
• Я решил использовать триггер рабочего процесса/настраиваемого объекта модель (т. е. у меня есть пользовательский объект, в котором зарегистрирован плагин CREATE. Плагин выполняет мою логику. Сопутствующий рабочий процесс запускается, когда «завершено» + [период тайм-аута] истекает. По истечении срока он создает новую запись триггера, и рабочий процесс завершается).
• Логика плагина работает нормально. Концепция рабочего процесса работает нормально до определенного момента, но через некоторое время рабочий процесс останавливается из-за сбоя:

  Это задание рабочего процесса было отменено, так как рабочий процесс, который его запустил, содержал бесконечный цикл. Исправьте логику рабочего процесса и повторите попытку. Сведения о логике рабочего процесса см. в справке.

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

Конкретное развертывание

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

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

Таким образом, остается сам рабочий процесс. Это просто. Он работает следующим образом:

1. При создании нового объекта-триггера...
2. он имеет тайм-аут Trigger.new_completedon + 15 минут
3. по тайм-ауту, он создает новую запись триггера (без "завершено" значение — это устанавливается плагином, помните)
4. Вот и все — никакого явного «конца рабочего процесса» (хотя я только что добавил его и проверю...)

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

То, что я уже знаю (поправьте меня, где я ошибаюсь)

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

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

Настройки глубины рекурсии можно установить с помощью PowerShellили кода SDK с использованием веб-службы развертываниятолько в локальном развертывании(с помощью командлета Set-CrmSetting)

Что я не хочу слышать (пожалуйста)

«Изменить настройки глубины рекурсии»

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

" Увеличьте время ожидания рабочего процесса"

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

Обновление

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

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