SharePoint Workflow Trouble Shooting (1) the Task is locked or stuck, too pointworkflow

SharePoint Workflow Trouble Shooting (1) the Task is locked or stuck, too pointworkflow

According to Andy Li, I have read the best and most thorough article on SharePoint Workflow architecture. After reading his article, I learned about the working mechanism of SharePoint Workflow and how to locate the problem. Therefore, we hope to help Workflow developers. This section describes trouble shooting.

This blog was contributed by Andy Li. He is an engineer in the SharePoint support team who handles problems. Original address. This Workflow series is contributed to the community to help you better understand the internal mechanism of Workflow runtime and how to interact with SharePoint.

This article is translated by SPFarmer.

The first four addresses:

Host Service: SPWinOeHostService

Combination of SharePoint and Workflow Runtime

Event Processing Pipeline)

Event Processing)

Locked/StuckTasks

Tasks that are locked or stuck are common problems in workflow. People asked me how to unlock a task after it is locked? I always replied: Why is this task locked? Many people really don't know what causes the task to be locked, but simply want to unlock it and hope it can solve the problem. The fact is that this will only make the problem worse!

In fact, there is no proper way to unlock a task. In essence, locking a task is implemented by setting the "WorkflowVersion" column to 1 (as we mentioned in previous blogs, 1 indicates that the task is not locked ). The problem with trying to unlock is that it does not know what happened to the Workflow instance, where the Workflow instance was stopped, and whether workflow expects the tasks you just unlocked to be updated.

Therefore, let's take a look at how a task is stuck or locked. First, we know that if a user submits a task through the task form, the task will be locked. The lock status continues until the workflow instance finishes processing.OnTaskChangedEvent (if you do not understand why, read the first part of this series ). therefore, if you try to submit this task again, whether through code or page, you will get an exception that "this task has been locked. After waiting for a few hours or a few days, you can submit the task again and you will still get the same exception. Why?

The following are the reasons:

#1 ItemUpdated has not been processed by the workflow instance. Therefore, the task is still locked.

#2 ItemUpdated has never reached the workflow engine (EventDeliveryFailedException). Similarly, workflow does not process this event, so the task is still locked.

#3 workflow has handled the ItemUpdated event, but the task is still not unlocked (required)

#1: Let's first figure out what happened when the user submitted a task. First, we know that an event handler is triggered. It will try to deliver events to workflow. SPWorkflowManager needs to load the workflow instance to runtime to transmit this event. Then, if the workflow instance is locked, SPWorkflowManager cannot transmit the event. A WorkItem will be added to the queue of the content database (ScheduledWorkItems table), and the timer job will reprocess it. If the timer job is not running, no one will handle the event.

#2: EventDeliveryFailedException is the most famous (or least notorious) exception in workflow. Depending on the internal exception, there are actually different causes that may cause this exception. The most common situation is as follows:

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 queue QueueNotFoundfor 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 Firewall pointservices 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 anobject. atMicrosoft. SharePoint. Workflow. SPWorkflowHostServiceBase. LoadInstanceData (GuidinstanceId, Boolean & compressedData)

EventDeliveryFailedExceptionwith QueueNotFound

Let's first discuss QueueNotFound. QueueNotFound is a workflow runtime exception. It means that workflow is not waiting for the event you try to transmit to it. In other words, for the task you submit, workflow does not wait for any event on it. This may also indicate that workflow is waiting for task A, but you are submitting task B. Simply put, the workflow instance does not get the event it wants.

So what exactly happened? There are several possible causes:

1. The Workflow instance is not correctly persisted. Workflow is usually persisted when there are no other things to be processed. Especially when it runsOnTaskChangedActivity. Persistence service will try to save the workflow instance to the content database. If a problem occurs during the persistence process, the previous state of the workflow instance is stored in the database. This is completely wrong. If you create a new task in workflow, workflow does not know what it is, because the newest workflow instance is not saved to the database. It seems that workflow has crossed to the stage where no task is created. Now, when you try to submit this task, workflow does not know what to do. Therefore, you get the EventDeliveryFailedException exception of QueueNotFound.

2. In another case, workflow is waiting for Task A, but you have submitted task B. The correlation parameter may be messy. Do you still remember that in workflow, you have created a TaskId for each task? Yes, this is the unique identifier of each session. Each CreateTask and OnTaskChanged pair must be a separate TaskId, which is different from other tasks. The most common situation we see is that people use shared variables for each pair of CreateTask/OnTaskChanged. If all your tasks are executed sequentially, there will be no problems. However, if your tasks run in parallel, your design will certainly be faulty. Sharing the TaskId parameter between tasks leads to competition. A TaskId is assigned to task A and task B at the same time (because it is parallel ). The probability of a problem may be relatively low, but if you randomly get EventDeliveryFailedException, you 'd better check whether you have used a shared TaskId.

3. Before August 2011 CU for Before the CU of SharePoint 2010 in February August 2011, some problems occurred in the process of processing events in SharePoint, which may cause workflow to be persisted to an incorrect state. In the CU in February, the process of event processing is more robust, but you may feel some delay in the process of event processing. Therefore, if you have no other options, make sure that you have installed the CU for July.

EventDeliveryFailedExceptionwith NullReferenceException

Note that the call stack shows that the "SPWorkflowHostServiceBase. LoadInstanceData" method failed. This is part of the SharePoint persistence service. Before SharePoint workflow runtime transfers an event to a workflow instance, it needs to load the workflow instance to the memory. This exception shows that the workflow instance is not correctly persisted because some objects seem to be null. In CU in February August 2011, we added more diagnostic logs to ULS to find problems related to persistent services. The following is an example. Therefore, if you are not sure whether your workflow is persistent, search for the following Log in ULS.

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

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

One of the possible causes of this exception is that workflow has been executed for too long. SharePoint has a hard requirement. If workflow has been running for 20 minutes and has not reached the next persistence point, its status will be reset by the timer job of fail-over. As we mentioned before, the timer job will check whether there is a problem (dead) in the workflow ). In this case, he will reset the window sill to unlock it. Fail-over timer job detects dead workflow by checking how long the workflow has been running. Because the vast majority of workflows should be completed in minutes or even seconds. Therefore, if it is displayed in the database that the workflow has been running for more than 20 minutes, it may be useless (stuck ).