为什么在我的CRM工作流程中触发了无限循环保护？ [英] Why is infinite loop protection being triggered on my CRM workflow?

问题描述

我应该从一开始就添加-这是在Microsoft Dynamics CRM 2011

I should have added from the outset - this is in Microsoft Dynamics CRM 2011

我非常了解CRM，但是我不知所措地解释当前部署的行为。

I know CRM well, but I'm at a loss to explain behaviour on my current deployment.

请阅读我的方案的概述，以帮助我理解我的哪些假设/理解错了（以及引起此错误的原因）。

Please read the outline of my scenario to help me understand which of my presumptions / understandings is wrong (and therefore what is causing this error). It's not consistent with my expectations.

• 要求要求每隔X分钟调用一次Web服务（它将待处理项添加到数据库索引中）


• 我选择使用工作流/自定义实体触发器模型（即，我有一个注册了CREATE插件的自定义实体。该插件执行我的逻辑。当完成时间+ [超时时间] 到期时，将启动一个伴随的工作流。在到期时，它将创建新的触发记录，工作流程结束）。


• 插件逻辑工作正常。工作流概念可以很好地工作，但是经过一段时间后，工作流因故障而停止：
  • 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:

    
    

    此工作流作业被取消是因为启动它的工作流程包括一个无限循环。更正工作流程逻辑，然后重试。有关工作流逻辑的信息，请参见帮助。

  
  

  
  
  

  特定部署

  
  
  

  首先，我认为在这种情况下我们忽略插件代码的内容是非常安全的。它工作正常，是原子的，几乎不涉及CRM（要明确，它是一个事件前插件，它运行远程Web服务，等待响应，然后在传递之前在我的触发器记录上设置完成日期属性）目标实体返回到管道中）。只要创建了触发器记录，该代码就会运行并执行应做的事情。

  Specific deployment

  Firstly, I think it's quite safe for us to ignore the content of the plugin code in this scenario. It works fine, it's atomic and hardly touches CRM (to be clear, it is a pre-event plugin which runs the remote web service, awaits a response and then sets the "completed on" date/time attribute on my Trigger record before passing the Target entity back into the pipeline) . So long as a Trigger record is created, this code runs and does what it should.

  在对插件的内容打折的情况下，在实体的预创建步骤中注册了插件可能会令我不满意。 。

  Having discounted the content of the plugin, there might be an issue that I don't appreciate in having the plugin registered on the pre-create step of the entity...

  这样就剩下了工作流程本身。这很简单。这样运行：

  So that leaves the workflow itself. It's a simple one. It runs thusly:

  
  
  1. 创建新的触发器实体时……
  
  
  2. 它具有一个Trigger.new_completedon的超时+ 15分钟
  
  
  3. 超时后，它将创建一个新的Trigger记录（没有 completed on值-该值由插件记住）
  
  
  4. 仅此而已-没有明确的最终工作流程（尽管我现在刚刚添加了一个，并将对其进行测试...）
  
  
  1. On creation of a new Trigger entity...
  2. it has a Timeout of Trigger.new_completedon + 15 minutes
  3. on timeout, it creates a new Trigger record (with no "completed on" value - this is set by the plugin remember)
  4. That's all - no explicit "end workflow" (though I've just added one now and will set it testing...)

  通过此设置，我手动创建了一个新的Trigger记录，该过程很好地执行了起来。前滚1h 58分钟（基于我运行的最后一个周期-记住我的插件代码可能需要一分钟才能完成运行），在成功执行7个周期（即创建并完成新的工作流程作业）之后，第8个失败，

  With this set-up, I manually create a new Trigger record and the process spins nicely into action. Roll forwards 1h 58 mins (based on the last cycle I ran - remembering that my plugin code may take a minute to finish running), after 7 successful execution cycles (i.e. new workflow jobs being created and completed), the 8th one fails with the aforementioned error.

  默认情况下，递归深度设置为8 。如果工作流/插件调用自身8次，则将检测到无限循环。

  Recursion depth, by default, is set to 8. If a workflow / plugin calls itself 8 times then an infinite loop is detected.

  递归深度每隔一小时重置一次（或10分钟-请参见链接博客中的警告 ？）

  可以设置递归深度设置通过部署Web服务 仅在本地部署中（通过Set-CrmSetting Cmdlet ）

  更改递归深度设置

  我无法更改部署递归深度设置，因为这不是在线方案中的选项-最终我也将部署到CRM Online。

  I cannot change the Deployment recursion depth settings as this is not an option in an online scenario - ultimately I will be deploying to CRM Online too.

  增加工作流的超时时间

  这也不是一种选择-重新索引需要每15分钟发生一次，最好是尽快。

  This is not an option either - the reindex needs to occur every 15 minutes, ideally sooner.

  @Boone建议在 60分钟的不活动状态后重置递归深度超时，而不是每60分钟一次。

  @Boone suggested below that the recursion depth timeout is reset after 60 minutes of inactivity rather than every 60 minutes. Therein lies the first misunderstanding.

  在与@alex讨论时，我建议在通过工作流创建实体和最终获得的工作流之间可能存在CorrelationId的持久性。产生...好吧。插件和工作流以及从该线程假脱机的所有记录中的CorrelationId均相同。我现在正在研究将CorrelationId（或可能是记录的创建）与实体和工作流分离的方法。

  While discussing with @alex, I suggested that there may be some persistence of CorrelationId between creating an entity via the workflow and the workflow that ultimates gets spawned... Well there is. The CorrelationId is the same in both the plugin and the workflow and any records that spool from that thread. I am now looking at ways to decouple the CorrelationId (or perhaps the creation of records) from the entity and the workflow.

  推荐答案

  要进行一个小时的重置，您必须一个小时没有活动。它距原设置仅1小时就不会重置。因此，由于您每隔15分钟进行一次活动，因此再也没有机会进行重置。我不知道这在任何地方都是一成不变的...但是根据我的经验。

  For the one hour "reset" to take place you have to have NO activity for an hour. It doesn't reset just 1 hour from the original. So since you have an activity every 15 minutes, it never has a chance to reset. I don't know that is said in stone anywhere... but from my experience.

  在CRM 4中，可以创建CRM服务（Google 在子管道中创建CRM服务），重置相关ID（使用CorrelationToken.NewToken（））。我在2011 SDK中看不到任何简单的东西。不知道此技巧是否可以在在线环境中起作用。 2011年的在线向后兼容CRM 4插件吗？

  In CRM 4 it was possible to create a CRM Service (Google creating a CRM service in the child pipeline) and reset the correlation ID (using CorrelationToken.NewToken()). I don't see anything so easy in the 2011 SDK. No idea if this trick worked in the online environment. Is 2011 online backwards compatible with CRM 4 plug-ins?

  您可以尝试的一件事是使用IExecutionContext.CorrelationId清除异步操作（系统作业）表。但是根据元数据，我认为可能有用的属性（CorrelationId，CorrelationUpdatedTime，Depth）对于更新无效。 也许您可以删除行？即使那样也可能无济于事。

  One thing you could try would be to use the IExecutionContext.CorrelationId to scavenge the asyncoperation (System Job) table. But according to the metadata, the attribute I think might be useful (CorrelationId, CorrelationUpdatedTime, Depth) are NOT valid for update. Maybe you could delete the rows? Even that may not help.

  这篇关于为什么在我的CRM工作流程中触发了无限循环保护？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！