zeitgesteuerter Workflow zum durchlaufen aller Listenelemente

Myrcella Als Antwort am 24 Okt. 2014 14:47

Also mit Timer-Jobs etc. kenne ich mich nicht aus, aber eine Liste von Elementen durchlaufen kannst du ganz einfach über eine Schleife. Dazu brauchst du einfach eine bedingte Schleife, die so lange läuft, bis eine Variable XYZ einen bestimmten Wert erreicht hat. Dieser Wert sollte mindestens so hoch sein wie die höchste Element-ID in der Liste und muss dementsprechend evtl. bei Bedarf immer mal erhöht werden. Am Ende von jedem Schleifendurchlauf wird die Variable um 1 erhöht. Und in der Schleife führst du eben immer die gewünschten Aktionen für das Element mit ID=Variable:XYZ durch. So mache ich das zumindest immer und bin mit dieser Lösung recht zufrieden.

Andi Fandrich Als Antwort am 24 Okt. 2014 15:14

Hallo Mue,

die von Myrcella angebotene Schleife gibt es leider erst ab SharePoint 2013 und auch da nur beim Server.

Im Grunde hast Du die vorhandenen Möglichkeiten schon richtig genutzt. Workflows in 2010 und ihre Möglichkeiten sind immer noch weitgehend dieselben wie in WSS 3 von 2007.

Die von Dir genannten Probleme wie die nicht nachvollziehbaren Abbrüche sind quasi normal und gehören zu den Workflows dazu. Je nach Umgebung betrifft das 1-5 Prozent der laufenden Workflows. Wenn Dich das stört, müßtest Du entweder eine andere Workflowengine verwenden. Nintex verwendet dieselbe wie SharePoint. K2 hat etwas eigenes, aber ich habe selbst keine Erfahrung damit. Oder Du entwickelst selbst etwas wie z.B. einen SharePoint Timerjob. Das braucht aber Visual Studio und entsprechendes Know-How.

Mue Als Antwort am 24 Okt. 2014 15:56

Hallo Myrcella, hallo Andi,

Mit derart schnellen Antworten hatte ich jetzt gar nicht gerechnet. Super Reaktionszeit. Die Antworten sind dafür leider recht ernüchternd und fast so, wie ich befürchtet hatte. Die Nutzung mit Schleife über alle Elemente hätte ich natürlich gern genutzt, ist aber im SPD 2010 und in den mir bekannten Erweiterungen (z.B. aus dieser Liste http://sharepointcommunity.de/blogs/mgreth/archive/2011/05/25/sharepoint-designer-2010-custom-workflow-actions.aspx) nicht enthalten. Genau so etwas habe ich ja gesucht. Den regelmäßig wiederholten Aufruf würde ich mit Bordmitteln schon hinbekommen.

Auf dem Sharepoint-Server steht mir leider keine Entwicklungsumgebung (Visual Studio) zur direkten Nutzung der Sharepoint-Klassen zur Verfügung und die Einbindung der notwendigen Klassen "zu Fuß" auf einem Fremdsystem übersteigt dann wohl doch meine Möglichkeiten. Ich hätte jetzt nicht gedacht, dass diese Anforderung so selten ist. Trotzdem schon mal vielen Dank.

Mue

Myrcella Als Antwort am 27 Okt. 2014 07:12

Hallo Andi,

da war ich wohl etwas übereifrig. Ich hab bisher nur mit 2013 gearbeitet, deswegen hab ich von 2010 nicht so viel Ahnung, sorry...

Dass es im SPD 2010 keine Schleifen gibt, ist mir bisher gar nicht aufgefallen. Meiner Meinung nach kannst du meinen Ansatz trotzdem umsetzen, nur statt einer Schleife nutzt du dazu verschiedene Stufen.

Beste Grüße,

Myrcella

Andi Fandrich Als Antwort am 27 Okt. 2014 08:08

Hallo Myrcella,

Schleifen bekommt man mit einem 2010er Workflow nicht hin - jedenfalls nicht mit Bordmitteln. Aber natürlich trotzdem danke für die Antwort. Viele Antworten und damit viele Ideen sind immer besser :-)

Myrcella Als Antwort am 28 Okt. 2014 08:52

Okay, du hast recht, das geht tatsächlich nicht. Ganz schön frustrierend.

Mue Als Antwort am 30 Okt. 2014 09:54

Ich habe noch einmal intensiver gesucht und einige (angebliche) ältere Lösungsansätze gefunden: http://sharepointgypsy.blogspot.de/2011/11/create-for-each-loop-for-workflows.html, http://sharepointgypsy.blogspot.de/2011/01/sharepoint-designer-workflows-2.html, http://sharepointsolutions.blogspot.com/2008/05/looping-through-items-in-sharepoint.html

Nachdem ich diese getestet habe, musste ich allerdings feststellen, dass sie unter Sharepoint 2010 mit den aktuellen Patches und SP's nicht oder nicht mehr laufen. Grund dafür ist, dass sich Listen-Workflows inzwischen nicht mehr selber aufrufen dürfen, z.B. bei Änderung eines Elements in der Liste, durch die der WF gestartet wird. Solche WF laufen bei mir nur noch 1 mal und brechen dann ab. Außerdem ist der Vorschlag unter dem ersten Link völlig unsicher, da hier mit fest zugeordneten ID (ID =1) beim suchen oder ändern gearbeitet wird und dieses Element spätestens nach einem eventuellen Löschen nie mehr vorhanden sein wird. Daher werde ich jetzt (mangels Direktzugriff auf das Objektmodell auf den Sharepointserver) eine Konsolenanwendung  unter Nutzung der Sharepoint Webservices programmieren, die dann über den Windows Aufgabenplaner regelmäßig alle 7 Tage aufgerufen wird und dann einfach beim ersten Durchlauf den Wert einer ja/nein Spalte auf ja setzt. Dadurch wird dann für das Element der WF bei Änderung gestartet. Dort kann ich den normalen SP Designer Mitteln meine Mails zusammenbauen und versenden. Anschließend wird dann durch die Konsolenanwendung die Spalte zurückgesetzt. Dies ist zwar eigentlich nicht nötig und bedingt dann im obigen SP-WF ein zusätzliche Abfrage, ist aber für die optische Kontrolle ganz sinnvoll. Man bräuchte auch nur eine Zählerspalte hochzählen lassen. Dies hat den zusätzlichen Charme, dass beim aufrufen des Webservices schon alle notwendigen Filter gesetzt werden können, damit die Liste wesentliche kürzer wird und nur noch die wirklich betroffenen Elemente "angesteuert" werden. Somit kann man sich aufwendige  Bedingungsabfragen im Workflow sparen.

Vorschläge zur grundsätzlichen Realisierung dieser Konsolenanwendung findet man hier: http://weblogs.mysharepoint.de/blogs/mgreth/archive/2009/08/25/msdn-code-sharepoint-schnipsel.aspx

Viele Grüße

Mue

Mue Als Antwort am 30 Okt. 2014 12:18

Noch ein zusätzlicher Hinweis zu meiner oben stehenden Lösung mit den Hochzählen einer Zählerspalte. Das funktioniert nur dann sinnvoll, wenn es keinen anderen Workflow gibt, der auf Änderungen im aktuellen Element reagiert. Man hat damit keine Spalte, die man als Filter zum abbrechen des WF nutzen kann. Mit der Lösung über die ja/nein Spalte funktioniert diese allerdings. Hier kann man in jedem anderen WF auf "Abgearbeitet=nein?" prüfen und nur in diesem Fall den WF fortsetzen.