SharePoint Workflow Trouble Shooting（一）Task被锁住或者卡住

[译者按]Andy Li这篇文章，是我看过的最好的，最透彻的关于SharePoint Workflow架构的文章。通过阅读他的文章，我才清楚的了解了SharePoint Workflow的运作机制，并且在遇到问题的时候，知道如何下手查找问题。因此翻译过来，希望对Workflow的开发人员有帮助。本部分主要讲trouble shooting。

这篇博客是由Andy Li贡献的，他是SharePoint开发人员支持组的处理疑难问题的工程师。原文地址。这个关于Workflow的系列，是他贡献给社区的，帮助大家更好的理解Workflow运行时的内部机制，以及如何和SharePoint交互。

这篇文章由SPFarmer翻译。

前四篇地址：

宿主服务(HostService): SPWinOeHostService

SharePoint 和Workflow Runtime的结合

Workflow 事件处理管道(Event Processing Pipeline)

Workflow 事件处理(Event Processing)

Locked/StuckTasks

锁住或者卡住的task是很多人在workflow里很常见的问题。人们问我，当一个task被锁定之后，如何解锁呢？我总是这样回答：为什么这个task会被锁住呢？很多人真的不知道，是什么导致task被锁定了，而是简单想去解锁，并且希望这个能够解决问题。事实是这个只会让问题更糟糕！

实际上，是没有一个合适的方法来解锁task的。本质上，锁定task是通过把“WorkflowVersion”列设置成1来实现的(在以前的博客里我们提到过，1代表未被锁定)。 尝试解锁带来的问题是，它不知道Workflow实例到底发生了什么，Workflow实例是在哪里停止的，workflow是否期待你刚刚解锁的task有更新，等等。

因此，我们再来看一下，一个task是如何被卡主或者锁住的。首先，我们已经知道，如果一个用户通过task表单提交了一个task，这个task就会进去到锁定状态。这个锁定状态会一直持续到workflow 实例处理完 OnTaskChanged 事件 (如果你不明白为什么，那么请阅读本系列第一部分).  因此，如果你尝试重新提交这个task，无论是通过代码还是页面，你就会得到“这个task已经被锁住”的异常。你等待几个小时或者几天之后，重新提交这个task，还是会得到同样的异常，为什么呢？

下面是原因:

#1 ItemUpdated 还没有被workflow实例处理.因此task仍然处于锁定状态。

#2 ItemUpdated 从来没有到达workflow引擎 (EventDeliveryFailedException). 同样，workflow没有处理这个事件，因此task仍然处于锁定状态。

#3 workflow 已经处理了 ItemUpdated 事件，但是task仍然没有解锁(被要求这样)

#1: 让我们先来弄清楚，用户提交一个task的时候，都发生了什么。首先，我们知道一个event receiver被触发了。它会尝试输送事件到workflow。SPWorkflowManager 需要加载workflow 实例到runtime来传输这个事件。然后，如果workflow 实例处于锁定状态，SPWorkflowManager 就不能够传输这个事件了。一个 WorkItem 会被加到内容数据库的的队列里(ScheduledWorkItems 表)， timer job 会重新处理它。如果timer job没有运行，那么就没有人来处理这个事件。

#2: EventDeliveryFailedException是workflow里最著名(或者最不臭名昭著)的异常。取决于内部的异常，实际上有不同的原因会导致这个异常。最通常的情况如下：

EngineRunWorkflow: System.Workflow.Activities.EventDeliveryFailedException:

Event "OnTaskChanged" on interface type "Microsoft.SharePoint.Workflow.ITaskService" for instance id "84f908b6-0357-497c-b7cc-8021798dc706" cannot be delivered.

--->System.Workflow.Runtime.QueueException: Event Queue operation failed withMessageQueueErrorCode QueueNotFound for queue 'Message Properties  InterfaceType:Microsoft.SharePoint.Workflow.ITaskService Method Name:OnTaskChanged CorrelationValues: ff5aa7b7-b6e4-4efb-84ef-27750b17b8ca '.

atSystem.Workflow.Runtime.WorkflowQueuingService.GetQueue(IComparable queueID)

Windows SharePointServices Workflow Infrastructure Engine RunWorkflow:

System.Workflow.Activities.EventDeliveryFailedException:Event "OnTaskChanged" on interface type "Microsoft.SharePoint.Workflow.ITaskService" for instance id

"4565fe7f-6043-4e8b-8896-4565fe7f9058" can not be delivered. --->

System.NullReferenceException:Object reference not set to an instance of an object. atMicrosoft.SharePoint.Workflow.SPWorkflowHostServiceBase.LoadInstanceData (GuidinstanceId, Boolean& compressedData)

EventDeliveryFailedExceptionwith QueueNotFound

让我们先讨论QueueNotFound。  QueueNotFound 是一个workflow runtime 异常。他的意思是说，workflow并没有在等待你尝试传输给它的事件。另一种说法，对于你提交的这个task，workflow并没有等待发生在它身上的任何事件。这个还可能表示，workflow在等待task A，但是你在提交task B。简单的来说，workflow实例并没有得到它想要的事件。 

那究竟发生了什么?有好几种原因可能导致这个问题：

1. Workflow实例并没有正确的持久化。Workflow通常在没有其他事情需要处理的时候被持久化。尤其是当它运行到 OnTaskChanged activity. 持久化服务会尝试保存workflow 实例到内容数据库里。如果在持久化过程中出了问题，那么存到数据库里的是workflow实例的前一个状态。这样就完全错了。如果你在workflow里面创建了一个新的task，workflow完全不知道这是在干什么，因为最新状态的workflow实例没有被保存到数据库里。这就好像workflow 穿越到了没有创建task之前。现在，你尝试提交这个task，workflow不知道你要做什么。因此你就得到了QueueNotFound 的EventDeliveryFailedException 异常。

2. 另外一种情况就是，workflow在等待Task A，但是你提交了task B。可能导致这种情况的是correlation 参数乱套了。还记得在workflow里，你为每一个task创建了一个TaskId吗？是的，这个就是每个会话的唯一标示。每一个CreateTask 和OnTaskChanged 对需要和其他task不一样的，单独的TaskId。我们看到的最通常的情况是，人们为每一对CreateTask/OnTaskChanged使用了共享的变量。如果你的所有task都是顺次执行的，不会出问题。但是如果你的task是并行运行的，你的这种设计就肯定有问题了。Task之间共享TaskId参数会导致竞争状态。一个TaskId会被同时分配给task A和B(因为是并行的)。出现问题的几率可能比较低，但是如果你随机的得到EventDeliveryFailedException，你最好检查一下你是否使用了一个共享的TaskId。

3. Before August 2011 CU for 在SharePoint 2010的2011年8月份的CU之前, SharePoint处理事件的过程有一些问题，会导致workflow持久化到一个错误的状态。在2011年8月份的CU中，处理事件的过程更加健壮，但是在处理事件的过程中，你可能会感觉到一些延迟。因此如果你没有别的选择了，请务必保证你安装了2011年8月份的CU。

EventDeliveryFailedExceptionwith NullReferenceException

注意到，调用堆栈显示“SPWorkflowHostServiceBase.LoadInstanceData” 方法失败的了。这个是SharePoint持久化服务的一部分。 在SharePoint workflow runtime传输事件到workflow实例之前，它需要加载workflow实例到内存里。这个异常显示，workflow实例没有被正确的持久化，因为一些对象看起来是null。在2011年8月份的 CU里,我们添加了更多的诊断log到ULS里面，用来查找和持久化服务有关的问题。下面是一个例子。因此如果你不确认你的workflow是否在持久化上有问题，请在ULS里面查找下面的Log。

Failed to persistworkflow instance: 3c489d77-355c-4beb-86d4-1f106f26113c with error code: 5,

instance datasize: 34505, internal state: Running, processing id:4db2b5e9-cf02-479f-83fc-db106a432ba4   15bfccd3-663b-449e-8d37-113494e4f892

有可能导致这个异常的原因之一，是workflow执行的时间太长了。SharePoint有一个硬性的要求，如果workflow运行了20分钟还没有达到下一个持久化点，它的状态会被fail-over 的timer job重新设置。 我们以前提到过，timer job 会检测workflow是否中途出问题了(死了)。如果是这样的话，他会把窗台重新设置解锁。fail-over timer job 检测死workflow的方法是，检测这个workflow运行了多久。因为绝大多数的workflow，应该用几分钟甚至几秒钟的时间完成它的工作。因此如果在数据库里，显示这个workflow已经运行了20分钟以上，它实际上可能什么都没干(卡住了)。