Présentation de l’hébergement de Windows Workflow Foundation

 

Moustafa Khalil Ahmed
Chef de programme
Microsoft Corporation

Août 2006

S’applique à :
   Windows Workflow Foundation
   Microsoft .NET Framework 2.0
   Microsoft .NET Framework 3.0

Résumé: Fournit une vue d’ensemble de la façon dont une application hébergeant Windows Workflow Foundation (WF) peut gérer et surveiller les flux de travail en cours d’exécution et donne une vue d’ensemble des services d’exécution et de leurs implémentations prêtes à l’emploi. Les lecteurs doivent être familiarisés avec Microsoft .NET Framework, C# et le modèle de programmation WF. (16 pages imprimées)

Contenu

Introduction
Gestion du cycle de vie des instances de flux de travail
Facilité de gestion et surveillance
Fiabilité et haute disponibilité
Base Runtime Services
Conclusion
Pour plus d'informations

Introduction

Cet article est destiné aux développeurs qui utilisent Windows Workflow Foundation (WF) pour les aider à comprendre les différentes options disponibles pour permettre à leurs applications de gérer et de surveiller les instances de workflow en cours d’exécution. L’article suppose que le lecteur a une compréhension de base de Microsoft .NET Framework, C# et WF.

WF se compose d’une bibliothèque d’activités et d’une infrastructure, d’un moteur d’exécution et d’un composant de services d’exécution qui doivent s’exécuter dans un processus d’application hôte. Les flux de travail sont construits sous la forme d’un ensemble d’activités exécutées par le moteur d’exécution. Le moteur d’exécution doit s’exécuter dans un processus d’application hôte. L'illustration suivante décrit comment les workflows, les activités et le moteur d'exécution de workflow sont tous hébergés dans le processus avec une application hôte.

Figure 1. Processus hôte Windows Workflow Foundation

WF fournit un moteur d’exécution, qui est responsable de l’exécution du flux de travail et de la gestion de l’état. Le runtime WF peut être hébergé dans n’importe quel processus .NET, y compris les ASP.NET, les services Windows, les applications console et les applications Windows Forms. Le développeur est responsable de l’écriture de ce processus hôte lors de la création d’une application avec workflow. Les services d’exécution fonctionnent dans le processus hôte pour fournir des fonctionnalités supplémentaires au moteur d’exécution, car il gère l’exécution des flux de travail.

Il existe de nombreux problèmes à prendre en compte lorsque vous implémentez une application hôte pour WF. Cet article fournit une vue d’ensemble de la façon dont l’application hôte peut gérer et superviser les flux de travail, ainsi qu’un résumé des services d’exécution de base et de leurs implémentations prêtes à l’emploi.

Gestion du cycle de vie des instances de flux de travail

WF fournit des activités prêtes à l’emploi et des méthodes d’opérations de contrôle sur la classe WorkflowInstance pour gérer les états et le cycle de vie des flux de travail. La section Gestion du cycle de vie des instances de flux de travail décrit les différents événements d’exécution instance de flux de travail spécifiques, ainsi que les transitions entre ces événements et leur relation avec les états du flux de travail.

Points de persistance

Les flux de travail sont souvent longs et inactifs, en attendant qu’une entrée d’un utilisateur ou d’autres systèmes continue. Étant donné qu’il n’est pas pratique de conserver les flux de travail inactifs en mémoire, il est recommandé de conserver l’état de instance du workflow sur un support de stockage jusqu’à ce que le flux de travail reçoive l’événement qu’il attend. En outre, l’enregistrement de l’état instance du flux de travail permet de reprendre le flux de travail à partir de ce point en cas de défaillance plus tard dans le processus.

La figure 2 décrit comment utiliser des points de persistance pour reprendre l’exécution d’instances de flux de travail.

Figure 2 : Utilisation de points de persistance pour reprendre l’exécution d’instances de flux de travail

Si un workflow instance’état est conservé au point B et qu’une défaillance se produit au point C, votre application peut reprendre le flux de travail instance à partir du point B sans perdre le travail effectué entre les points A et B. Toutefois, si un service de persistance n’est pas disponible ou si l’état du flux de travail instance n’est pas persistant, le travail effectué du point A à B est perdu.

Si un WorkflowPersistenceService est présent (c’est-à-dire ajouté à l’instance WorkflowRuntime), le moteur d’exécution de flux de travail utilise ce service pour conserver l’état instance flux de travail sur un support de stockage. Cela peut se produire aux points suivants :

• À l’achèvement des activités marquées avec persistOnCloseAttribute (par exemple, les activités d’étendue de transaction)
• Avant l’achèvement du flux de travail instance
• Avant l’arrêt du workflow instance
• Quand le flux de travail devient inactif
• Quand WorkflowInstance.Unload ou WorkflowInstance.TryUnload sont appelés

Le moteur d’exécution WF appelle la méthode SaveWorkflowInstanceState() sur workflowPersistenceService pour enregistrer l’état instance du flux de travail. Il appelle la méthode LoadWorkflowInstanceState() pour récupérer le flux de travail instance état persistant si nécessaire. Le runtime de flux de travail gère toute la sémantique concernant le moment où effectuer la persistance, et les services de persistance sont responsables de l’enregistrement et du chargement réels du flux de travail instance. Les états d’activité et l’ID de instance de flux de travail sont sérialisés et enregistrés dans le magasin de persistance. En outre, toutes les autres informations nécessaires pour reprendre le flux de travail instance exécution (par exemple, les files d’attente) sont incluses dans l’état sérialisé et enregistré.

Événements d’instance de flux de travail

Un flux de travail instance peut être dans l’un des cinq états suivants : Créé, En cours d’exécution, Suspendu, Terminé et Terminé. Les flux de travail ont 13 événements qui se produisent tout au long de la durée de vie du flux de travail instance. Ces événements peuvent indiquer une transition vers un autre état. Par exemple, l’événement WorkflowCompleted indique que le instance est passé de En cours d’exécution à Terminé. Certains événements n’indiquent pas que le instance est passé à un autre état. Par exemple, l’événement WorkflowPersisted indique que le instance est persistant, mais toujours à l’état En cours d’exécution. Sur ces 13 événements, 11 sont communiqués à l’application hôte via des événements d’exécution et des événements de workflow de suivi. Deux événements, Changed et Exception, sont communiqués à l’application hôte via les événements de workflow de suivi uniquement.

WF fournit des méthodes d’opérations de contrôle sur la classe WorkflowInstance pour permettre aux applications hôtes de gérer le cycle de vie des flux de travail. En outre, une application peut définir des stratégies pour gérer le cycle de vie du flux de travail. Par exemple, une application peut avoir des stratégies de déchargement pour indiquer au moteur WF de décharger les instance de flux de travail. WF fournit des activités prêtes à l’emploi qui peuvent affecter le flux de travail instance statistiques. Par exemple, les activités SuspendActivity et TerminateActivity peuvent être utilisées pour suspendre et arrêter le workflow instance respectivement. Les sections suivantes décrivent les différents événements spécifiques instance de flux de travail qui sont déclenchés par le runtime de workflow pour communiquer les événements instance de flux de travail et les transitions de statistiques du instance de flux de travail.

WorkflowAborted

Une instance de flux de travail est considérée comme ayant été abandonnée lorsque le moteur d’exécution de workflow jette le instance en mémoire. Les applications hôtes peuvent abandonner le flux de travail instance en appelant WorkflowInstance.Abort(). Les instances de flux de travail abandonnées peuvent être reprises à partir de leur dernier point de persistance en appelant WorkflowInstance.Resume(). L’abandon d’un workflow instance est utilisé dans des situations extrêmes où une application décide d’ignorer tout le travail effectué à partir du dernier point de persistance jusqu’à l’appel de WorkflowInstance.Abort().

WorkflowCompleted

Une instance de flux de travail est terminée lorsque l’instance se termine. À ce moment-là, l’application hôte peut examiner les files d’attente pour les messages et autres événements qui n’ont pas été consommés par le workflow instance.

Flux de travailCréé

Un workflow est créé lorsque le instance est entièrement construit, mais avant que les activités ne commencent à s’exécuter. Le flux de travail instance est créé en appelant l’une des méthodes surchargées WorkflowRuntime.CreateWorkflow().

WorkflowIdled

Le flux de travail instance est inactif lorsqu’il attend qu’un événement externe (minuteur, message ou autres événements personnalisés) poursuive l’exécution. Pour économiser des ressources système, une application peut définir sa stratégie de déchargement pour décharger le flux de travail instance de la mémoire lorsqu’il est inactif. Si l’application hôte utilise sqlWorkflowPersistenceService prête à l’emploi, vous pouvez définir un indicateur UnloadOnIdle dans le fichier de configuration de l’application pour indiquer au moteur d’exécution WF de conserver l’état du flux de travail lorsque le instance est inactif.

WorkflowLoaded

L’événement WorkflowLoaded est déclenché lorsque l’état instance est chargé dans la mémoire à partir d’un magasin de persistance.

WorkflowPersisted

Lorsque le sqlWorkflowPersistenceService out-of-box ou un service de persistance personnalisé a été ajouté à l’instance WorkflowRuntime, le instance de flux de travail est conservé lorsque l’état instance workflow est enregistré dans le magasin de persistance.

Flux de travail Reprise

La instance de flux de travail reprend lorsque WorkflowInstance.Resume() est appelé sur un instance de workflow suspendu ou abandonné.

Flux de travailDémarré

L’événement WorkflowStarted est déclenché lorsque WorkflowInstance.Start() est appelé. L’événement de démarrage du flux de travail est déclenché avant que le moteur d’exécution de flux de travail ne commence à exécuter les activités de flux de travail.

WorkflowSuspended

La suspension de la instance de flux de travail s’effectue via un appel WorkflowInstance.Suspend() ou lorsqu’une activité SuspendActivity s’exécute. Par conséquent, le flux de travail instance est dans un état suspendu.

WorkflowTerminated

La fin de la instance de flux de travail s’effectue via un appel WorkflowInstance.Terminate(), lorsqu’une activité TerminateActivity s’exécute ou lorsqu’une exception non gérée se produit dans le flux de travail en cours d’exécution instance. Une fois cet événement déclenché, le flux de travail instance est dans l’état terminé.

WorkflowUnloaded

L’événement WorkflowUnloaded est déclenché lorsque le flux de travail instance est déchargé de la mémoire vers un magasin de persistance. Cette opération est effectuée en fonction de la stratégie de persistance, ou via un appel à WorkflowInstance.Unload() ou WorkflowInstance.TryUnload().

Transitions des événements d’instance de flux de travail

Les événements de flux de travail instance sont communiqués à l’hôte via des événements d’exécution de workflow et des événements de workflow de suivi. L’application hôte peut s’abonner aux événements d’exécution ou utiliser un service de suivi pour être avertie. Les événements Exception et Modification sont uniquement communiqués à l’application hôte via les services de suivi. Un événement Exception indique qu’une exception s’est produite lors de l’exécution du instance de workflow. Un événement Changed indique que le workflow instance a été mis à jour dynamiquement pendant l’exécution.

La figure 3 illustre les transitions entre différents événements de flux de travail et les états du flux de travail.

Figure 3. Transitions entre les événements et états de workflow (cliquez sur l’image pour l’agrandir)

Si un service de persistance est activé, les points de persistance se produisent comme indiqué dans la figure 3. Ces applications hôtes doivent s’attendre à voir les événements WorkflowPersisted, WorkflowUnloaded et WorkflowLoaded , le cas échéant. Si le instance de flux de travail n’est pas en mémoire et qu’un service de persistance est activé, toutes les opérations valides sur le instance (Reprendre, Abandonner, Arrêter, Arrêter, etc.) entraînent le chargement du flux de travail instance en premier, puis continuent à traiter la demande. Par exemple, si vous avez un flux de travail suspendu mais déchargé instance, l’appel de Resume sur celui-ci entraîne son chargement d’abord, puis continue à déclencher l’événement Resume comme indiqué dans le diagramme.

Opérations d’instance de flux de travail

Comme indiqué précédemment, la classe WorkflowInstance a des méthodes pour contrôler le cycle de vie du flux de travail instance. Cette section décrit ces méthodes.

WorkflowInstance.Start()

Démarre l’exécution du flux de travail créé instance. WorkflowInstance.Start() entraîne le lancement de l’événement WorkflowStarted par le runtime de workflow, et le flux de travail instance est à l’état En cours d’exécution. Une exception InvalidOperationException est levée si Start() est appelé sur un instance de workflow déjà démarré.

WorkflowInstance.Abort()

Abandonne l'instance de workflow. Lorsque l’abandon réussit, le runtime de workflow déclenche l’événement WorkflowAborted .

WorkflowInstance.Load()

Charge un flux de travail déchargé instance d’un magasin de persistance dans la mémoire. L’exécution du instance est alors planifiée à partir de l’état dans lequel elle se trouvait avant son déchargement. Lorsque le chargement réussit, le runtime de workflow déclenche l’événement WorkflowLoaded .

WorkflowInstance.Resume()

Reprend (continue l’exécution de) un workflow suspendu ou abandonné instance. Le runtime de workflow déclenche l’événement WorkflowResumed juste avant la reprise de l’exécution de l’instance de workflow.

WorkflowInstance.Suspend()

Interrompt l’exécution du workflow instance. Lorsque l’appel à WorkflowInstance.Suspend() réussit, le runtime de workflow déclenche l’événement WorkflowSuspended .

WorkflowInstance.Terminate()

Termine la instance de flux de travail et efface la instance de flux de travail en mémoire. Le runtime de workflow informe le service de persistance inscrit que le flux de travail instance a été effacé de la mémoire. Pour sqlWorkflowPersistenceService, cela signifie que toutes les informations d’état de ce instance de flux de travail sont supprimées de la base de données à l’arrêt. Vous ne pouvez pas recharger le flux de travail instance à partir d’un point de persistance précédemment stocké. Lorsque WorkflowInstance.Terminate() réussit, le runtime de workflow déclenche l’événement WorkflowTerminated .

WorkflowInstance.Unload()

Décharge l'instance de workflow de la mémoire dans le magasin de persistances. WorkflowInstance.Unload() est synchrone. Il se bloque jusqu’à ce que le travail actuellement planifié soit terminé, ou que la fin d’une étendue de transaction soit atteinte, afin d’effectuer le déchargement avec succès. Lorsque WorkflowInstance.Unload() réussit, le runtime de workflow déclenche l’événement WorkflowUnloaded . Une exception InvalidOperationException est levée si Unload() est appelé en l’absence de service de persistance inscrit.

WorkflowInstance.TryUnload()

Contrairement à WorkflowInstance.Unload(),WorkflowInstance.TryUnload() ne se bloque pas tant que le flux de travail ne peut pas être déchargé. WorkflowInstance.TryUnload() décharge le flux de travail instance de la mémoire dans le magasin de persistance et retourne true lorsque le instance est suspendu ou inactif. Sinon, l’appel retourne false. Une exception InvalidOperationException est levée si TryUnload() est appelé en l’absence de service de persistance inscrit.

Pour plus d’informations sur les différentes méthodes de contrôle sur WorkflowInstance, consultez le Kit de développement logiciel (SDK) Windows Foundation.

Facilité de gestion et surveillance

Les applications qui hébergent des flux de travail sont responsables de la gestion et de la surveillance des flux de travail qu’elles hébergent et exécutent. WF fournit la prise en charge de divers outils de gestion et de surveillance. Par exemple, WF fournit un suivi de bout en bout que vous pouvez utiliser pour le débogage de bas niveau, ainsi que pour l’infrastructure de suivi pour l’extraction et la surveillance des données de flux de travail.

Cette section décrit la facilité de gestion et l’infrastructure de surveillance en place et comment l’utiliser dans vos applications hôtes.

Suivi

WF fournit une infrastructure de suivi pour capturer les événements et les données de flux de travail, d’activité et d’utilisateur pendant l’exécution des instances de workflow. N’importe quel instance d’exécution de workflow peut avoir plusieurs services de suivi inscrits, ou aucun. Les informations de suivi sont envoyées aux services de suivi inscrits. Les services de suivi sont chargés de stocker et de traiter ces informations en fonction des besoins de l’application hôte. WF fournit un service de suivi sql (SqlTrackingService) prête à l’emploi qu’une application hôte peut utiliser. En outre, les développeurs d’applications hôtes peuvent écrire leurs propres services de suivi personnalisés et les utiliser pour les applications hôtes.

Vous pouvez utiliser le suivi pour examiner l’historique de votre workflow instance exécution et déterminer l’état actuel des instances de workflow en cours d’exécution sur votre système. En outre, le suivi peut fournir des informations que vous pouvez utiliser avec la définition de flux de travail pour prédire les chemins d’exécution attendus à venir des instances de flux de travail qui s’exécutent sur le système. WF fournit un exemple d’application, Workflow Monitor Sample, qui utilise le SqlTrackingService et les contrôles du concepteur de flux de travail pour afficher le flux de travail et l’activité status des informations sur les flux de travail terminés et en cours d’exécution.

Pour plus d’informations sur la surveillance des flux de travail à l’aide du suivi, consultez l’outil Sdk Workflow Monitor dans l’exemple Exemples d’applications/Moniteur de flux de travail. Pour obtenir des exemples qui montrent comment créer un service de suivi personnalisé, consultez l’exemple ConsoleTrackingService et le service de suivi de fichiers et l’exemple de requête dans Exemples technologiques/suivi. Pour obtenir des exemples qui montrent comment utiliser sqlTrackingService prête à l’emploi, consultez exemple de suivi simple et requête à l’aide de SQLTrackingService sample in Technology Samples/Trackingout-of-box.

Suivi et suivi de bout en bout

Vous pouvez utiliser des traces pour surveiller l’intégrité de votre application et isoler et résoudre les problèmes sans perturber un système en cours d’exécution. WF utilise les API System.Diagnostics pour effectuer le suivi des informations sur l’exécution du workflow et du workflow instance l’exécution, y compris les informations d’évaluation de l’ensemble de règles. Par défaut, les traces sont désactivées, mais vous pouvez les activer si vous le souhaitez.

En outre, WF participe au suivi de bout en bout. Les fonctionnalités de suivi de bout en bout permettent aux visionneuses de suivi d’afficher les informations de suivi de continuation sur différents composants et les transitions entre ces composants. Cela facilite le débogage de bout en bout.

Si vous utilisez un fichier de configuration d’application, vous devez ajouter ce qui suit pour activer le suivi de journalisation pour plusieurs espaces de noms WF :

<system.diagnostics>
    <switches>
        <add name="System.Workflow LogToTraceListeners" value="1" />
        <add name="System.Workflow.Runtime" value="All" />
        <add name="System.Workflow.Runtime.Hosting" value="All" />
        <add name="System.Workflow.Runtime.Tracking" value="All" />
        <add name="System.Workflow.Activities" value="All" />
        <add name="System.Workflow.Activities.Rules" value="All" />
    </switches>
</system.diagnostics> 

Lorsque LogToTraceListeners est utilisé, WF énumère chaque TraceListener créé dans votre application hôte et leur envoie toutes les informations de journalisation. Les lignes restantes de l’exemple vous permettent de spécifier les espaces de noms pour lesquels capturer les informations de journalisation, ainsi que la quantité d’informations qui sont tracées. Les valeurs possibles pour l’attribut value sont All, Off, Critical, Error, Warning, Information et Verbose. Pour plus d’informations sur l’utilisation des attributs de valeur, consultez le Kit de développement logiciel (SDK) WF.

Événements du runtime de flux de travail

Les événements d’exécution sont déclenchés par le runtime de workflow et fournissent à l’application hôte les moyens de gérer le cycle de vie du runtime de workflow et des instances de workflow. Les gestionnaires d’événements sont définis sur la classe WorkflowRuntime , et l’application hôte doit s’abonner à ces événements pour les utiliser.

Les événements d’exécution agissent comme un système de notification léger lorsque l’application hôte doit agir sur un événement spécifique au lieu de stocker ces événements et leurs données associées à des fins d’interrogation. Pour ce dernier, il est recommandé d’utiliser l’infrastructure de suivi.

Une instance de WorkflowRuntime peut exécuter plusieurs instances de workflow ; chaque instance de workflow a son propre cycle de vie. Par conséquent, les arguments d’événement pour les événements de flux de travail instance contiennent l’ID de instance de flux de travail et d’autres informations. Ces informations peuvent être utilisées pour mettre en corrélation l’événement avec le flux de travail instance qui provoque le déclencher par le runtime de workflow.

Les sections suivantes décrivent les événements d’exécution de workflow disponibles.

WorkflowRuntime.ServiceExceptionNotHandled

Cet événement est déclenché lorsque le thread appartenant au service lève une exception. Un service dérivé de la classe WorkflowRuntimeService peut appeler la méthode RaiseServicesExceptionNotHandledEvent() pour informer les abonnés à l’événement ServicesExceptionNotHandled qu’une exception s’est produite pendant son exécution et qu’il n’a pas pu gérer cette exception. Les services out-of-box déclenchent cet événement dans de telles conditions. L’application hôte peut s’abonner à cet événement pour implémenter un mécanisme de récupération. L’argument d’événement associé à cet événement est ServicesExceptionNotHandledEventArgs.

WorkflowRuntime.Started

Cet événement est déclenché lorsque la instance spécifiée du WorkflowRuntime démarre. L’argument d’événement associé à cet événement est WorkflowRuntimeEventArgs.

WorkflowRuntime.Stopped

Cet événement est déclenché lorsque le instance spécifié du WorkflowRuntime s’arrête. L’argument d’événement associé à cet événement est WorkflowRuntimeEventArgs.

Tableau 1. WorkflowInstanceEvents

Événement	Description	Argument d’événement
WorkflowAborted	Déclenché lorsque le instance de workflow est abandonné.	WorkflowEventArgs
WorkflowCompleted	Déclenché lorsque le flux de travail instance est terminé.	WorkflowCompletedEventArgs
WorkflowCréated	Déclenché lorsque le flux de travail instance est entièrement construit, mais avant le traitement des activités, c’est-à-dire avant que le flux de travail ne commence à s’exécuter.	WorkflowEventArgs
WorkflowIdled	Déclenché lorsque le flux de travail instance passe à l’état inactif, c’est-à-dire que le instance de flux de travail attend qu’un événement externe (par exemple, un minuteur, un message, etc.) continue l’exécution.	WorkflowEventArgs
WorkflowLoaded	Déclenché lorsque le flux de travail instance est chargé en mémoire, généralement à partir d’un magasin de persistance.	WorkflowEventArgs
WorkflowPersisted	Déclenché lorsque le instance de flux de travail est persistant.	WorkflowEventArgs
Workflow Reprise	Déclenché lorsque le flux de travail instance reprend, généralement à partir d’un état suspendu ou abandonné.	WorkflowEventArgs
WorkflowStarted	Déclenché lorsque le workflow instance commence à s’exécuter.	WorkflowEventArgs
WorkflowSuspended	Déclenché lorsque le workflow instance est suspendu.	WorkflowSuspendedEventArgs
WorkflowTerminated	Déclenché à l’arrêt du instance de workflow.	WorkflowTerminatedEventArgs
WorkflowUnloaded	Déclenché lorsque le flux de travail instance est déchargé de la mémoire vers un magasin de persistance.	WorkflowEventArgs

Consultez la section « Gestion du cycle de vie du flux de travail » plus haut dans cet article pour plus d’informations sur les différents événements et la façon dont le flux de travail entre dans différents états.

Pour plus d’informations sur l’utilisation de différents événements d’exécution de workflow, consultez les exemples du Kit de développement logiciel (SDK) Windows Workflow Foundation.

Compteurs de performances

Vous pouvez surveiller les performances du flux de travail à l’aide de l’outil de performances Windows. Il se compose de deux parties : Moniteur système et Journaux de performances et alertes. Par le biais des journaux de performances et des alertes, vous pouvez configurer des compteurs de performances pour enregistrer les données de performances et définir des alertes système pour vous avertir quand la valeur d’un compteur spécifié est supérieure ou inférieure à un seuil défini.

WF fournit un ensemble de compteurs de performances avec l’objet de performance WF que vous pouvez utiliser pour suivre les performances d’un flux de travail. Pour obtenir la liste complète des compteurs de performances, consultez la section Compteurs de performances du flux de travail dans le Kit de développement logiciel (SDK) WF.

Pour plus d’informations sur l’ajout de compteurs de performances à l’outil Performances, consultez le site Web Microsoft TechNet.

Stratégie de déchargement

Les systèmes peuvent avoir des milliers de workflows s’exécutant simultanément à un moment donné. Il peut devenir impraticable de permettre à tous de rester en mémoire. Pour mieux gérer les ressources d’un système, vous pouvez définir une stratégie de déchargement pour conserver les états de workflow et les décharger de la mémoire.

WF fournit une stratégie de déchargement en cas d’inactivité si vous utilisez le service de persistance prête à l’emploi. La stratégie est active lorsque vous définissez la propriété UnloadOnIdle sur la classe SqlWorkflowPersistenceService pour indiquer au moteur d’exécution de décharger le flux de travail lorsqu’il est inactif. Si l’application hôte active SqlWorkflowPersistenceService via un fichier de configuration, vous pouvez le faire en définissant l’indicateur UnloadOnIdle sur true. Si sqlWorkflowPersistenceService est construit et activé via du code, l’application hôte doit le construire à l’aide du constructeur SqlWorkflowPersistenceService (String, Boolean, TimeSpan, TimeSpan). Votre application hôte peut implémenter d’autres stratégies de déchargement complexes.

En outre, vous pouvez appeler la méthode WorkflowInstance.Unload() pour demander à décharger ce flux de travail spécifique instance de la mémoire et à conserver son état. L’application hôte peut ultérieurement appeler la méthode Load() sur les instances pour continuer à les exécuter à partir du dernier point de persistance. Lorsque des instances de flux de travail sont déchargées, un événement d’exécution, l’événement WorkflowUnloaded , est déclenché.

Fiabilité et haute disponibilité

WF prend en charge les hôtes qui choisissent d’être fiables et hautement disponibles en prenant en charge les éléments suivants :

SQL Clustering

Les services SQL prêtes à l’emploi prennent en charge l’installation clustering. Les services SQL WF out-of-box fournissent des nouvelles tentatives lors de la validation du lot sur SQL Server. Par conséquent, prenez en charge les scénarios de basculement ou les serveurs SQL temporairement inaccessibles. La logique de nouvelle tentative peut être définie sur une combinaison de l’un des services suivants :

• DefaultWorkflowCommitWorkBatchService
• SharedConnectionWorkflowCommitWorkBatchService
• SqlTrackingService
• SqlWorkflowPersistenceService

Par défaut, la logique de nouvelle tentative est DÉSACTIVÉE. L’application hôte doit explicitement activer la logique de nouvelle tentative pour utiliser la fonctionnalité. Les applications peuvent choisir d’activer les nouvelles tentatives par service ou sur tous les services mentionnés précédemment. Pour ce faire, définissez la propriété EnableRetries sur les classes de services ou via le fichier de configuration. Avec un fichier de configuration, l’application hôte peut utiliser un indicateur partagé, EnableRetries, pour définir activer les nouvelles tentatives sur ON ou OFF sur tous les services affectés. Si la propriété EnableRetries est définie sur un service, sa valeur remplace la valeur de l’indicateur partagé EnableRetries . Les services SQL WF out-of-box effectuent de nouvelles tentatives pour un nombre constant de fois. Le nombre de nouvelles tentatives n’est pas configurable. Toutefois, les applications peuvent ajuster le délai d’attente de connexion dans la chaîne de connexion des services pour ajuster partiellement le temps entre les nouvelles tentatives.

Définition des nouvelles tentatives

L’exemple suivant montre comment définir EnableRetries pour tous les services prêts à l’emploi en ajoutant un paramètre commun, EnableRetries, et en définissant sa valeur sur True. Il montre comment désactiver EnableRetries pour SqlWorkflowPersistenceService en ajoutant un indicateur EnableRetries pour ce service et en lui affectant la valeur False.

<WorkflowRuntime Name="SampleApplication" UnloadOnIdle="false">
    <CommonParameters>
        <add name="ConnectionString" value="Initial Catalog=WorkflowStore;Data Source=localhost;Integrated Security=SSPI;" />
        <add name="EnableRetries" value="True" />
    </CommonParameters>
    <Services>
        <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, 
System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" EnableRetries="False"  />
    </Services>
</WorkflowRuntime>

En règle générale, il est recommandé de définir les nouvelles tentatives sur tous les services sur ON ou OFF.

Notez que la classe WorkflowCommitWorkBatchService est chargée de réessayer toutes les validations par lots associées aux activités non TransactionScopeActivity (points de persistance). La classe WorkflowCommitBatchService ne peut pas effectuer de nouvelles tentatives de validations par lots de travail pour les activités TransactionScopeActivity . En effet, dans ce cas, elle n’a pas démarré la transaction et n’en est donc pas propriétaire. Les nouvelles tentatives de validations par lots de travail pour les activités TransactionScopeActivity doivent être modélisées dans le flux de travail. Cette opération se fait généralement sous la forme d’une boucle while et d’un gestionnaire d’exceptions en dehors de TransactionScopeActivity.

Nouvelles tentatives sur le SqlTrackingService out-of-box, s’il est exécuté en mode non transactionnel, et le sqlWorkflowPersistenceService prête à l’emploi contrôle le travail lié à SQL qui n’est pas lié aux validations de lots de travail. Cela inclut la vérification des minuteurs arrivés à expiration et le chargement d’instances de workflow.

Équilibrage de charge et mise à l’échelle Front-End

L’application qui héberge WF est responsable de la gestion des scénarios d’équilibrage de charge et des scénarios de mise à l’échelle front-end. WF fournit une prise en charge dans le moteur et les services SQL prêtes à l’emploi pour permettre à différentes instances d’application hôte de pointer vers les mêmes bases de données SQL de persistance ou de suivi.

Si vous avez plusieurs applications hôtes connectées au même magasin de persistance, l’une d’elles peut charger n’importe quel workflow instance type à partir de la base de données. WF out-of-box SqlWorkflowPersistenceService ne prend pas en charge l’attribution de types de flux de travail ou d’instances à charger sur des hôtes spécifiques lorsqu’ils partagent le même magasin de persistance. Vous devez implémenter un service de persistance personnalisé si ce comportement ne répond pas aux besoins de votre application hôte.

Le moteur d’exécution WF fournit une sémantique de verrouillage pour prendre en charge les scénarios de mise à l’échelle front-end lorsque plusieurs applications hôtes utilisent le même magasin de persistance. La sémantique de verrouillage empêche les applications de charger un flux de travail instance déjà chargé par une autre application. La classe WorkflowPersistenceService vous permet de prendre en charge cette fonctionnalité de moteur d’exécution de flux de travail en fournissant un paramètre à la méthode SaveWorkflowInstanceState() qui spécifie si les informations d’état d’un flux de travail instance doivent être déverrouillées dans le magasin de données, et en fournissant la méthode UnlockWorkflowInstanceState() pour déverrouiller les informations d’état de flux de travail précédemment verrouillées. Dans un service de persistance qui implémente le verrouillage, un appel à la méthode LoadWorkflowInstanceState() doit verrouiller les informations d’état d’un instance de flux de travail.

Consultez les sections Services de persistance de flux de travail Windows et Création de services de persistance personnalisés dans le Guide de programmation WF pour plus d’informations sur la sémantique de verrouillage du flux de travail instance.

Base Runtime Services

Le moteur d’exécution WF exécute des flux de travail à l’aide des services d’exécution. Le modèle de service runtime donne à l’application hôte la flexibilité nécessaire pour fournir différents services au moteur d’exécution WF. Cette section décrit les services d’exécution fournis par WF et les implémentations prêtes à l’emploi de ces services.

Pour plus d’informations sur les implémentations du service runtime, consultez les sections Windows Workflow Foundation Services et Développement des services Windows Workflow Foundation Dans le Guide de programmation WF.

Le runtime WF fournit quatre services. Ces services ont des implémentations prêtes à l’emploi, ou les applications hôtes peuvent implémenter leurs propres services et les fournir au runtime de workflow.

Workflow Transaction Services

L’objectif des services de transaction de flux de travail Windows (WorkflowCommitWorkBatchService) est d’activer une logique personnalisée concernant l’engagement des lots de travail (également appelés points de persistance). Lorsqu’un lot de travail est validé, le runtime appelle le service de transaction actuel et passe un délégué à l’appel pour effectuer la validation réelle du lot de travail. Le runtime doit encore effectuer la validation, mais permettre à un service de l'insérer dans le processus active la personnalisation autour du processus de validation.

L’infrastructure WF ne prend pas en charge la possibilité d’apporter votre propre transaction de l’extérieur dans un workflow instance. Les seuls types de transactions ambiantes prises en charge par WorkflowCommitWorkBatchService sont les transactions qui proviennent du instance de flux de travail. Les transactions ambiantes qui proviennent de l’application hôte exécutant le runtime de workflow sont temporairement supprimées du thread actuel pour réduire leurs effets secondaires. Une fois le workflow inactif, la transaction ambiante d’origine de l’application hôte contenue par est de nouveau placée dans le thread.

WF fournit deux implémentations prêtes à l’emploi pour les services de transaction : DefaultWorkflowCommitWorkBatchService et SharedConnectionWorkflowCommitWorkBatchService.

Le moteur d’exécution WF nécessite un service de transaction de flux de travail. Par défaut, il utilise defaultWorkflowCommitWorkBatchService. L’application hôte peut choisir de remplacer defaultWorkflowSchedulerService par SharedConnectionDefaultWorkflowCommitWorkBatchService ou par un service personnalisé.

DefaultWorkflowCommitWorkBatchService

Lorsque le moteur d’exécution de flux de travail démarre, un instance de DefaultWorkflowCommitWorkBatchService est créé et ajouté à WorkflowRuntime si aucun autre service de transaction n’est ajouté. Ce service crée des transactions .NET Framework pour chaque connexion de base de données. Par exemple, les connexions entre SQL Tracking Services et SQL Persistence Services ne sont pas partagées. Vous pouvez utiliser ce service dans vos workflows pour prendre en charge les transactions nécessaires à l’intégrité des données.

SharedConnectionWorkflowCommitWorkBatchService

Ce service est utilisé pour les transactions de base de données qui utilisent une connexion partagée entre différents objets. Si l’application hôte souhaite utiliser ce service, elle doit l’ajouter à WorkflowRuntime à l’aide de la méthode AddService ou via le fichier de configuration.

Services du planificateur de flux de travail

Les services du planificateur de flux de travail gèrent la façon dont les instances de flux de travail sont planifiées par le moteur d’exécution de flux de travail, qu’elles soient gérées en mode asynchrone ou synchrone manuel. WF fournit deux implémentations prêtes à l’emploi pour workflowSchedulerService : DefaultWorkflowSchedulerService et ManualWorkflowSchedulerService.

Le moteur d’exécution WF nécessite un service de planificateur de flux de travail pour exécuter des flux de travail. Par défaut, il utilise DefaultWorkflowSchedulerService. L’application hôte peut choisir de remplacer defaultWorkflowSchedulerService par ManualWorkflowSchedulerService ou un service personnalisé.

DefaultWorkflowSchedulerService

DefaultWorkflowSchedulerService crée et gère les threads qui exécutent des instances de flux de travail de manière asynchrone sur le moteur d’exécution de flux de travail et inclut la prise en charge par défaut de la mise en file d’attente de plusieurs instances de flux de travail dans le pool de threads d’exécution. Si aucun autre service de planificateur de flux de travail instance n’est ajouté à WorkflowRuntime, il utilise defaultWorkflowSchedulerService par défaut.

ManualWorkflowSchedulerService

ManualWorkflowSchedulerService est utilisé pour l’exécution synchrone des instances de workflow. Si ce service est utilisé, les instances de flux de travail sont exécutées sur le thread appelant à partir de l’application hôte, bloquant ainsi l’exécution de l’application hôte jusqu’à ce que le flux de travail instance devienne inactif.

Services de persistance de flux de travail

Les services de persistance sont responsables du stockage et de la récupération (chargement et déchargement) de l’état instance workflow. WF fournit une implémentation SQL prête à l’emploi du service de persistance : SqlWorkflowPersistenceService.

SqlWorkflowPersistenceService

Cette implémentation prête à l’emploi stocke les informations d’état et de minuteur pour SQL Server/MSDE. SqlWorkflowPersistenceService participe aux transactions de flux de travail et implémente le verrouillage de l’accès. En outre, SqlWorkflowPersistenceService fournit des fonctionnalités permettant d’activer les nouvelles tentatives lorsque le serveur SQL n’est pas disponible. Cela peut être contrôlé en définissant la propriété EnableRetries sur le service. Pour plus d’informations sur SqlWorkflowPersistenceService, consultez le Guide de programmation WF.

Workflow Tracking Services

Les services de suivi gèrent les profils de suivi et le stockage des informations de suivi. WF fournit une implémentation SQL prête à l’emploi d’un service de suivi implémenté dans la classe SqlTrackingService .

SqlTrackingService

Cette implémentation stocke les données et les profils de suivi dans SQL Server/MSDE. Le service prend en charge les éléments suivants :

• Participe aux transactions de flux de travail par défaut ; le comportement est contrôlé par la propriété SqlTrackingService.IsTransactional .

• Fournit un mécanisme permettant d’utiliser des profils de suivi par défaut pour tous les types ou d’associer des profils de suivi par types de flux de travail ou instances de flux de travail.

• Prend en charge la maintenance des données en fournissant des fonctionnalités de partitionnement en direct et à la demande.

  Des informations détaillées sur la maintenance des données sont fournies dans la section Maintenance des données avec SqlTrackingService du Guide de programmation WF.

En outre, WF fournit des API SqlTrackingQuery que vous pouvez utiliser pour interroger les données de suivi stockées dans SqlTrackingService. Pour plus d’informations sur SqlTrackingService, consultez le Guide de programmation WF.

Conclusion

WF fournit un moteur d’exécution et des services pour exécuter des flux de travail et gérer leur état. Une application hôte ou un processus doit être écrit pour héberger des flux de travail WF. Cette application hôte est chargée de fournir différents services d’exécution au moteur d’exécution de flux de travail. Les services d’exécution WF prêtes à l’emploi sont destinés à répondre à des scénarios courants. Toutefois, si les services prêtes à l’emploi ne répondent pas aux besoins de l’application hôte, l’application hôte doit implémenter des services personnalisés et les fournir au runtime de flux de travail.

En outre, WF fournit une infrastructure pour gérer et surveiller les instances de flux de travail en cours d’exécution et pour prendre en charge les applications hôtes qui choisissent d’être fiables et hautement disponibles. Les applications hôtes doivent décider comment utiliser les différentes options en fonction de leurs scénarios spécifiques à l’hébergement.

Pour plus d'informations

Cet article, ainsi que les ressources suivantes, doivent aider les développeurs qui découvrent la technologie de flux de travail à en savoir plus sur la technologie et à devenir rapidement productifs en l’utilisant.

• Centre de développement MSDN Workflow
  • Contient des documents et des liens vers des webdiffusions et des labos.
• Exemples de sites de la communauté
• Documentation du Kit de développement logiciel (SDK) Windows
  • Si vous n’avez pas le Kit de développement logiciel (SDK) Windows Foundation, téléchargez-le à partir du site du Kit de développement logiciel (SDK) Windows. Le Kit de développement logiciel (SDK) de workflow Windows fait partie du Kit de développement logiciel (SDK) Windows. Il contient des références de guide de programmation WF, des références d’API et divers exemples de technologies et d’applications.
• Forum de flux de travail MSDN
  • Forum de discussion qui peut fournir des réponses aux questions relatives à l’hébergement du runtime WF ou WF en général.

 

À propos de l’auteur

Moustafa Khalil Ahmed est responsable de programme au sein de l’équipe WF chez Microsoft Corp., Redmond, WA. Depuis qu’il a rejoint Microsoft en 2000, il a travaillé sur le développement de différents composants de serveur et a participé à l’expédition de quatre produits serveur, dont Microsoft BizTalk Server. Avant de travailler chez Microsoft, Moustafa était ingénieur logiciel, analyste d’affaires et responsable de compte chez ITWorx, au Caire, En Égypte.