Freigeben über

SharePoint-Workflowzeitgeberauftrag bleibt bei "Anhalten" hängen

  • Gilt für:: SharePoint Server 2016, SharePoint Server 2013, SharePoint Server 2010

Symptome

In der SharePoint-Zentraladministration zeigt ein Workflowtimerauftrag den Status "Anhalten" an. Daher treten die folgenden Probleme auf:

  • Genehmigungen von Vorgängen werden nicht abgeschlossen.
  • Workflows können nach einer Pause nicht ausgeführt werden.
  • Zufällige Verarbeitung von Workflows erfolgt.
  • Workflows funktionieren nicht über längere Zeiträume.

Ursache

Die wahrscheinlichste Ursache ist eine schlechte Workflowinstanz.

Lösung

Um das Problem zu beheben, ermitteln Sie zuerst, ob es durch eine Workflowdefinition verursacht wird, die im System oder durch eine ungültige Workflowinstanz eingeführt wurde. Nachdem Sie überprüft haben, können Sie mit dem Workflowbesitzer entscheiden, ob der Workflow beendet oder gelöscht werden kann.

Um das Problem schnell zu diagnostizieren, erwägen Sie, den Microsoft SharePoint Foundation-Workflowzeitgeberdienst auf allen Servern außer einem server zu beenden.

Schritt 2: Festlegen der ULS-Protokollierungsebene auf "VerboseEx"

Führen Sie in der SharePoint-Verwaltungsshell den folgenden Befehl aus:

Set-SPLogLevel -TraceSeverity VerboseEx

Hinweis: Dies kann zu Leistungsproblemen in der Farm führen. Es wird empfohlen, die Dauer auf das Minimum zu beschränken und die ULS-Protokollierungsebene auf den Standardwert zurückzusetzen, nachdem das Verhalten mithilfe von Clear-SPLogLevel reproduziert wurde.

Wenn die Leistungsauswirkung die vollständige VerboseEx-Ablaufverfolgung verhindert, legen Sie die Protokollierungsebene für alle Kategorien auf "Ausführlich" und die Protokollierungsebene für "Legacy-Workflowinfrastruktur" (oder "Workflowinfrastruktur" in SharePoint 2010) und "Timer"-Kategorien auf "VerboseEx" fest. Führen Sie dazu die folgenden Befehle in der SharePoint-Verwaltungsshell aus:

Set-SPLogLevel -TraceSeverity Verbose   
Set-SPLogLevel -TraceSeverity VerboseEx -Identity "Legacy Workflow Infrastructure"  
Set-SPLogLevel -TraceSeverity VerboseEx -Identity "Timer"

Schritt 3: Löschen des Konfigurationscaches

Löschen Sie den Konfigurationscache auf allen Servern, auf denen der Workflowzeitgeberauftrag hängen bleibt, und auf den Servern, auf denen der Microsoft SharePoint Foundation-Workflowtimerdienst gestartet wird.

Schritt 4: Warten Sie, bis das Problem erneut auftritt, und sammeln Sie ULS-Protokolle.

Nachdem der Konfigurationscache gelöscht wurde, ändert sich der Status des Workflowzeitgeberauftrags von "Anhalten" in "Angehalten" und dann "Ausführen". Warten Sie, bis das Problem auftritt – es dauert in der Regel zehn Minuten. Möglicherweise sehen Sie auch, dass der Workflowzeitgeberauftrag auf einem anderen Server gestartet wird, wenn der Auftrag auf diesem Server ausgeführt werden kann.

Überprüfen Sie alle fünf Minuten die ULS-Protokolle, um festzustellen, ob das Problem reproduziert wurde, und der Zeitgeberauftrag bleibt hängen. Das Problem wird in den ULS-Protokollen angezeigt, bevor der Zeitgeberauftragsstatus "Anhalten" wird. Wenn keine neuen Einträge für den "Zeitgeberauftragsauftragsworkflow" in ULS-Protokollen erstellt werden, bleibt der Zeitgeberauftrag hängen. Filtern Sie in diesem Fall die ULS-Protokolle mithilfe der folgenden Bedingung, und überprüfen Sie die Uhrzeit des letzten Eintrags:

 Name  Contains  Timer Job job-workflow

Schritt 5: Untersuchen von ULS-Protokollen

  1. Öffnen Sie ULS-Protokolle in ULS Viewer, und wenden Sie dann die folgenden Filter an:

    Name  Contains  job-workflow  
EventID  Contains  ahk8y

  2. Suchen Sie den letzten Workflow, der verarbeitet wurde. Dies ist wahrscheinlich die Workflowinstanz, die das Problem verursacht hat. Hier ist ein Beispiel:

    SharePoint Foundation Legacy Workflow Infrastructure ahk8y Verbose In RunWorkflowElev(), begin processing events for instance: bb7e3f4f-74ac-43f7-a31e-faa7e900843e      8329f59d-0342-20c3-fa1a-56f9161ded9f

  3. Löschen Sie alle Filter, und wenden Sie dann den folgenden Filter an:

    Korrelation entspricht <Correlation_ID> Und
    Nachricht enthält proc_GetWorkflowAssociations und
    [EventID enthält b6p4 Oder
    EventID contains tzkv ]

    Im Beispiel ist die Korrelations-ID 8329f59d-0342-20c3-fa1a-56f9161ded9f.

  4. Suchen Sie die letzten Vorkommen von Ereignissen b6p4 und tzkv, und suchen Sie dann die ListId, SiteId, ItemId und WebId. Hier ist ein Beispiel:

    05/25/2017 12:28:43.27 OWSTIMER.EXE (0x9318) 0x6DF0 SharePoint Foundation Database b6p4 VerboseEx SqlCommand: ; EXEC proc_getworkflowassociations '8dd5c889-47a6-4798-93ef-8652609278f4', 'j3952987-5ca6-4eae-8530-13e83acf1bb0', 'e22969ea-f883-4e99-8cbd-4b799a884d2d', 'm82r99b0-ff01-4448-9907-e2cbbbca0586', @contenttypeid, @RequestGuid OUTPUT 8329f59d-0342-20c3-fa1a-56f9161ded9f   
05/25/2017 12:28:43.27 OWSTIMER.EXE (0x9318) 0x6DF0 SharePoint Foundation Database tzkv Verbose SqlCommand: 'proc_GetWorkflowAssociations' CommandType: StoredProcedure CommandTimeout: 0 Parameter: '@RETURN_VALUE' Type: Int Size: 0 Direction: ReturnValue Value: Parameter: '@SiteId' Type: UniqueIdentifier Size: 0 Direction: Input Value: '8dd5c889-47a6-4798-93ef-8652609278f4' Parameter: '@WebId' Type: UniqueIdentifier Size: 0 Direction: Input Value: 'j3952987-5ca6-4eae-8530-13e83acf1bb0' Parameter: '@Id' Type: UniqueIdentifier Size: 0 Direction: Input Value: 'e22969ea-f883-4e99-8cbd-4b799a884d2d' Parameter: '@ListId' Type: UniqueIdentifier Size: 0 Direction: Input Value: 'm82r99b0-ff01-4448-9907-e2cbbbca0586' Parameter: '@ContentTypeId' Type: VarBinary Size: 512 Direction: Input Value: Parameter: '@RequestGuid' Type: UniqueIdentifier Size: 0 Direction: Input Value: '8329f59d-0342-20c3-fa1a-56f9161ded9f' 8329f59d-0342-20c3-fa1a-56f9161ded9f

    Im Beispiel ist die ListId m82r99b0-ff01-4448-9907-e2cbbbca0586, die SiteId ist 8dd5c889-47a6-4798-93ef-8652609278f4, die ItemId ist e22969ea-f883-4e99-8cbd-4b799a884d2d2d, und die WebId ist j3952987-5ca6-4eae-8530-13e83acf1bb0.

Schritt 6: Identifizieren des Workflows

Führen Sie in der SharePoint-Verwaltungsshell die folgenden Befehle aus, um die Web-URL und den Listentitel zu finden:

 $web= (Get-SPSite -Identity <SiteId> |Get-SPWeb -Identity <WebId>)   
 $list = $web.Lists.GetList("<ListId>", $true)  
 $list.ParentWeb   
 $list.Title

Beachten Sie, dass SiteId, WebId und ListId Platzhalter für die SiteId, WebId und ListId sind, die in Schritt 5 gefunden wurden.

Wechseln Sie zur Liste, und suchen Sie das Element mithilfe von ItemId. Sie können auch eine temporäre Ansicht in der Liste erstellen und nach ITEMID filtern. Der problematische Workflow ist dem Element zugeordnet. Wechseln Sie zur Workfloweinstellung des Elements. Wenn auf dem Element mehrere Workflows ausgeführt werden, klicken Sie auf die Statusspalte des problematischen Workflows, um die Workflowverlaufsseite anzuzeigen.

Schritt 7: Beenden des Workflows

Überprüfen Sie den Workflowverlauf, um zu ermitteln, was falsch ist. Anschließend können Sie den Workflow beenden oder das Element löschen.

Manchmal können Sie den Workflow oder das Element in Schritt 6 nicht identifizieren. Stellen Sie in solchen Fällen sicher, dass Sie die richtige Liste anzeigen und alle anderen Datenteile überprüfen. Überprüfen Sie auch Papierkörbchen.

Wenn Sie das Element oder den Workflow immer noch nicht finden können, ist es möglich, dass das Element gelöscht wurde, aber die Workflowinstanz noch ausgeführt wird. Führen Sie in diesem Fall die folgenden Befehle in der SharePoint-Verwaltungsshell aus, um den Workflow abzubrechen:

$web = Get-SPWeb <WebURL>  

#Pass the workflow Instance Id from the ahk8y event  
$WorkflowInstanceID = <WorkflowInstanceID>  
$workflowId =  [GUID]$WorkflowInstanceID  
$workflow = New-Object Microsoft.SharePoint.Workflow.SPWorkflow($web, $workflowId);  
[Microsoft.SharePoint.Workflow.SPWorkflowManager]::CancelWorkflow($workflow)

Weitere Informationen

Benötigen Sie weitere Hilfe? Navigieren Sie zu SharePoint-Community.