Por que a proteção de loop infinito está sendo acionada no meu fluxo de trabalho do CRM?

Atualizar

Eu deveria ter adicionado desde o início - isso é no Microsoft Dynamics CRM2011

Conheço bem o CRM, mas não sei explicar o comportamento na implantação atual.

Por favor, leia o esboço do meu cenário para me ajudar a entender quais dos meus pressupostos / entendimentos estão errados (e, portanto, o que está causando esse erro). Não é consistente com as minhas expectativas.

Cenário Básico

O requisito exige que um serviço web seja chamado a cada X minutos (adicionapendente itens para um índice de banco de dados)Eu optei por usar um modelo de gatilho de entidade de fluxo de trabalho / personalizado (ou seja, eu tenho uma entidade personalizada que tem um plugin CREATE registrado. O plugin executa minha lógica. Um fluxo de trabalho de acompanhamento é iniciado quandotempo "concluído" + [período de tempo limite] expira. No vencimento, ele cria um novo registro de acionador e o fluxo de trabalho é encerrado).A lógica do plug-in funciona bem. O conceito de fluxo de trabalho funciona bem até certo ponto, mas após um período de tempo, o fluxo de trabalho pára com uma falha:

Esse job de fluxo de trabalho foi cancelado porque o fluxo de trabalho que o iniciou incluiu um loop infinito. Corrija a lógica do fluxo de trabalho e tente novamente. Para obter informações sobre a lógica do fluxo de trabalho, consulte a Ajuda.

Então, em poucas palavras - detecção de loop infinito padrão. Eu entendo o conceito e porque ele existe.

Implantação específica

Em primeiro lugar, acho que é seguro ignorar o conteúdo do código do plug-in nesse cenário. Ele funciona bem, é atômico e dificilmente toca no CRM (para ficar claro, é um plug-in pré-evento que executa o serviço da web remoto, aguarda uma resposta e, em seguida, define o atributo data / hora "concluído em" no meu registro Trigger antes de passar a entidade Target de volta ao pipeline). Contanto que um registro Trigger seja criado, esse código é executado e faz o que deveria.

Tendo descontado o conteúdo do plugin, pode haver um problema que eu não aprecio em ter o plugin registrado na etapa de pré-criação da entidade ...

Então isso deixa o próprio fluxo de trabalho. É simples. Funciona assim:

Na criação de uma nova entidade Trigger ...ele tem um tempo limite de disparo.new_completedon + 15 minutosno tempo limite, ele cria um novo registro Trigger (sem o valor "concluído em" - isso é definido pelo plug-in)Isso é tudo - não há "fluxo de trabalho final" explícito (embora eu tenha acabado de adicionar um agora e irá configurar o teste ...)

Com essa configuração, eu manualmente criei um novo registro Trigger e o processo girou bem em ação. Rolar para frente 1h 58 mins (com base no último ciclo que executei - lembrando que meu código do plug-in pode demorar alguns minutos para terminar a execução), após sete ciclos de execução bem-sucedidos (ou seja, novos trabalhos de fluxo de trabalho sendo criados e concluídos), o 8º falhará erro acima mencionado.

O que eu já sei (me corrija onde eu estou errado)

A profundidade de recursão, por padrão, é definida como 8. Se um fluxo de trabalho / plug-in se chamar 8 vezes, um loop infinito será detectado.

A profundidade de recursão é redefinida a cada uma hora (ou 10 minutos - consulte "Avisos" no blog vinculado?)

Configurações de profundidade de recursão podem ser definidas via PowerShell ou código SDK usando oServiço Web de Implantação em uma implantação local apenas (através do Cmdlet Set-CrmSetting)

O que eu não quero ouvir (por favor)

"Alterar configurações de profundidade de recursão"

Não consigo alterar as configurações de profundidade de recursão de implantação, pois isso não é uma opção em um cenário on-line. Por fim, também estarei implantando no CRM Online.

"Aumentar o período de tempo limite no seu fluxo de trabalho"

Isso também não é uma opção - a reindexação precisa ocorrer a cada 15 minutos, idealmente antes.

Atualizar

@Boone sugeriu abaixo que o tempo limite de profundidade de recursão é redefinido após 60 minutos deinatividade em vez de a cada 60 minutos. Aí reside o primeiro mal-entendido.

Ao discutir com @alex, sugeri que pode haver alguma persistência de CorrelationId entre a criação de uma entidade por meio do fluxo de trabalho e o fluxo de trabalho que os últimos geram ... Bem, existe. O CorrelationId é o mesmo no plug-in e no fluxo de trabalho e em todos os registros que fazem spool desse encadeamento. Agora estou procurando maneiras de dissociar o CorrelationId (ou talvez a criação de registros) da entidade e do fluxo de trabalho.

questionAnswers(2)

yourAnswerToTheQuestion