none
Sequenzieller Ablauf von Workflows

    Frage

  • Hallo Kollegen,

    bis heute habe ich geglaubt, das in einem Workflow die Schritte von oben nach unten nacheinander abgearbeitet werden.

    Kann mir jemand erklären wie es sein kann das ein Workflow bis zum letzten Schritt durchläuft und dann auf Beendigung von Schritt X (Screenshot dritte Zeile) irgendwo mitten im Ablauf wartet?

    Im Screenshot wird auf eine custom codeactivity gewartet, die selbst intern auf das Freiwerden einer Semaphore warte diese dann blockt und dann zurückkehrt. Das Pendent dazu ist die letzte Zeile die die Semaphore wieder freigibt.

    Ich weiß das das nicht sicher ist für Multiserver Installationen. Mir geht es hier nur um die Frage, ob einer von Euch einen Einstiegspunkt in die CRM 2011 Doku nennen kann aus der sich dieses Verhalten schlüssig erklären lässt.

    Grüße

    Thomas

    Sonntag, 14. Juli 2013 09:33

Antworten

  • Hallo Thomas,

    ich behaupte genau wie du, das Workflows von oben nach unten abgearbeitet werden.

    Das Verhalten in deinem Workflow ist aber korrekt, da die Schritte nach der Wartebedingung in der Baumstruktur nicht unterhalb der Wartebedingung sind, sondern wieder im Root beginnen. Würdest du alle Schritte nach der Wartebindung unterhalb der Wartebindung einhängen, werden diese erst ausgeführt, wenn die Wartebedingung erfüllt ist.

    Ich hoffe, du wirst aus dieser Erklärung schlau :-), eventuell wird es mit der Grafik deutlicher.


    Viele Grüße

    Michael Sulz
    MVP für Microsoft Dynamics CRM
    Blog
    Website XING LinkedIn Facebook Twitter


    Montag, 15. Juli 2013 08:24
    Moderator
  • Hallo Thomas,

    ok, jetzt habe ich es verstanden (hoffentlich) :-)

    Dann bin ich bei dir, der Workflow sollte warten bis der Schritt abgearbeitet ist.


    Viele Grüße

    Michael Sulz
    MVP für Microsoft Dynamics CRM
    Blog
    Website XING LinkedIn Facebook Twitter

    Dienstag, 16. Juli 2013 10:34
    Moderator

Alle Antworten

  • Hallo Thomas,

    ich behaupte genau wie du, das Workflows von oben nach unten abgearbeitet werden.

    Das Verhalten in deinem Workflow ist aber korrekt, da die Schritte nach der Wartebedingung in der Baumstruktur nicht unterhalb der Wartebedingung sind, sondern wieder im Root beginnen. Würdest du alle Schritte nach der Wartebindung unterhalb der Wartebindung einhängen, werden diese erst ausgeführt, wenn die Wartebedingung erfüllt ist.

    Ich hoffe, du wirst aus dieser Erklärung schlau :-), eventuell wird es mit der Grafik deutlicher.


    Viele Grüße

    Michael Sulz
    MVP für Microsoft Dynamics CRM
    Blog
    Website XING LinkedIn Facebook Twitter


    Montag, 15. Juli 2013 08:24
    Moderator
  • Hallo Michael,

    ich habe mich wahrscheinlich missverständlich ausgedrückt. Die ersten 2 Zeilen klären nur ob ein bestimmtes Feld leer ist und falls ja endet der WF in der zweiten Zeile.

    Richtig ist, dass der Schritt ....:Worklowblocker im Root liegt. Der Schritt macht intern in einer Schleife so etwas wie Thread.Sleep(1000), um auf etwas zu warten. Das heißt die "Execute" Methode läuft unter Umständen mehrere Sekunden bis zu einigen Minuten. Es ist also keine Workflow Wartebedingung. Ich hätte erwartet das die "Execute" Methode enden muss und verstehe nicht wie der Workflow die weiteren Zeilen abarbeiten kann ohne das dieser Schritt beendet ist.

    Übrigens wenn ich dem Schritt einen Output Parameter hinzufüge und diesen im folgenden Schritt verwende scheint das Verhalten wie erwartet zu sein. Erst wird der Schritt beendet und dann geht es weiter.

    So ich hoffe nun ist das Problem etwas klarer.

    Grüße Thomas

    Montag, 15. Juli 2013 08:40
  • Hallo Thomas,

    ok, jetzt habe ich es verstanden (hoffentlich) :-)

    Dann bin ich bei dir, der Workflow sollte warten bis der Schritt abgearbeitet ist.


    Viele Grüße

    Michael Sulz
    MVP für Microsoft Dynamics CRM
    Blog
    Website XING LinkedIn Facebook Twitter

    Dienstag, 16. Juli 2013 10:34
    Moderator
  • Nein, der Workflow verhält sich 100% korrekt, da die Logik nicht korrekt angewendet wurde.

    Wie Du Thomas es bereits geschrieben hast, wenn Du einen Output Parameter hinzufügst, arbeitet der Workflow die Logik korrekt ab.

    Da dieser Parameter fehlt und Ihr - wie Du schreibst ein künstliches Sleep anwendet - wartet der Workflow nicht auf diesen Schritt. Der Workflow hat den Schritt also quasi angestoßen und verweilt nunmehr in Eurer künstlichen Warteschleife. Da diese aber keinen Rückgabewert hat, ist die Logik für den Workflow-Schritt abgearbeitet und der Workflow kann mit den weiteren Schritten fortsetzen.

    Will man den Workflow künstlich anhalten, so ist es in der Tat sinnvoll mit einem Rückgabeparameter in der Custom Assembly zu arbeiten und diesen auf Existenz oder Wert hin abzufragen, bevor man in der Workflow-Logik den nächsten Schritt anstößt.

    Gruß


    Carsten Groth http://carstengroth.wordpress.com Microsoft Dynamics Certified Technology Specialist, MVP für Microsoft Dynamics CRM

    Samstag, 27. Juli 2013 15:32
  • Hallo Zusammen,

    ergänzend kann ich noch hinzufügen, das das Vorhandensein eine Output Parameters nicht genügt. der Parameter muss zwingend im folgenden Schritt geprüft/verwendet werden damit der Workflow auf die Beendigung wartet.

    Leider beleibt die eigentliche Frage unbeantwortet. Wo in der SDK Doku oder in der Doku der WorkFlow Fundation steht das?

    mfg

    Thomas

    PS: Ich habe das ganze nun in eine Solution zusammengestellt. Wer also in einer massiv parallelen Situation z.B. beim Import von Datensätzen sicherstellen muss das Workflows nicht in verschiedenen Threads zugleich einen nicht vorhandenen Datensatz erzeugen und dadurch Doubletten erzeugen, der kann sich gern melden. Das ganze ist nun auch in Multi Server Umgebungen sicher.
    Sonntag, 28. Juli 2013 17:57