¿Por qué se activa la protección de bucle infinito en mi flujo de trabajo de CRM?

Actualizar

Debería haber agregado desde el principio, esto está en Microsoft Dynamics CRM2011

Conozco bien a CRM, pero no puedo explicar el comportamiento de mi implementación actual.

Lea el esquema de mi escenario para ayudarme a entender cuál de mis suposiciones / entendimientos es incorrecto (y por lo tanto, qué está causando este error). No es consistente con mis expectativas.

Escenario basico

El requisito exige que un servicio web se llame cada X minutos (agregapendiente elementos a un índice de base de datos)Opté por usar un modelo de activación de entidad de flujo de trabajo / personalizada (es decir, tengo una entidad personalizada que tiene un complemento CREATE registrado. El complemento ejecuta mi lógica. Se inicia un flujo de trabajo complementario cuandoTiempo "completado" + [período de espera] expira Al expirar, crea un nuevo registro de activación y finaliza el flujo de trabajo).La lógica del plugin funciona bien. El concepto de flujo de trabajo funciona bien hasta cierto punto, pero después de un período de tiempo, el flujo de trabajo se detiene con una falla:

Este trabajo de flujo de trabajo se canceló porque el flujo de trabajo que lo inició incluía un bucle infinito. Corrija la lógica del flujo de trabajo y vuelva a intentarlo. Para obtener información sobre la lógica del flujo de trabajo, consulte la Ayuda.

Así que en pocas palabras - estándar de detección de bucle infinito. Entiendo el concepto y por qué existe.

Despliegue especifico

En primer lugar, creo que es bastante seguro que ignoremos el contenido del código del complemento en este escenario. Funciona bien, es atómico y apenas toca CRM (para ser claro, es un complemento previo al evento que ejecuta el servicio web remoto, espera una respuesta y luego establece el atributo de fecha / hora "completado en" en mi registro de Desencadenador antes de pasar) la entidad objetivo de nuevo en la tubería). Mientras se cree un registro de Disparo, este código se ejecuta y hace lo que debería.

Habiendo descontado el contenido del complemento, puede haber un problema que no aprecio al tener el complemento registrado en el paso previo a la creación de la entidad ...

Así que eso deja el propio flujo de trabajo. Es una simple. Funciona así:

Sobre la creación de una nueva entidad de disparo ...tiene un Timeout of Trigger.new_completedon + 15 minutesen el tiempo de espera, crea un nuevo registro de Desencadenador (sin ningún valor "completado en", esto se establece mediante el complemento recordatorio)Eso es todo, no hay un "flujo de trabajo final" explícito (aunque acabo de agregar uno ahora y lo pondré a prueba ...)

Con esta configuración, creo manualmente un nuevo registro de Desencadenador y el proceso entra muy bien en acción. Desplazar hacia adelante 1 h 58 minutos (según el último ciclo que ejecuté; recordando que mi código de complemento puede tardar un minuto en finalizar), después de 7 ciclos de ejecución exitosos (es decir, se están creando y completando nuevos trabajos de flujo de trabajo), el 8vo falla con el error mencionado anteriormente.

Lo que ya sé (corrígeme donde me equivoco)

La profundidad de recursión, por defecto, se establece en 8. Si un flujo de trabajo / complemento se llama a sí mismo 8 veces, se detecta un bucle infinito.

La profundidad de la recursión se restablece cada hora. (o 10 minutos - vea "Advertencias" en el blog vinculado?)

Los ajustes de profundidad de recursión se pueden establecer a través de PowerShell o código SDK utilizando elServicio web de despliegue solo en una instalación local (a través del cmdlet Set-CrmSetting)

Lo que no quiero escuchar (por favor)

"Cambiar la configuración de profundidad de recursión"

No puedo cambiar la configuración de profundidad de recursión de la implementación, ya que esta no es una opción en un escenario en línea; en última instancia, también lo haré en CRM en línea.

"Aumente el tiempo de espera en su flujo de trabajo"

Esta tampoco es una opción: la reindexación debe ocurrir cada 15 minutos, idealmente antes.

Actualizar

@Boone sugirió a continuación que el tiempo de espera de profundidad de recursión se restablece después de 60 minutos deinactividad En lugar de cada 60 minutos. Ahí radica el primer malentendido.

Mientras discutía con @alex, sugerí que podría existir cierta persistencia de CorrelationId entre la creación de una entidad a través del flujo de trabajo y el flujo de trabajo que se genera últimamente ... Bueno, sí lo hay. El CorrelationId es el mismo tanto en el complemento como en el flujo de trabajo y en cualquier registro que se coloque en ese hilo. Ahora estoy buscando formas de desacoplar el Id. De correlación (o quizás la creación de registros) de la entidad y el flujo de trabajo.

Respuestas a la pregunta(2)

Su respuesta a la pregunta