Verwenden von Workflowmarkup

Artikel
12/17/2007

Mit Windows Workflow Foundation erhalten Designer und Entwickler eine deklarative Möglichkeit zum Erstellen von Workflows unter Verwendung von eXtensible Application Markup Language (XAML) zur Erstellung von Markupquelldateien. Diese Markupdateien können in einen Workflowtyp kompiliert, während der Laufzeit direkt in das Workflow-Laufzeitmodul geladen oder in einen Workflowtyp kompiliert werden, wobei CodeBehind-Dateien entweder in C# oder Visual Basic implementiert werden. Dies bedeutet, dass die Workflowmarkupdateien kompiliert oder nicht kompiliert werden können, abhängig von geschäftlichen Gründen und davon, ob zusätzliche Implementierungslogik erforderlich ist. Die Verwendung von Workflowmarkup mit CodeBehind-Logikdateien ähnelt der Trennung von Präsentationsdateien von logischen Dateien durch ASP.NET.

Ein Beispiel zum direkten Laden einer Workflowmarkupdatei in das Workflow-Laufzeitmodul finden Sie im Abschnitt zu laufenden Workflows im Thema Erstellen einer Workflowhostanwendung.

Neben dem Erstellen eines Workflows in Workflowmarkup können Sie Workflowmarkup auch beim Beibehalten des Workflows mit einem WorkflowPersistenceService-Dienst verwenden, da programmgesteuerte Workflows beim Serialisieren mit WorkflowMarkupSerializer zu Workflowmarkup werden. Weitere Informationen finden Sie unter Gewusst wie: Serialisieren von Workflows und Windows Workflow-Persistenzdienste.

Grundlegende Struktur

Die grundlegende Struktur des Workflowmarkups beinhaltet den Stammknoten, der den Workflowtyp anzeigt, sowie die untergeordneten Aktivitäten in diesem Workflow als geschachtelte Unterelemente. Da Workflowmarkup auf einer Teilmenge von XAML-Elementen und -Attributen basiert, ist die Struktur von Workflowmarkupdateien mit der Struktur einer XAML-Datei vergleichbar. Beispielsweise wird jedes Element im Workflow als Knoten von zusammengesetzten Aktivitäten oder dem Workflow selbst dargestellt. Die Beziehung zwischen Knoten wird beibehalten, so wie es auch der Fall ist, wenn Workflows mithilfe einer Programmiersprache wie C# oder Visual Basic erstellt werden.

Elemente und Attribute

Wie zuvor erwähnt, entspricht jedes Element in einer Workflowmarkupdatei einer Workflowkomponente. Die Namen für diese Elemente stimmen mit den Namen für die Aktivitätstypen überein, die beim programmgesteuerten Erstellen von Workflows verwendet werden. Zum Beispiel wird die IfElseActivity-Aktivität durch das <IfElseActivity>-Element dargestellt. Dies gilt auch für benutzerdefinierte Aktivitäten.

Aktivitätsmember werden entsprechend der Darstellung im folgenden Beispiel deklariert:

<SampleActivity Property1="PropValue" Method="CustomMethod" Event="EventHandlerMethod"/>

XAML bietet zudem die Möglichkeit, mithilfe des x:Code-Direktivenelements prozeduralen Code innerhalb einer Workflowmarkupdatei einzufügen. Der Code muss in einem CDATA-Abschnitt abgelegt werden, damit der Compiler den Code kompilieren kann, anstatt ihn wie deklaratives XAML-Markup zu behandeln. Im folgenden Beispiel wird gezeigt, wie dieses Element mit einem CDATA-Abschnitt verwendet wird.

<CodeActivity x:Name="codeActivity1" ExecuteCode="methodName1">
  <x:Code><![CDATA[
      void methodName1(object sender, EventArgs e) 
      {
      }
  ]]></x:Code>
</CodeActivity>

Hinweis

Das x:Code-Direktivenelement kann nur in kompilierten Workflowmarkupdateien verwendet werden.

In der folgenden Tabelle werden die allgemeinen Attribute des Workflowmarkups beschrieben.

Attribut	Beschreibung
x:Array	Ein Array von Typen.
x:Class	Name der Workflowklasse einschließlich des Namespace. Die Klasse mit diesem Namen wird beim Kompilieren des Workflows erstellt.
x:Name	Der Name einer Aktivität. Entspricht der Activity.Name-Eigenschaft.
x:Type	Ein Typverweis.
x:Null	Ein NULL-Wert.
xmlns:x	Der Namespace für das XAML-Schema.
xmlns	Der Namespace für das Workflow-XAML-Schema.

Hinweis

Wird zum Erstellen eines Workflows eine nicht kompilierte, reine XAML-Workflowmarkupdatei verwendet, darf das x:Class-Attribut nicht in der XAML-Datei enthalten sein. Dieses Attribut ist nur gültig, wenn der Workflow kompiliert wird.

Hinweis

Wird der Stammnamespace für eine VB-Anwendung nach dem Erstellen einer Workflowmarkupdatei geändert, muss das x:Class-Attribut dieses Workflows ebenfalls aktualisiert werden.

Beispiel

Nachfolgend finden Sie das Beispiel einer Workflowmarkupdatei, die mit einer CodeBehind-Datei verwendet wird, die die Implementierungslogik für die verschiedenen Ereignishandler im Workflow beinhaltet.

<SequentialWorkflowActivity x:Class="XAMLWorkflow.Workflow1" x:Name="Workflow1" xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml" xmlns="https://schemas.microsoft.com/winfx/2006/xaml/workflow">
    <IfElseActivity x:Name="ifElseActivity1">
        <IfElseBranchActivity x:Name="ifElseBranchActivity1">
            <IfElseBranchActivity.Condition>
                <CodeCondition Condition="EvalCondition" />
            </IfElseBranchActivity.Condition>
            <CodeActivity x:Name="codeActivity1" ExecuteCode="codeActivity1_ExecuteCode" />
            <FaultHandlersActivity x:Name="faultHandlersActivity1">
                <FaultHandlerActivity x:Name="faultHandlerActivity1" Fault="{ActivityBind Workflow1,Path=faultHandlerProp}" FaultType="{x:Type System.NullReferenceException}">
                    <CodeActivity x:Name="codeActivity3" ExecuteCode="codeActivity3_ExecuteCode" />
                </FaultHandlerActivity>
            </FaultHandlersActivity>
        </IfElseBranchActivity>
        <IfElseBranchActivity x:Name="ifElseBranchActivity2">
            <CodeActivity x:Name="codeActivity2" ExecuteCode="codeActivity2_ExecuteCode" />
        </IfElseBranchActivity>
    </IfElseActivity>
</SequentialWorkflowActivity>

Der Condition-Ereignishandler und der ExecuteCode-Ereignishandler müssen implementiert werden, bevor dieses Beispiel gemäß dem folgenden Beispiel kompiliert wird:

Private Sub EvalCondition(ByVal sender As Object, ByVal e As ConditionalEventArgs)End Sub
Private Sub codeActivity1_ExecuteCode(ByVal sender As Object, ByVal e As EventArgs)
End Sub
Private Sub codeActivity2_ExecuteCode(ByVal sender As Object, ByVal e As EventArgs)
End Sub

private void EvalCondition(object sender, ConditionalEventArgs e) { }
private void codeActivity1_ExecuteCode(object sender, EventArgs e) { }
private void codeActivity2_ExecuteCode(object sender, EventArgs e) { }

Hinweis

Wird zum Erstellen eines Workflows eine nicht kompilierte, reine XAML-Workflowmarkupdatei verwendet, müssen alle Abhängigkeitseigenschaften des Typereignishandlers mit der ActivityBind-Markuperweiterung festgelegt werden, da sie andernfalls während der Laufzeit nicht kompiliert werden. Siehe folgendes Beispiel:

<CodeActivity x:Name="codeActivity1" ExecuteCode="{ActivityBind Name=Activity12, Path=codeActivity1_ExecuteCode}" />

Siehe auch

Footer image

Freigeben über

Verwenden von Workflowmarkup

Grundlegende Struktur

Elemente und Attribute

Beispiel

Siehe auch

Referenz

Konzepte

Weitere Ressourcen

Zusätzliche Ressourcen