Dienstag, November 07, 2006

PRE008-4 Session 4: Advanced Customization Topics, Persistence and Designer Hosting


Christian Weyer , Ingo Rammer

Abstract: Das selbe wie in der vorhergegangenen Session !


Dies ist die letzte Session für heute.. Puh, bin froh. Ich hab das Gefühl, mein Fieber ist wieder gestiegen und ich bin ziemlich schlapp. Ich werde auf dem nach-Hause weg eine Apotheke suchen, mich ins Hotel begeben, diese Blog Artikel bearbeiten und dann nur noch schlafen… Aber nun zurück zur Session:
Ingo zeigt nun den State Machine Workflow, den er dem Titel nach bei der letzten Session hätte zeigen sollen… egal. Nun sind wir bei unserem Incident Management ;-)
Seine State Machine hat folgende States:

○ Initial State
○ Accepted
○ Declined
○ Manager Approval
○ Completed


Natürlich nichts neues für mich, jedoch bin ich gespannt, ob ich diverse Fragen beantwortet bekomme oder ob sie auf uns bekannte Probleme bezug nehmen. Nun werden die einzelnen Activitys, welche während dem ganzen Tag entstanden sind, kombiniert. D.h, unsere State Machine ist nun voll mit Sequentiellen WF's , resp. Activitys. (z.B. callExternalMethodActivity) Nun zeigt er, wie man von aussen den WF jederzeit fragen kann, in welchem State er ist. Ausserdem zeigt er, dass man den WF fragen kann, auf welche Events er wartet und dass man sie von aussen beantworten oder "feuern" kann. Somit kann ich jederzeit einen WF weitertreiben. Hier ist eine Frage: Kann ich einen WF, der Completed ist, wieder reaktivieren. Die Antwort von Ingo ist, Nein. Es mache keinen Sinn… Zudem werde im Persistance Layer jeder WF "normalerweise" beim completen gelöscht.
Nun werden die FaultHandlersActivitys gezeigt. (Dies sind eigentlich Try Catch Blocks). Global Event Handler.
Nun zeigt er die Cancellation View. Darin kann man Cancellation Activity definieren. Es kann ja durchaus sein, dass ich in jedem Step den Workflow Canceln kann. Damit kann ich dann die Activitys verwenden, um zu Entscheiden, was nun geschehen soll. Dies sind wiederum nur Try Catch Blöcke.
Nun zeigen sie ein Beispiel mit dem FilePersistence Service. Damit kann ich WF's in Files speichern und wieder laden. Im Beispiel zeigen sie, wie der Worflow wenn er Idle ist, einem WebService übergeben wird und auf einem Server gespeichert wird. Was hier nicht funkioniert ist dies: Wenn der WF gespeichert wird, so wird er ja aus dem Memory gelöscht. Nun wird geschaut, ob es noch irgendwelche Timers gibt auf dem WF.Wenn ja, dann werden System.Threading.Timers erzeugt. Dies funktioniert dann auch, ausser man bootet das System. Nach dem Booten kann ich jederzeit meinen WF wieder zum Leben erwecken, aber meine Timers sind weg.
Nun kommt er zum Thema des Designer hosting. Den Designer selber zu hosten ist dafür gedacht, wenn ich in meiner Applikation den Designer verwenden will oder durch eine eigene Applikation meine WF's umkonfigurieren will. Natürlich kann ich dies alles im Visual Studio, aber ich möchte ja ev. dass jemand aus meiner Applikation, welche selber WF's benötigt, der Benutzer den WF auch ändern kann (Grafisch, resp. wir sprechen nur vom Designer) .

Die Pre-Conference ist nun beendet. Ich habe mich nach der ersten Session dazu entschieden, weder den Architekten Track noch den SharePoint Track zu besuchen. Der SharePoint Track war "aufgwärmtes" (ok, der WF auch, aber wesentlich interessanter präsentiert und mit viel mehr Tipps und Tricks gespickt. Deshalb blieb ich auf diesem Track...

Keine Kommentare: