Artikelformat

Abbildung eines Workflows als endlicher Automat

Viele Abläufe einer Webapplikation lassen sich durch einen Workflow darstellen. Ein Bestellprozess bspw. oder das Anlegen einer Seite in einem CMS. Heute betrachten wir, wie man soetwas auf einer etwas abstrakteren Ebene formuliert.

Wer mit den Zeta Components arbeitet, wird die dortige Workflow Komponente kennen. Diese baut grundsätzlich auf einer vereinfachten Darstellung eines Petrinetz auf. Meine Beschreibung wird etwas anders sein. Angenommen man nutzt einen endlichen Automaten. Dieser hat definierte Zustände und Übergänge. Genau so lässt sich auch ein Workflow bauen. Dazu ist der aktuelle Zustand der Anwendung eben der Zustand im Automaten und der Übergang zu einem anderen Zustand wird von einem Benutzer angestoßen.

Weiter hat man einen Startzustand und einen Endzustand. Das sind genau die Zustände, durch die man in die Verarbeitung Eintritt, bzw einen Prozess abschließt. Bspw will der Benutzer etwas bestellen, so wird der Startzustand betreten und ist die Bestellung an das System übermittelt und alle Informationen wie Zahlungsinformationen und Versand- und Rechnungsadresse gesammelt tritt der Benutzer über den Endzustand aus dem Workflow aus.

Ein wichtiger Punkt sind die Notifications. Dabei handelt es sich um Aktionen, die bei Übergang von einem Zustand zu einem anderen ausgeführt werden. Beispielsweise „Email an den Kunden, wenn Bestellprozess abgeschlossen wurde“.

Zuletzt fehlen nur noch Bedingungen. So kann man bedingte Übergänge definieren, die nur dann vom Benutzer aktiviert werden können, wenn eine bestimmte Bedingung erfüllt ist. Zum Beispiel könnte man die Option „Als Geschenk versenden“ nur anbieten, wenn eine Lieferadresse explizit angegeben wurde. Diese bedingten Übergänge könte man auf 2 Arten definieren. Einerseits Bedingungen, die das System vorgibt und die vom Benutzer nicht beeinflußt werden können und andererseits Bedingungen, die der Benutzer manipulieren kann, damit dieser Übergang „freigeschaltet“ wird.

Die Idee lässt sich sicher noch ausbauen und um Möglichkeiten erweitern die bei reiflicher Überlegung erst gefunden werden. Die Alternative zu den recht beliebten Petrinetzen sollte aber schon einmal klar sein 😉

In eigener Sache:
2010 neigt sich dem Ende zu und ich habe den Rest des Jahres Urlaub. Daher ist dies der letzte technische Beitrag; 2011 geht es wie gewohnt weiter. Also wünsche ich meinen Lesern ein frohes Fest und einen guten Rutsch ins Jahr 2011.

4 Kommentare

  1. Gerade beim komplexeren Interaktionsmöglichkeiten eines Users, verwenden wir bei uns häufiger Automaten zur Visualisierung während der Entwicklungsphase. Kann ich jedem nur empfehlen. Andererseits sind das aber auch solche Basics, daß die kaum nen BlogArtikel wert sind… Wobei man das Thema natürlich auch noch ausschlachten kann mit allerlei theoretischem Kram, dann wirds wieder entwas interesanter 🙂
    Anyway: wünsche auch ein frohes Fest

    Antworten
    • Man kann zu dem Thema durchaus auch eine Bachelor oder Master-Arbeit schreiben. Ziel meiner Beträge ist ja nicht nur die professionellen Entwickler anzusprechen, sondern auch einem Anfänger zu motivieren. Übrigens ist der spannende Punkt die Umsetzung der EAs.

  2. Hallo zusammen, in einer ähnlichen Art haben wir das auch beim phlexible.cms (www.phlexible.net) realisiert.

    Wir haben eine Workflow-Engine für die Geschäftslogik gebaut. Diese kann als Zend_Config oder als eine process.ini definiert werden und an die Komponente übergeben werden. Mann ist somit sehr flexibel. Es werden also Prozesse erstellt die nur eine bestimmte Sache machen und ihr Status weitergeben. Diese Prozesse könne an beliebige Stellen in dem Workflow wiederverwendet werden.

    Hier ein konkreter Prozessdefinition:Als Start steht ein getätigter Einkauf in einen WebShop. Als Bezahlung kann der User sich für eine Kreditkarte oder PayPal entscheiden. Ist die Bezahlung erfolgreich so werden die Einkaufe versendet. Wenn nicht, bleibt der Prozess in den Entscheidungsknoten persistent und wartet auf eine erfolgreiche Bezahlung.

    Hier die Konfiguration für die Workflow-Engine:

    ;################################################
    ;## Workflow Configuration Section
    ;################################################

    ; StartNode where this workflow starts

    workflow.config.startNode = start

    ; Allowed environments for this workflow

    workflow.config.environment.1 = MWF_Core_Workflow_UnitTest_Environment

    ; Allowed input for this workflow

    workflow.config.input.1 = MWF_Core_Workflow_Data_Input

    ; Allowed output for this workflow

    workflow.config.output.1 = MWF_Core_Workflow_Data_Output

    ;################################################
    ;## Workflow Definition Section
    ;################################################

    ; Workflow begins here and continues on node mycondition
    start.type = start
    start.output = mycondition

    ; Simple condition-based branching of tree. Want to pay with CC or Paypal. If confition matches
    ; nothing, a LogicalErrorException is thrown.
    mycondition.type = condition
    mycondition.config.condition.1.class = Mycondition_Workflow_UseCreditcard
    mycondition.config.condition.1.config.someconfig = foo
    mycondition.config.condition.1.output = usecc
    mycondition.config.condition.2.class = Mycondition_Workflow_UsePaypal
    mycondition.config.condition.2.config.someconfig = bar
    mycondition.config.condition.2.output = usepaypal

    ; Process payment with CC, payment arrives in realtime
    usecc.type = worknode
    usecc.class = My_Creditcard_Payment_Processing
    usecc.output = shipproduct

    ; Process payment with Paypal. Payment arrives when customer does paypal-checkout. Workflow can only continue,
    ; if customer does the Paypal-Checkout, someday...
    usepaypal.type = worknode
    usepaypal.class = My_Paypal_Payment_Processing
    usepaypal.output = mypersist

    ; Process that does something and signals to be persisted. Persistance is managed by WorkflowEngine,
    ; using repositories and datamappers. A persisted Workflow can be continued at any state.
    ; When Paypal payment arrives, the workflow will be continues on worknode shipproduct, for example.
    mypersist.type = worknode
    mypersist.class = Mypersist_Just_Signal_Persist

    ; Trigger shipping the product to the customer
    shipproduct.type = worknode
    shipproduct.class = My_Shipping
    shipproduct.output = end

    ; Workflow ends here
    end.type = end

    Antworten
  3. Schade, dass es keine weiteren Informationen zu den theoretischen Grundlagen der Workflow-Komponente gibt (der im Wiki angegebene Link führt zu keinem Ziel). Ich denke jedoch, dass es in Sebastian Bergmanns Diplomarbeit [1] ausreichend erläutert wird.

    Das schöne an Petrinetzen ist, dass es mächtige Tools gibt, mit deren Hilfe man gewisse Eigenschaften (z.B. Deadlockfreiheit) verifzieren (!) kann.

    [1] http://sebastian-bergmann.de/publications/bergmann-WorkflowEngine-DiplomaThesis.pdf

    Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.