重新启动异步服务后，重复的工作流程会怎样？

本文介绍了重新启动异步服务后，重复的工作流程会怎样？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我们的组织正在基于>重复工作流。但是，有时备份工作流队列遇到问题，或者由于某些原因需要重新启动服务器（更新汇总等），或者以其他某种方式发现我们必须重新启动CRM的异步服务。

Our org is planning on basing parts of our business model on the premise of recurring workflows in CRM 2011. However, we sometimes run into an issue with a backed up workflow queue, or for some reason need to restart the server (update rollups, etc.), or in some other way find we have to restart the CRM's async service.

在等待阶段的任何工作流程都会发生什么在这种情况下？

What would happen to any workflows in the "waiting" phase in this scenario?

• 我在 AsyncOperationBase 表中看到带有 waiting 状态码；当服务重新联机时，它会查看此表并相应地恢复吗？
• 在上述情况下，如果停止该服务会发生什么情况？到达其 PostponeUntil 日期？该服务是否查看所有将来未完成的和未完成日期的工作流程，并决定如何处理这些工作流程？还是工作流程完全失败了？

• I see the workflow in the AsyncOperationBase table with the "waiting" statuscode; when the service comes back online, does it look at this table and resume accordingly?
• In the above scenario, what what would happen if the service was stopped, and in the interim, the workflow reached its PostponeUntil date? Does the service look at all non-complete future and backdated workflows and decide what to with each? Or does the workflow just fail altogether?

在此过程中任何失败显然都将成为CRM系统这一要素的交易中断，并且我们必须开发一个外部组件来处理重复发生的项目。

Any fails in the process would obviously be a deal breaker for this element of the CRM system, and we'd have to develop an external component to handle recurring items.

我希望期望对此有一些说明，但是我只能猜测 WaitSubscription 类与此主题有关，但大部分没有记录。

I'd expect there to be some documentation on this, but I can only guess that the WaitSubscription class has something to do with this topic, but it's for the most part undocumented.

推荐答案

就目前而言，由于异步过程看似黑盒子，因此我们决定使用外部服务来管理此问题。跟踪对数据库服务器的调用确实会显示对 AsyncOperationBase 表的大量调用，这使我相信该服务始终会检查作业是否已完成，但是在没有极端测试的情况下，就目前而言，针对此要求使用单独的服务更加安全。

For now, we've decided to go with an external service to manage this, due to the seemingly black box nature of the async process. Tracing the calls to the database server does show a lot of calls to the AsyncOperationBase table, which tends to make me believe the service always checks to see if a job is being done, but in the absence of extreme testing, for now it's more secure to use a separate service for this requirement.