Architecture Windows Workflow
Windows Workflow Foundation (WF) élève le niveau d’abstraction pour le développement d’applications interactives à durée d’exécution longue. Les unités de travail sont encapsulées comme activités. Les activités s’exécutent dans un environnement qui fournit les fonctions suivantes : contrôle de flux, gestion des exceptions, propagation d’erreur, persistance des données d’état, chargement et déchargement de flux de travail en cours depuis la mémoire, suivi et flux de transaction.
Architecture des activités
Les activités sont développées comme types CLR qui dérivent soit des objets Activity, CodeActivity, AsyncCodeActivity ou NativeActivity, soit de leurs variantes Activity<TResult>, CodeActivity<TResult>, AsyncCodeActivity<TResult> ou NativeActivity<TResult>. En développant des activités qui dérivent de l'objet Activity, l'utilisateur peut assembler des activités préexistantes pour développer rapidement des unités de travail qui s'exécutent dans l'environnement de workflow. L'objet CodeActivity permet quant à lui de créer la logique d'exécution en code managé, en utilisant l'objet CodeActivityContext principalement pour accéder aux arguments d'activité. AsyncCodeActivity est semblable à CodeActivity, mais peut être utilisé pour implémenter des tâches asynchrones. En développant des activités qui dérivent de l'objet NativeActivity, les utilisateurs peuvent accéder au runtime via l'objet NativeActivityContext pour des fonctionnalités telles que la planification d'activités enfants, la création de signets, l'appel de travail asynchrone, l'enregistrement de transactions, etc.
La création d'activités qui dérivent de l'objet Activity est déclarative et ces activités peuvent être créées en XAML. Dans l'exemple suivant, une activité appelée Prompt
est créée à l'aide d'autres activités pour le corps d'exécution.
<Activity x:Class='Prompt'
xmlns:x='http://schemas.microsoft.com/winfx/2006/xaml'
xmlns:z='http://schemas.microsoft.com/netfx/2008/xaml/schema'
xmlns:my='clr-namespace:XAMLActivityDefinition;assembly=XAMLActivityDefinition'
xmlns:s="clr-namespace:System;assembly=mscorlib"
xmlns="http://schemas.microsoft.com/2009/workflow">
<z:SchemaType.Members>
<z:SchemaType.SchemaProperty Name='Text' Type='InArgument(s:String)' />
<z:SchemaType.SchemaProperty Name='Response' Type='OutArgument(s:String)' />
</z:SchemaType.Members>
<Sequence>
<my:WriteLine Text='[Text]' />
<my:ReadLine BookmarkName='r1' Result='[Response]' />
</Sequence>
</Activity>
Contexte de l'activité
ActivityContext est l'interface de l'auteur d'activité avec l'exécution du workflow. Elle permet d'accéder aux nombreuses fonctionnalités du runtime. L'exemple suivant consiste à définir une activité qui utilise le contexte d'exécution pour créer un signet (mécanisme qui permet à une activité d'enregistrer un point de continuation dans son exécution qui peut être reprise par un hôte passant des données dans l'activité).
public sealed class ReadLine : NativeActivity<string>
{
[RequiredArgument]
public InArgument<string> BookmarkName { get; set; }
protected override void Execute(NativeActivityContext context)
{
// Create a Bookmark and wait for it to be resumed.
context.CreateBookmark(BookmarkName.Get(context),
new BookmarkCallback(OnResumeBookmark));
}
// NativeActivity derived activities that do asynchronous operations by calling
// one of the CreateBookmark overloads defined on System.Activities.NativeActivityContext
// must override the CanInduceIdle property and return true.
protected override bool CanInduceIdle
{
get { return true; }
}
public void OnResumeBookmark(NativeActivityContext context, Bookmark bookmark, object obj)
{
// When the Bookmark is resumed, assign its value to
// the Result argument.
Result.Set(context, (string)obj);
}
Cycle de vie des activités
À l'origine, l'instance d'une activité est à l'état Executing. À moins que des exceptions ne soient rencontrées, elle conserve cet état jusqu'à ce que l'exécution de toutes les activités enfants, ainsi que tout autre travail en attente (objets Bookmark, par exemple) soient terminés, auquel cas elle passe à l'état Closed. Le parent d'une instance d'activité peut demander qu'un enfant soit annulé. Si l'enfant est en mesure d'être annulé, il se termine et passe à l'état Canceled. Si une exception est levée lors de l'exécution, le runtime passe l'activité à l'état objet Faulted et propage l'exception en haut de la chaîne parente d'activités. Voici les trois états d’achèvement d’une activité :
Fermé : l’activité a terminé son travail et s’est arrêtée.
Annulé : l’activité a abandonné normalement son travail et s’est arrêtée. Le travail n'est pas restauré explicitement lorsque cet état est entré.
Faulted : l’activité a rencontré une erreur et s’est arrêtée sans terminer son travail.
Les activités restent à l'état Executing lorsqu'elles sont rendues persistantes ou sont déchargées.