Partager via


Éléments internes de l'hôte du service de workflow

WorkflowServiceHost fournit un hôte pour les services basés sur des workflows. Elle est chargée d'écouter les messages entrants et de les router vers l'instance de service de workflow appropriée, contrôle le déchargement et la persistance des workflows inactifs, et plus encore. Cette rubrique explique comment WorkflowServiceHost traite les messages entrants.

Vue d'ensemble WorkflowServiceHost

La classe WorkflowServiceHost permet d'héberger des services de workflow. Elle écoute les messages entrants et les route vers l'instance de service appropriée, en créant de nouvelles instances ou en chargeant des instances existantes à partir d'un stockage durable, selon les besoins. Le diagramme suivant illustre le fonctionnement général de WorkflowServiceHost :

Diagram that shows an overview of the Workflow Service Host.

Ce diagramme montre que la classe WorkflowServiceHost charge les définitions de service de workflow à partir de fichiers .xamlx et les informations de configuration à partir d'un fichier de configuration. Elle charge aussi la configuration du suivi à partir du profil de suivi. WorkflowServiceHost expose un point de terminaison de contrôle de workflow qui vous permet d'envoyer des opérations de contrôle à des instances de workflow. Pour plus d’informations, consultez l’exemple Point de terminaison de contrôle de workflow.

WorkflowServiceHost expose aussi des points de terminaison d'application qui écoutent les messages d'application entrants. Un message entrant qui arrive est envoyé à l'instance de service de workflow appropriée (si celle-ci est actuellement chargée). Au besoin, une nouvelle instance de workflow est créée. Cependant, si une instance existante a été rendue persistante, elle est chargée à partir du magasin de persistance.

Détails de WorkflowServiceHost

Le diagramme suivant montre un peu plus en détail la façon dont WorkflowServiceHost gère les messages :

Diagram that shows the Workflow Service Host message flow.

Ce diagramme présente trois points de terminaison distincts : un point de terminaison d'application, un point de terminaison de contrôle de workflow et un point de terminaison d'hébergement de workflow. Le point de terminaison d'application reçoit les messages liés à une instance de workflow spécifique. Le point de terminaison de contrôle de workflow écoute les opérations de contrôle. Le point de terminaison d'hébergement de workflow écoute les messages qui entraînent le chargement et l'exécution par WorkflowServiceHost de workflows sans service. Comme le montre le diagramme, tous les messages sont traités via le runtime WCF. La limitation d'instance de service de workflow s'effectue à l'aide de la propriété MaxConcurrentInstances. Cette propriété limite le nombre d'instances de service de workflow. En cas de dépassement de cette limite, les demandes supplémentaires de nouvelle instance de service de workflow ou les demandes d'activation d'instances de workflow persistantes seront mises en file d'attente. Les demandes mises en file d'attente sont traitées dans l'ordre FIFO (premier entré, premier sorti) qu'il s'agisse de demandes de nouvelle instance ou d'une instance en cours d'exécution, persistante. Des informations de stratégie d'hôte qui déterminent le mode de traitement des exceptions non gérées et la façon dont les services de workflow inactifs sont déchargés et rendus persistants sont chargées. Pour plus d’informations sur ces rubriques, consultez Guide pratique pour configurer le comportement des exceptions non prises en charge du workflow avec WorkflowServiceHost et Guide pratique pour configurer le comportement inactif avec WorkflowServiceHost. Les instances de workflow sont rendues persistantes conformément aux stratégies d'hôte, puis rechargées selon les besoins. Pour plus d’informations sur la persistance du workflow, consultez Guide pratique pour configurer la persistance avec WorkflowServiceHost, Création d’un service de workflow de longue durée et Persistance du workflow.

L’illustration suivante montre le flux lors de l’appel de WorkflowServiceHost.Open :

Diagram that shows the flow when WorkflowServiceHost.Open is called.

Le workflow est chargé à partir du XAML et l’arborescence d’activité est créée. WorkflowServiceHost parcourt l'arborescence d'activité et crée la description du service. La configuration est appliquée à l'hôte. Enfin, l'hôte commence à écouter les messages entrants.

L’illustration suivante montre ce que fait WorkflowServiceHost quand il reçoit un message lié à une activité Receive dont CanCreateInstance a la valeur true :

Decision tree used by the WFS Host when it receives a message and CanCreateInstance is true.

Le message arrive et est traité par la pile de canaux WCF. Les limitations sont vérifiées et les requêtes de corrélation exécutées. Si le message est lié à une instance existante, il est remis. Si une nouvelle instance doit être créée, la propriété CanCreateInstance de l'activité Receive est vérifiée. Si sa valeur est true, une nouvelle instance est créée et le message est remis.

L'illustration suivante montre ce que fait WorkflowServiceHost à réception d'un message lié à une activité Receive dont CanCreateInstance a la valeur false.

Decision tree used by the WFS Host when it receives a message and CanCreateInstance is false.

Le message arrive et est traité par la pile de canaux WCF. Les limitations sont vérifiées et les requêtes de corrélation exécutées. Le message est lié à une instance existante (puisque CanCreateInstance a la valeur false), de sorte que l'instance est chargée à partir du magasin de persistance, le signet est repris et le workflow s'exécute.

Avertissement

Si SQL Server est configuré de façon à n'écouter que le protocole NamedPipe, l'ouverture de l'hôte du service de workflow échoue.

Voir aussi