Traitement par lots des informations d'état dans des workflows

Article
04/22/2008

Votre workflow enregistre périodiquement son état sur le stockage persistant à différents points de vérification appelés points de persistance. Si une anomalie se produit dans votre workflow, le moteur d'exécution peut devoir récupérer ces informations persistantes afin de retourner à un état stable. Si deux composants ou davantage communiquent, il est souvent utile de coordonner la persistance afin que les états des composants soient cohérents. Les lots de travail sont utilisés par les services externes au workflow pour rendre les informations d'état persistantes. Ce lot de services regroupe les éléments de travail par lots et partage la même transaction que celle du workflow. Si le workflow ne valide pas de transaction, certains éléments de travail peuvent malgré tout être regroupés par les services pendant les points de persistance.

Windows Workflow Foundation fournit un IWorkBatch et un IPendingWork afin d'aider les services et les instances de workflow à rendre persistantes les informations d'état.

Pour tous les appels aux services initialisés à partir du workflow, le moteur d'exécution fournit un IWorkBatch dans son contexte d'appel de thread. Votre service peut ajouter un élément de travail en attente à ce lot de travail afin que le moteur d'exécution puisse valider tous les éléments de travail connexes au sein d'une transaction unique. Pour les ajouts d'éléments de travail au lot ou pour les inscriptions avec le lot, utilisez l'instruction suivante :

WorkflowEnvironment.WorkBatch.Add(IPendingWork work, object workItem);

De plus, vous pouvez passer un IPendingWork au constructeur pour ExternalDataEventArgs.

Séquence d'actions exécutée lorsqu'un composant est appelé

Pendant l'initialisation, le workflow crée un lot de travail.
Le workflow joint le lot de travail à l'appel d'une méthode sur un composant. Les services peuvent accéder au lot de travail dans chacune de leurs méthodes en utilisant la classe WorkflowEnvironment.

Séquence d'actions exécutée au point de validation

Le workflow crée une transaction.
Le workflow parcourt le lot de travail et recueille tous les éléments de travail d'un composant, en conservant leur ordre, afin de créer un lot de travail. Le workflow appelle la méthode Commit sur le composant, en passant la transaction et le lot de travail.
Le composant ajoute le travail contenu dans le lot de travail à la transaction.
Les étapes 2 et 3 sont répétées pour tous les composants contenant des éléments de travail dans des lots de travail.
Lorsque les notifications Commitaboutissent, le workflow valide la transaction correspondante.
Une fois que la validation d'une transaction a eu lieu, le workflow parcourt le lot de travail et recueille tous les éléments de travail par composant, comme à l'étape 2. Le workflow appelle la méthode Complete pour chaque composant, en passant la transaction et le lot de travail correspondants.

Séquence d'actions exécutée en cas d'erreur de workflow

Le workflow identifie tous les éléments de travail en rapport avec l'erreur et construit un lot de travail.
Le workflow appelle la méthode Complete de chaque IPendingWorkunique portant la valeur d'état false pour tous les travaux contenus dans le lot de travail.
Le workflow abandonne le travail présent dans le lot de travail si celui-ci appartient à un contexte enfant d'une activité TransactionScopeActivity ou d'une activité CompensatingTransactionScopeActivity.
Le runtime conserve la référence à tous les éléments restants du lot de travail après la reprise. Ce travail peut ensuite être validé à un point de persistance ultérieur.

Nouvelle tentative de transactions de travail en traitement par lots

Les DefaultWorkflowCommitWorkBatchService, SharedConnectionWorkflowCommitWorkBatchService, SqlWorkflowPersistenceServiceet SqlTrackingService ont tous la capacité d'effectuer de nouvelles tentatives de validation des lots de travail. Cette fonction, activée via la propriété EnableRetries, permet à ces services de continuer de tenter de valider un lot de travail en cas de délais d'attente réseau, de redémarrage de l'ordinateur, de réinitialisations de processus SQL Server, etc.

Le nombre de nouvelles tentatives est égal à 20. Les trois premières tentatives se produisent immédiatement l'une après l'autre. Ensuite, un délai s'écoule entre chaque tentative suivante. Les applications peuvent ajuster le délai de connexion dans leur chaîne de connexion afin de régler partiellement l'heure entre les différentes tentatives.

Cette propriété peut être définie par programme ou via un fichier de configuration. Pour plus d'informations sur la définition par programme, consultez la propriété EnableRetries pour chacun des services. Pour plus d'informations sur la définition de cette propriété via un fichier de configuration, consultez Workflow Configuration Files.