Workflow wird nicht mehr korrekt ausgeführt

C.Kaiser Als Antwort am 6 Sept. 2010 09:33

WSS 3.0 (unter dem Tag ist der Beitrag gespeichert ist nicht gleich Sharepoint Services 2003. ;-)

Was sagen denn die SharePoint Log-Dateien (Programme/Gemeinsame Dateien/Microsoft Shared/web server extensions/12/LOGS) und / oder Windows Server Logs?

474445 Als Antwort am 6 Sept. 2010 10:05

Stimmt sorry, meinte WSS 3.0 :-)

Also die Log-Datei ist für mich etwas unübersichtlich ... ich finde es schwierig zu erkennen was hier wichtig ist.

Hier ist aber ein Abschnitt, der mir aufgefallen ist:

09/06/2010 09:53:37.78  w3wp.exe (0x14C0)                        0x1768 Windows SharePoint Services    Workflow Infrastructure        9e8i Unexpected Declarative workflows cannot automatically start if the triggering action was performed by System Account. Canceling workflow auto-start. List Id: c271d646-2ea8-4aca-96e0-411ea38f0c0b, Item Id: 465, Workflow Association Id: 81181bcf-25b7-4b67-a912-2c040668117a 
09/06/2010 09:53:38.19  w3wp.exe (0x14C0)                        0x1238 Windows SharePoint Services    Web Controls                   88wy Medium   SPDataSourceView.ExecuteSelect() - selectArguments: IsEmpty=True, MaximumRows=0, RetrieveTotalRowCount=False, SortExpression=, StartRowIndex=0, TotalRowCount=-1 
09/06/2010 09:53:38.36  w3wp.exe (0x14C0)                        0x072C Windows SharePoint Services    General                        0 Unexpected ERROR: request not found in the TrackedRequests. We might be creating and closing webs on different threads. ThreadId = 10, Free call stack =    bei Microsoft.SharePoint.SPRequestManager.Release(SPRequest request)     bei Microsoft.SharePoint.SPSite.Close()     bei Microsoft.SharePoint.SPSite.Dispose()     bei Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver.AutoStartWorkflow(SPItemEventProperties properties, Boolean bCreate, Boolean bChange, AssocType atyp)     bei Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver.AutoStartWorkflow(SPItemEventProperties properties, Boolean bCreate, Boolean bChange)     bei Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver.ItemUpdated(SPItemEventProperties properties)     bei Microsoft.SharePoint.SPEventManager.RunIt... 

Andi Fandrich Als Antwort am 6 Sept. 2010 10:18

[quote user="474445"]Declarative workflows cannot automatically start if the triggering action was performed by System Account[/quote]

Das sagt alles: Das Systemkonto triggered keine Workflows. Benutze einen anderen Account.

Auch der letzte Eintrag könnte interessant sein. Benutzt Ihr irgendwelche selbstprogrammierten Workflowaktionen? Hier scheint etwas schlampig programmiert zu sein.

474445 Als Antwort am 6 Sept. 2010 10:35

Also das Systemkonto soll auch keinen Workflow starten. Der Workflow soll nur ausgelöst werden wenn jemand (nicht das Systemkonto) eine Änderung an einem Listenelement vornimmt oder ein Listenelement erstellt.

Als Workflowaktion nutzen wir eine programmierte Aktion von Codeplex. Eine andere Möglichkeit habe ich nicht gefunden Berechtigungen für ein einzelnen Listenelement in einem Workflow zu ändern. Wäre schlecht, wenn die Probleme daran liegen sollten. Weißt du vielleicht ob man mit SharePoint Foundation oder dem SharePoint Server Berechtigungen durch einen Workflow verändern kann? Demnächst sollte das System nämlich davon unabhängig auf eine neuere Version umgestellt werden.

Danke für deine Mühe!

Andi Fandrich Als Antwort am 6 Sept. 2010 11:06

Mit SharePoint Server 2010 geht das, aber nicht mit Foundation.

Wenn ich mich recht erinnere, dann erfolgt das Ändern der Berechtigungen bei den Codeplex-Activities mit erhöhten Rechten. Deshalb muß das Listenelement neu aus der DB geholt werden (statt aus dem Workflow) und ist damit nicht synchron. Wenn jetzt eine Workflowaktion irgendwas an einem Element ändert und direkt danach kommt eine Aktion, die die Berechtigungen dieses Elements ändert, dann gibt es einen Fehler. Man kann das umgehen, indem man dazwischen eine kurze Pause einbaut.

474445 Als Antwort am 10 Sept. 2010 12:42

Danke für deine Antwort! Mitlerweile funktioniert der Workflow wieder korrekt. Es wurde ein Hotfix installiert und ich habe doch noch einen kleinen Fehler im Workflow gefunden wodurch sich wahrscheinlich Fehler angesammelt hatten.

Nun, wenn man mit dem SharePoint Server Berechtigungen setzen könnte wäre das für mich auf jeden Fall ein Riesenvorteil. Hoffentlich kann ich bald darauf umsteigen.

Im Moment ist es auch so, dass mein Workflow bis zu einer halben Minute dauert. Wenn ein Listenelement zweimal hintereinander recht schnell geändert wird, wird nur der erste Workflow durchgeführt, das zweite nicht weil der Workflow schon läuft. Dadurch kann es aber sein, dass Aktionen übersprungen werden. Am besten wäre es, wenn der erste Workflow beendet werden würde und die neue "Version" des Workflows würde stattdessen von vorne laufen. Ist irgendwas in dieser Art wohl möglich, oder mit dem Server besser zu realisieren?

Andi Fandrich Als Antwort am 10 Sept. 2010 13:04

[quote user="474445"]Im Moment ist es auch so, dass mein Workflow bis zu einer halben Minute dauert. Wenn ein Listenelement zweimal hintereinander recht schnell geändert wird, wird nur der erste Workflow durchgeführt, das zweite nicht weil der Workflow schon läuft. Dadurch kann es aber sein, dass Aktionen übersprungen werden. Am besten wäre es, wenn der erste Workflow beendet werden würde und die neue "Version" des Workflows würde stattdessen von vorne laufen. Ist irgendwas in dieser Art wohl möglich, oder mit dem Server besser zu realisieren?[/quote]

So ganz verstehe ich das Problem nicht. Jeder Workflow kann nur einmal pro Element laufen. Er kann also nicht durch Änderungen nochmal in einer zweiten Instanz gestartet werden.

Workflows funktionieren immer transaktionell, d.h. alle aufeinanderfolgenden Aktionen werden in einer Transaktion abgearbeitet. Wenn eine Aktion scheitert, dann scheitern alle. Das gilt immer bis zu einer Aktion, die den Workflow pausieren läßt, wie z.B. das Zuweisen einer Aufgabe.

Innerhalb einer solchen Transaktion arbeitet der Workflow mit immer derselben Instanz eines Listenelements. Zwischenzeitliche Änderungen bekommt er nicht mit, aber sie sollten in der Praxis auch keine Rolle spielen, weil die Transaktion sehr schnell abgearbeitet wird.

Dieser Mechanismus ist beim SharePoint Server derselbe.

474445 Als Antwort am 13 Sept. 2010 08:56

[quote user="Andi Fandrich"]

Innerhalb einer solchen Transaktion arbeitet der Workflow mit immer derselben Instanz eines Listenelements. Zwischenzeitliche Änderungen bekommt er nicht mit, aber sie sollten in der Praxis auch keine Rolle spielen, weil die Transaktion sehr schnell abgearbeitet wird.

Mein Workflow dauert ungefähr eine halbe Minute. Deshalb kann es z.B. vorkommen, dass ein Listenelement geändert wird und die Bedingungen des Workflows sind erfüllt, so dass Berechtigungen verändert werden. Während dieser Workflow läuft wird das gleiche Listenelement aber nochmals geändert. Eventuell sind jetzt Bedingungen erfüllt, so dass die Berechtigungen wieder anders gesetzt werden müssten. Aber das werden sie natürlich nicht, weil der Workflow nur einmal ausgeführt wird. Nur wenn der Workflow abgeschlossen ist bevor das Element nochmals geändert wird läuft es korrekt.

Ich dachte vielleicht ist es irgnendwie möglich mehrere Instanzen eines Workflows zu haben. Aber anscheinden wohl nicht. Wäre die Frage warum mein Workflow so lange dauert. Möglicherweise liegt das gerade an dieser Aktion von Codeplex, die die Berechtigungen umsetzt. Und wenn diese Aktion beim SharePoint Server direkt dabei ist und nicht auf Fremdprogrammierung zurückgegriffen werden muss geht es damit vielleicht schneller?

Andi Fandrich Als Antwort am 13 Sept. 2010 09:19

Das hatte ich oben schon erklärt: die Codeplex-Aktionen zum Setzen der Berechtigungen sind nicht synchronisiert und können deshalb unter bestimmten Bedingungen Probleme machen.

474445 Als Antwort am 13 Sept. 2010 13:35

Ok, danke!