Extensibilité de l'hôte du service de workflow
.NET Framework 4.6.1 fournit la classe WorkflowServiceHost pour l'hébergement de services de workflow. Cette classe est utilisée lorsque vous auto-hébergez un service de workflow dans une application managée ou un service Windows. Cette classe est également utilisée lors de l'hébergement d'un service de workflow dans les services IIS (Internet Information Services) ou WAS (Windows Process Activation Service). La classe WorkflowServiceHost fournit des points d’extension qui vous permettent d’ajouter des extensions personnalisées, de modifier le comportement inactif et d’héberger des workflows sans service (workflows qui n’utilisent aucune activité de messagerie).
Extensions de l'hôte du service de workflow
Le WorkflowServiceHost contient une propriété WorkflowExtensions de type WorkflowInstanceExtensionManager qui fournit des méthodes pour ajouter des extensions au WorkflowServiceHost. Utilisez la méthode Add pour ajouter une extension pour chaque instance du service de workflow. Le délégué spécifié est appelé pour créer une extension lorsqu’une instance du service de workflow est créée ou chargée à partir d’un magasin de persistance. Utilisez la méthode Add pour ajouter une extension pour chaque hôte du service de workflow. Une instance de l'extension est partagée pour toutes les instances du service de workflow.
Réagir aux exceptions non gérées
Le WorkflowUnhandledExceptionBehavior vous permet de spécifier l'action à entreprendre si une exception non gérée est levée dans un service de workflow. La propriété Action spécifie l'une des valeurs de WorkflowUnhandledExceptionAction :
Abandon : abandonne l'instance de service de workflow.
AbandonAndSuspend : restaure le dernier état persistant et interrompt l'instance du service de workflow. Cela ne se produit que si le workflow a déjà été persistant au moins une fois. Dans le cas contraire, l'instance de workflow est annulée.
Cancel : annule l'instance.
Terminate : met fin à l'instance.
Ce comportement peut être configuré dans le code, comme indiqué dans l'exemple suivant.
host.Description.Behaviors.Add(new WorkflowUnhandledExceptionBehavior { Action = WorkflowUnhandledExceptionAction.Abandon });
Il peut également être configuré dans un fichier de configuration, comme illustré dans l'exemple suivant.
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="True"/>
<serviceDebug includeExceptionDetailInFaults="False" />
<workflowUnhandledExceptionBehavior action="Abandon" />
</behavior>
</serviceBehaviors>
</behaviors>
Hébergement de workflows sans service
WorkflowServiceHost peut être utilisé pour héberger des workflows sans service, ou des workflows qui ne commencent pas non plus par une activité Receive ou qui n'utilisent pas les activités de messagerie. Les services de workflow commencent normalement par une activité Receive. Lorsque le WorkflowServiceHost reçoit un message pour un service de workflow, si celui-ci n'est pas déjà en cours d'exécution (ou persistant), une nouvelle instance du service de workflow est créée. Si un workflow ne commence pas par une activité Receive, il ne peut pas être démarré par l'envoi d'un message parce qu'il n'existe aucune activité pour recevoir le message. Pour héberger un workflow sans service, dérivez une classe à partir de WorkflowHostingEndpoint et substituez les méthodes OnGetInstanceId, OnGetCreationContext et OnResolveBookmark. Substituez OnGetInstanceId si vous souhaitez fournir un ID d'instance préféré. Substituez la méthode OnGetCreationContext pour créer un contexte de création de workflow personnalisé ou remplir une instance du WorkflowCreationContext existant. Substituez la méthode OnResolveBookmark pour extraire manuellement le signet du message entrant. Si vous remplacez cette méthode, vous devez invoquer SendResponse dans son corps pour qu'il réponde au message envoyé au WorkflowHostingEndpoint. Faute de cela, la limite MaxConcurrentCalls sera peut-être dépassée. Dans les contrats duplex, vous pouvez détecter votre échec d'appel de SendResponse car le client ne reçoit pas de réponse. Dans les contrats unidirectionnels, vous pouvez ne détecter l'échec de l'appel de SendResponse qu'une fois qu'il est trop tard, c'est-à-dire après le dépassement de la valeur limite MaxConcurrentCalls. Pour créer une nouvelle instance d'un workflow sans service, déclarez un contrat de service définissant une opération qui crée une instance. L'opération de création doit prendre un élément IDictionary<chaîne, objet> pour transmettre tous les paramètres de flux de travail requis. Ce contrat est implémenté de manière implicite par la classe dérivée de WorkflowHostingEndpoint. Lorsque vous hébergez le workflow, ajoutez à l'hôte une instance de la classe dérivée de WorkflowHostingEndpoint en appelant la méthode AddServiceEndpoint, puis appelez Open. Pour créer une instance du workflow, créez un objet ChannelFactory<TChannel> de votre type de contrat de service et appelez CreateChannel. Vous pouvez ensuite appeler l'opération de création définie dans votre contrat de service.