SharePoint Workflow architecture (2) Event Processing and sharepointworkflow

SharePoint Workflow architecture (2) Event Processing and sharepointworkflow

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 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 three addresses:

Host Service: SPWinOeHostService

Combination of SharePoint and Workflow Runtime

Event Processing Pipeline)

High Level Event Processing

Most workflows are event-driven workflows. When workflow reaches a specific Activities that need to be input from outside, the workflow runtime will call the SharePoint persistence service to save the data of the workflow instance to the content database. The following data flow chart briefly describes how SharePoint workflow responds to external events.

1. eventcycler responds to user operations

As we mentioned earlier, there are several workflow event receivers that can respond to user operations.SPWinOEItemEventReceiverResponds to tasks and list item events, suchItemUpdatedAndItemDeleted. These events include the following information:

-The task or list item associated with this event.

-BeforeProperties and AfterProperties of the modified Task or List item.

-Event type, which can beItemAdded, ItemUpdated,ItemDeletedOrSharePoint event handler handles any type of events.

Event aggreger sends Event data to SPWorkflowManager.

2. En-queuing event

SPWorkflowManager will try to deliver the event to the corresponding workflow instance (each task has a "WorkflowInstanceID" attribute, which is also how SharePoint knows which workflow instance to send the event ).

Before passing an event, SPWorkflowManager adds the event to the queue of the content database in the form of WorkItem (ScheduleWorkItem table ). this is because, in fact, the event transfer process may be long and may fail. Therefore, it is easy to add to the queue to be fault tolerant. If an error occurs when this event is passed, we can obtain the event again and try again. We will introduce how to read the database to find the cause of failure in passing workflow events.

3. Delivering event

SPWorkflowManager sends an event to the SharePoint workflow runtime (SPWinOeHostService) to continue transmitting the event. The host service loads the workflow instance to the runtime and submits the event to the workflow instance. At this timeOnTaskChangedActivityMethodInvokedMethod.

4. Dequeuing event

If the workflow instance successfully processes the eventScheduleWorkItemsDelete the event in the table and mark the event pipeline as ended.

Event Pipeline

To better understand how these components work together, let's take a look at typical scenarios of SharePoint processing task-related activities. This process starts with running workflow.CreateTaskActivity. Finished in workflowCompleteTaskActivity.

1.CreateTaskActivity inheritsCallExternalMethodActivity.This activity is where the workflow instance and SharePoint start the data exchange session. TaskId is also initialized at this time.

2. Workflowruntime callSPWinOeTaskService. CreateTaskCreate a real task item. Remember that SPListeitem is only created in the memory and not submitted to the database. The actual commit is implemented by the WorkBatch service before the workflow persistence.

3. The next activity of Workflow isOnTaskChangedActivity. Workflow runtime will call the subscriber Service. It will create an event handler for processing the ItemUpdated time on the task we just created.

4. Workflowruntime will create an event sink to respondOnTaskChangedEvent.

5. Now there is nothing else to do for the workflow instance, because it is waiting for the user to submit the task. The persistence service is called to save the workflow instance to the content database. Remember, SPListitem in memory is also submitted at this time.

6. the user submits modifications to the Task through the task form. The Task form is actually an apsx page. by calling the Object Module to update the task item. Task form, the call isSPWorkflowTask. AlterTask ()API to submit modifications to the task. This will trigger the ItemUpdated event of the previously registered event aggreger.

NOTE:You may arrive at the first day, and each workflow task has a special field called "WorkflowVersion ". the value of this column is SPWorkflowTask. alterTask () is set to a value greater than 1, indicating that the task is locked. This indicates that the task has an update and the corresponding workflow instance is required for some actions. This also means that the task is locked before being processed by the workflow instance.

Problem: If I callAlterTask ()API. I receive an exception "task is loack". Why?

Answer: AlterTaskThe API calls SPListItem. update (). if he detects that this task belongs to a running workflow instance, it sets the value of the "WorkflowVersion" column to a value greater than 1. Now if you try to callSPListItem. Update (), It will detect the "WorkflowVersion" column. If its value is greater than 1, we will stop the update and throw this exception. In this way, before workflow completes the OnTaskChange event, it blocks any modifications to the item. OnlyOnTaskChangedAfter the activity is processed by the workflow instance, "WorkflowVersion" is set to 1, indicating that the task is unlocked.

7. Now let's continue. Event aggreger will respond to SPListItem. Update () and callSPWorkflowManager. RunWorkflowTry to transmit the event to workflow runtime.

8. SPWorkflowManager generatesWorkItemPut it in the database (enqueuing, ScheduledWorkItems table). WorkItem records the ItemUpdate events of tasks in the pending state before the workflow instance processes them. We saved this event in the content database for fault tolerance. If this event is not successfully passed for any reason, the timer job of workflow can find this WorkItem from the database and continue to process it.

9. SPWorkflowManager continues to transmit this event to SharePoint workflow runtime (SPWinOeHostService). SPWinOeHostService checks this event and obtains two data from this event:WorkflowInstanceIDAndTaskID. It loads the workflow instance to the workflow runtime.OnTaskChangedEvent to the workflow instance, yourOnTaskChanged. OnInvoked ()The custom code in is called during this period.

Q: Where is TaskId stored?

Answer: each workflow task has a column named "GUID", which is TaskID.

10. workflowruntime is finishedOnTaskChangedAfter the activityWorkItemDelete from the database. The "WorkflowVersion" column of the Task is set to "1" (unlocked), and the event handler er is deleted from the tasklist.

About Workflow Timer Jobs

We once said that when SPWorkflowManager tries to send events to the Host Service (SPWinOEHostService), it needs to check several conditions. One condition is that the workflow is not locked and is not running elsewhere. A SharePoint environment can have multiple front-end servers ). Workflow runtime can host on any server. We need to ensure that the workflow instance is processed by only one workflow runtime at any time. SharePoint sets a flag in the database to identify the lock status. SPWorkflowManager can easily find out if workflow is locked. If the workflow is locked, SPWorkflowManager puts the WorkItem in the database queue, and the timer job processes the event asynchronously.

Workflow timerjob is responsible for processing WorkItems in the queue. In this case, timer service is the host of workflow runtime. Here there are three timer jobs related to workflow, which process different jobs. The following table lists their main functions:

Job	Description
SPWorkflowFailOverJobDefinition	A workflow may fail for multiple reasons. If he fails in the middle, he will be locked and cannot be restarted. Fail-over timer jobs are used to unlock these workflows so that they can continue to run.
SPWorkflowJobDefinition	WorkItems. w3wp.exe in the ScheduleWorkItem queue always tries to transmit the event to workflow in the first time. However, if workflow is locked by another process, it will put the event in the database queue. By default, this timer job will process these events.
SPWorkflowAutoCleanJobDefinition	Understand the old workflow instances in the database. By default, this job will know the workflows completed 60 days ago. You can set the default value by modifying the SPWorkflowAssociation. AutoCleanupDays attribute.

Every five minutes, SPWorkflowJobDefinition is awakened and you can find WorkItems in the database. The WorkItem record in the database contains all pending state jobs. For example, workflow instance ID, task item ID, and event type. For each WorkItems, the timer job reassembles the SPWorkflowEvents object through the WorkItem record. He calls SPWorkflowManager. RunWorkflow ()And pass the event to the Workflow instance.

To be continued.