理解CRM 4.0异步服务的数据结构AsyncOperationBase ( part 2)
在理解CRM 4.0异步服务的数据结构AsyncOperationBase ( part 1)中我们有张表格介绍了异步服务更种System Job的状态。这些状态通常在界面上通过登录CRM后检查系统工作列表能够看到。大家是否注意到有些jobs被现显示为失败，有些允许手动重试resume/cancel，有些可以自动恢复执行？
Gonzalo Ruiz的博客解释了背后的逻辑:
Gonzalo Ruiz: When do asynchronous jobs fail, suspend or retry?
本文概要翻译一下作为参考。
当StateCode=1时候，根据错误严重级别AsyncService有如下三种逻辑决定下一步处理办法:
- Fail: 该错误致命的，本job将不会被继续执行或者重试
- Retry: 该错误严重级别低，系统将在一定时间内自动重试执行
- Suspend: 该错误严重级别中等 - 将导致job被挂起，管理人员必须通过界面手动干预重新执行激活该job
那么错误严重级别如何决定呢？可以参看下表:
注意： AsyncOperationBase表格的ErrorCode和Message列记录了详细的错误信息.表格中工作流作为一种特殊的job，由于有人机交互的机会干预更改错误，所以很多情况下系统倾向为挂起工作流job。本表格仅是示例的一部分供参考，实际代码要复杂的多。
Scenario |
Async jobresult action |
Workflowresult action |
ErrorCode |
| An SDK call fails: Infinite loop detected | fail | fail | 80044182 |
| An SDK call fails: Organization disabled | retry | retry | 8004A104 / 8004A107 |
| An SDK call fails: Server is busy | retry | retry | 8004A001 |
| An SDK call fails: Other | fail | suspend | |
| SQL exception is thrown | retry | retry | 80040216 |
| Workflow system is paused | N/A | suspend | 80045017 |
| Network error | retry | retry | 80044306 |
| Record associated with workflow cannot be found | N/A | Suspend | 80045031 |
| The HTTP response fails with code HttpStatusCode.Unauthorized | suspend | suspend | 80044306 |
| The HTTP response fails | retry | retry | 80044306 |
| Plugin or workflow activity throws an InvalidPluginExecutionException | fail | fail | 80040265 |
| Anything else | fail | fail |
那么是否系统会无限次的自动不停重试呢？即使自动重试间隔是多长时间呢？
答案是否定的。下次自动重试的时间存储在AsyncOperationBase的PostPoneUntil列里，而PostPoneUntil是根据该表格的RetryCount来计算的 (计算公式是按照指数运算进行的，所以RetryCount越高重试等待的时间将以指数级别增长)。默认下一般系统在RetryCount>=5的时候就会挂起该job (PostponeUntil=’9999-12-30 23:59:59’)
| RetryCount | Time to wait(seconds) |
| 0 | 36 |
| 1 | 43 |
| 2 | 52 |
| 3 | 62 |
| 4 | 75 |
| >=5 | Suspend |
所以如果你在界面上看到下次执行时间若被设为时间的最大值9999就意味着只能手动干预重新运行该job了。
如果你有海量的job需要批量取消或者删除，请联系微软Dynamics CRM 售后技术支持部门，我们会提供工具批量删除/取消你的海量job.
谢谢
张立岩 (Clifford Zhang)