SharePoint 2013 Workflow mit ApplicationException HTTP 401

Kein gänzlich neues Thema: Ein SharePoint-Workflow bleibt hängen. Beim Testen ging er noch und nun, wo er produktiv gehen soll, läuft er nicht länger durch. Nur warum?

Dem Log oder auch den Workflow-Informationen entnimmt man ein vielsagendes „Angehalten“  bzw. „Suspended“. Bei genauerem Hinsehen (MouseOver des kleinen, blauen Info-Icon) findet man in etwa die folgende Fehlerbeschreibung und ist nur ein ganz klein wenig schlauer:

RequestorId: 472ce13d-a3c0-e24a-0000-000000000000.
Details: An unhandled exception occurred during the execution of the workflow instance. 
Exception details: System.ApplicationException: HTTP 401
{"Transfer-Encoding":["chunked"],
 "X-SharePointHealthScore":["0"],
 "SPRequestGuid":["472ce13d-a3c0-e24a-af05-003a17628b61"],
 "request-id":["472ce13d-a3c0-e24a-af05-003a17628b61"],
 "MicrosoftSharePointTeamServices":["15.0.0.4561"],
 "X-Content-Type-Options":["nosniff"],
 "Date":["Wed, 19 Aug 2015 23:42:01 GMT"],
 "Server":["Microsoft-IIS\/8.5"],
 "WWW-Authenticate":["NTLM"],
 "X-AspNet-Version":["4.0.30319"],
 "X-Powered-By":["ASP.NET"]}
  at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context) 
  at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) 
  at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

Der Grund, warum ich ausgerechnet diesem Fehler einen Beitrag widme, ist der, dass im Netz zwar zahlreiche Fragen zur Fehlermeldung existieren aber unangenehmerweise fast ebenso viele Antworten, die nicht zwangsläufig zum Ziel führen. Man solle die Benutzerprofilsynchronisierung manuell in der Zentraladministration starten, man möge dem Workflow-ausführenden Benutzer Schreibrechte auf die korrespondierende Liste geben, man müsse statt SharePoint-Benutzer besser AD-Benutzer direkt berechtigen, ein Workflow-Identitätswechselschritt oder der neue App-Step soll Wunder wirken, und zahlreiche Ideen mehr. Leider in meinem konkreten Fall alles Käse, viel zu kompliziert gedacht und komplett vorbei an der Lösung…

Das Problem

Was man schon mal mit Gewissheit sagen kann, ist der Fakt, dass hier ein Berechtigungsproblem vorliegt. Die spannende Frage ist: Wo? Denn genau das, verrät die Meldung leider nicht.

Bevor ich das Rätsel lüfte, möchte ich ein paar signifikante Eigenheiten des Workflows sowie Konfiguration/Umgebungsbedingungen der SharePoint-Site beschreiben, da diese mit der Schlüssel zur Lösung sind:

  • Der „normale“ Benutzer auf der SharePoint-Site ist lediglich Mitglied der Besuchergruppe, hat folglich auf die meisten Elemente der Seite nur lesenden Zugriff
  • Der Workflow sollte ein Listenelement schreiben, was der den Workflow ausführende Benutzer von Hand auch kann/darf, da für die Liste die Berechtigungsvererbung aufgehoben wurde und die Mitglieder der Besuchergruppe hier schreiben dürfen
  • Der Workflow läuft ohne Probleme für Benutzer, die über die Mitgliedergruppe der Seite berechtigt sind, nicht jedoch für Benutzer der Besuchergruppe; dennoch sind die Rechte für Besucher und Mitglieder auf der in Rede stehenden Liste identisch
  • Der Workflow schlägt für Benutzer der Gästegruppe bereits relativ weit am Anfang fehl, noch bevor tatsächlich eine Create-Action für die Liste ausgeführt wird sondern lediglich beim Protokollieren im Workflowverlauf

Die Lösung

Der letzte Punkt in der Aufzählung ist der Entscheidende und das Schlüsselwort ist „Workflowverlauf“. Die Workflowverlaufsinformationen werden in der Standardkonfiguration eines Workflows ebenfalls in eine Liste auf der Seite geschrieben, die von Hause aus versteckt ist und dementsprechend nicht unter „Alle Websiteinhalte“ erscheint.
Mit Hilfe des SharePoint Designer 2013 oder auch des direkten Aufrufs (http://<server>/<site>/Lists/Workflow%20History/) erhält man Zugriff auf die Liste und sollte hier sicherstellen, dass den Benutzern, die den Workflow ausführen und damit in ihrem Namen in die Workflowverlaufsliste schreiben sollen, hier über die entsprechenden Rechte verfügen. Alternativ ist es natürlich auch möglich, eine neue Workflowverlaufsliste für den Workflow zu definieren – die Hauptsache ist, dass der Benutzer darin schreiben darf.

Noch ein Tipp zur Fehleranalyse sowie auch für den Fall, dass der beschriebene Lösungsansatz nicht zum Erfolg führt: Wenn man das Log bzw. die Workflow-Informationen direkt zur Laufzeit des Workflows beobachtet, erhält man möglicherweise andere Fehlermeldungen, die sich hinter dem blauen Info-Icon verbergen deutlich aufschlussreicher sind. So zum Beispiel brachte mich die folgende Meldung auf den richtigen Pfad zur Lösung meines Problems:

Retrying last request. Next attempt scheduled in less than one minute. 
Details of last request: HTTP Unauthorized to http://sitename/_vti_bin/client.svc/web/lists/getbyid(guid'guid')/Items 
Correlation Id: guid Instance Id: guid

(In Deutscher Umgebung: „Die letzte Anforderung wird wiederholt. Der nächste Versuch ist in weniger als einer Minute geplant“)

Mit der GUID, die sehr wahrscheinlich in einem der Selektoren des API-Requests enthalten ist, wie zum Beispiel der Listen-ID, lässt sich mit wenig Aufwand die Liste oder das Element, welches das Problem verursacht, schnell ausfindig machen.

Über Thomas Roschinsky
Software Engineer | .NET | SharePoint | Dynamics CRM | BI | C# | C/C++

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: