Workflow - Debuggen, sonstige Punkte

Question

Hallo,

<sap:VirtualizedContainerService.HintSize>262,680</sap:VirtualizedContainerService.HintSize>
  <mva:VisualBasic.Settings>Assembly references and imported namespaces for internal implementation</mva:VisualBasic.Settings>
  <Sequence DisplayName="Wareneingangsprüfung" sad:XamlDebuggerXmlReader.FileName="c:\Kalimba\Kapitel 8\Wareneingang\WorkflowWareneingang.xaml" sap:VirtualizedContainerService.HintSize="222,640">
    <sap:WorkflowViewStateService.ViewState>
      <scg3:Dictionary x:TypeArguments="x:String, x:Object">
        <x:Boolean x:Key="IsExpanded">True</x:Boolean>
      </scg3:Dictionary>

Das Debuggen geht nicht. Meine Recherche har ergeben. Der Pfad wird hart kodiert gespeichert. Warum?

 Nehme ich meinen Pfad klappt es.
Warum ist dieser fix hinterlegt? Wie bekomme ich diesen weg.

Das Beispiel stammt ja aus dem Buch.

BUCH

Den richtigen Vorteil der Workflow sehe ich noch nicht, da es ja schon ziemlich verschachelt ist.
Wo kann man sagen, dass das der richtige Weg ist, sich eine Einarbeitung lohnt.

Gibt es evtl. auch gute Online Tutorials für die Workflow? Wie fängt man hat. Das Online Buch ist leider nicht 1:1 der gedruckten Ausgabe.

Grüße Andreas

Answer 1

Hallo Andreas,

Der Pfad wird automatisch vom Visual Studio Workflow-Designer aktualisiert, wenn Du den Workflow speicherst (Strg+S). Das ist nicht der Fall, wenn Du den Designer re-hostest.

Warum der physikalische Pfad unter DebuggerXmlReader.FileName steht? - Damit der Debugger die von dir gesetzten Haltepunkte zur Debugzeit erkennen und visuell präsentieren kann ( Du kannst die angefügte Eigenschaft auch entfernen, aber dann funktioniert das Debuggen nicht mehr).

Dein Link verweist übrigens auf das falsche Buch. Gemeint ist wohl das Buch von Matthias Geirhos: Professionell Entwickeln Mit Visual C# 2010. Das Praxisbuch, Galileo Press (isbn:9783836214742, amazon:3836214741, google:Ob2DRAAACAAJ).

Wenn Du das Buch hast, lies weiter. Dort wird - wie ich finde - ziemlich gut erklärt, wozu Workflows verwendet werden, und wann man besser traditionelle Codierung nimmt.

Siehe auch:

WF 4.0 - Lernprogramm "Erste Schritte":
http://msdn.microsoft.com/de-de/library/dd489454.aspx

.NET Framework Developer Center - WF
http://msdn.microsoft.com/en-us/netframework/aa663328

Gruß
Marcel

Answer 2

Dein Link verweist übrigens auf das falsche Buch. Gemeint ist wohl das Buch von Matthias Geirhos: Professionell Entwickeln Mit Visual C# 2010. Das Praxisbuch, Galileo Press (isbn:9783836214742, amazon:3836214741, google:Ob2DRAAACAAJ).

Wenn Du das Buch hast, lies weiter. Dort wird - wie ich finde - ziemlich gut erklärt, wozu Workflows verwendet werden, und wann man besser traditionelle Codierung nimmt.

Hallo Marcel,

ja hast Recht. Da habe ich mich vertan.

Das Buch habe ich nicht, nur den Code bekommen. Ich finde es etwas unübersichtlich, komplex.

Deshalb einfach die Frage, siehst Du Vorteile in der Workflow?

Das kann ja schon ganz schön komplex werden. Wo ist dann der Vorteil?

Grüße Andreas

Answer 3

Hallo Andreas,

Also ich finde das Tutorial aus Geirhos' Buch recht übersichtlich.

Zum Workflow selbst: Viele Unternehmen greifen heutzutage zur Standarsoftware. Es liegt aber in der Natur der Geschäftswelt, dass sich das Umfeld ständig ändert und man als Unternehmen zuweilen sehr schnell auf diese Änderungen reagieren muss. Je schneller man die in Software abgebildeten Geschäftsprozesse ändern kann, desto größer wird der Wettbewerbsvorteil bzw. desto geringer sind die Verluste des Unternehmens. Wir wissen alle, dass Codeänderungen ihre Zeit brauchen und die Codebasis mit der Zeit dazu tendiert wie verknotetet Spaghetti auszusehen wenn man nur pragmatisch hier ändert und dort flickt. Workflows haben in diesem Zusammenhang einen echten Vorteil. Sie lassen sich recht schnell umkonfigurieren, und oft braucht man gar keine neue Programmierung. 

WF-Arbeit gleicht dem Zusammenstecken von Puzzlestücken. Sind die einzelnen Aktivitäten programmiert (und davon gibt's eine ganze Menge auf Codeplexe usw.) hat man einen Baukasten, den man immer weider verwenden kann. Ich kann hier gar nicht alle Vorteile von WF aufzählen, aber eins vielleicht noch: Workflows können "schlafen gehen", sie können lange Zeit auf eine Antwort warten ohne Ressourcen zu konsumieren, und wenn die Antwort da ist, können sie von der Runtime "geweckt" werden. Workflows werden persistiert, ohne eigenes dazutun. Der gespeicherte Zustand kann Tage, Wochen oder Monate später wieder aufgerufen werden um den Workflow fortzusetzen. Im Enterprise-Kontext bringt das große Vorteile mit sich, die bares Geld wert sind.

Gruß
Marcel