Utilisation d'activités de messagerie

Article
04/17/2011

Cette rubrique s'applique à Windows Workflow Foundation 4.

Les activités de messagerie permettent aux workflows d'envoyer et de recevoir des messages WCF. En ajoutant des activités de messagerie à un workflow, vous pouvez modéliser n'importe quel modèle d'échange de messages (MEP) arbitrairement complexe.

Modèles d'échange de messages

Il existe trois modèles d'échange de messages de base :

Datagramme : lors de l'utilisation du datagramme MEP, le client envoie un message au service, mais le service ne répond pas. Cet échange est parfois appelé « fire and forget ». Un échange de ce type requiert une confirmation hors bande de la réussite de la remise. Le message peut être perdu lors de la transmission et ne jamais atteindre le service. Si le client envoie un message avec succès, cela ne garantit pas que le service a reçu le message. Le datagramme est un bloc de construction de messagerie fondamental. Vous pouvez en effet générer vos propres MEP au-dessus de ce bloc.
Demande-réponse : lors de l'utilisation du MEP demande-réponse, le client envoie un message au service, le service fait le traitement nécessaire, puis renvoie une réponse au client. Ce modèle se compose de paires demande-réponse. Parmi les exemples d'appels demande-réponse figurent notamment les appels de procédure distante (RPC) et les demandes GET de navigateur. Ce modèle est également connu sous le nom de mode semi-duplex.
Duplex : lors de l'utilisation du MEP duplex, le client et le service peuvent s'envoyer des messages l'un à l'autre dans n'importe quel ordre. Le MEP duplex est similaire à une conversation téléphonique, où chaque mot prononcé correspond à un message.

Les activités de messagerie vous permettent d'implémenter chacun de ces MEP de base ainsi qu'un MEP arbitrairement complexe.

Activités de messagerie

Le .NET Framework version 4 définit les activités de messagerie suivantes :

Send : utilise l'activité Send pour envoyer un message.
SendReply : utilise l'activité SendReply pour envoyer une réponse à un message reçu. Cette activité est utilisée par les services de workflow lors de l'implémentation d'un MEP demande/réponse.
Receive : utilise l'activité Receive pour recevoir un message.
ReceiveReply : utilise l'activité ReceiveReply pour recevoir un message de réponse. Cette activité est utilisée par les clients du service de workflow lors de l'implémentation d'un MEP demande/réponse.

Activités de messagerie et modèles d'échange de messages

Un MEP datagramme implique un client qui envoie un message et un service qui reçoit le message. Si le client est un workflow, utilisez une activité Send pour envoyer le message. Pour recevoir ce message dans un workflow, utilisez une activité Receive. Les activités Send et Receive ont chacune une propriété nommée Content. Cette propriété contient les données qui sont envoyées ou reçues. Lors de l'implémentation du MEP demande-réponse, le client et le service utilisent tous les deux des paires d'activités. Le client utilise une activité Send pour envoyer le message et une activité ReceiveReply pour recevoir la réponse du service. Ces deux activités sont associées l'une à l'autre par la propriété Request. Cette propriété est définie sur l'activité Send qui a envoyé le message d'origine. Le service utilise également une paire d'activités associées : Receive et SendReply. Ces deux activités sont associées par la propriété Request. Cette propriété est définie sur l'activité Receive qui a reçu le message d'origine. Les activités ReceiveReply et SendReply, comme Send et Receive vous permettent d'envoyer une instance Message ou un type de contrat de message.

En raison de la longue durée d'exécution des workflows, il est important que le modèle duplex de communication prenne également en charge des conversations de longue durée. Pour prendre en charge des conversations de longue durée, les clients qui initialisent la conversation doivent donner au service la possibilité de le rappeler plus tard lorsque les données deviennent disponibles. Par exemple, une demande de bon de commande est soumise à l'approbation du gestionnaire, mais elle risque de ne pas être traitée dans la journée, la semaine ou même l'année ; le workflow qui gère l'approbation du bon de commande doit le savoir pour continuer une fois l'approbation donnée. Ce modèle de communication en duplex est pris en charge dans les workflows à l'aide de la corrélation. Pour implémenter un modèle duplex, utilisez les activités Send et Receive. Sur l'activité Receive, initialisez une corrélation à l'aide de la valeur de clé spéciale de la propriété CallbackHandleName. Sur l'activité Send, définissez ce gestionnaire de corrélation comme valeur de la propriété CorrelatesWith. Pour plus d'informations, consultez Duplex durable.

Remarque :
L'implémentation d'un duplex de workflow à l'aide d'une corrélation de rappel (« Duplex Durable ») est destinée aux conversations de longue durée. Ce n'est pas la même chose qu'un duplex WCF avec des contrats de rappel, où la conversation est de courte durée d'exécution (durée de vie du canal).

Mise en forme de messages et activités de messagerie

Les activités Receive et ReceiveReply ont une propriété nommée Content. Cette propriété est de type ReceiveContent et représente les données que reçoit l'activité Receive ou ReceiveReply. Le .NET Framework définit deux classes connexes nommées RecieveMessageContent et ReceiveParametersContent qui sont toutes les deux dérivées de ReceiveContent. Définissez la propriété Content de l'activité Receive ou ReceiveReply sur une instance de l'un de ces types pour recevoir des données dans un service de workflow. Le type à utiliser dépend du type des données que l'activité reçoit. Si l'activité reçoit un objet Message ou un type de contrat de message, utilisez ReceiveMessageContent. Si l'activité reçoit un jeu de contrat de données ou de types XML qui peut être sérialisé, utilisez ReceiveParametersContent. ReceiveParametersContent vous permet d'envoyer plusieurs paramètres, alors que ReceiveMessageContent ne vous permet d'envoyer qu'un seul objet, le message (ou le type de contrat de message).

Remarque :
ReceiveMessageContent peut également être utilisé avec un contrat de données ou un type XML unique qui peut être sérialisé. La différence entre utiliser ReceiveParametersContent avec un paramètre unique et l'objet transmis directement à RecieveMessageContent est le format de câble. Le contenu du paramètre est encapsulé dans un élément XML correspondant au nom de l'opération et l'objet sérialisé est encapsulé dans un élément XML à l'aide du nom de paramètre (par exemple, `<Echo><msg>Hello, World</msg></Echo>`). Le contenu du message n'est pas encapsulé par le nom de l'opération. L'objet sérialisé est en revanche placé dans un élément XML à l'aide du nom de type qualifié XML (par exemple, `<string>Hello, World</string>`).

Remarque :

ReceiveMessageContent peut également être utilisé avec un contrat de données ou un type XML unique qui peut être sérialisé. La différence entre utiliser ReceiveParametersContent avec un paramètre unique et l'objet transmis directement à RecieveMessageContent est le format de câble. Le contenu du paramètre est encapsulé dans un élément XML correspondant au nom de l'opération et l'objet sérialisé est encapsulé dans un élément XML à l'aide du nom de paramètre (par exemple, <Echo><msg>Hello, World</msg></Echo>). Le contenu du message n'est pas encapsulé par le nom de l'opération. L'objet sérialisé est en revanche placé dans un élément XML à l'aide du nom de type qualifié XML (par exemple, <string>Hello, World</string>).

Les activités Send et SendReply ont également une propriété nommée Content. Cette propriété est de type SendContent et représente les données envoyées par l'activité Send ou SendReply. Le .NET Framework définit deux types connexes nommés SendMessageContent et SendParametersContent qui sont tous les deux dérivés de SendContent. Définissez la propriété Content de l'activité Send ou SendReply sur une instance de l'un de ces types pour envoyer des données à partir d'un service de workflow. Le type à utiliser dépend du type de données que l'activité envoie. Si l'activité envoie un objet Message ou un type de contrat de message, utilisez SendMessageContent. Si l'activité envoie un type de contrat de données utilisez SendParametersContent. SendParametersContent vous permet d'envoyer plusieurs paramètres, alors que SendMessageContent ne vous permet d'envoyer qu'un seul objet, le message (ou le type de contrat de message).

Lorsque vous programmez de façon impérative avec les activités de messagerie, vous utilisez les InArgument et OutArgument génériques pour encapsuler les objets que vous affectez au message ou les propriétés de paramètres des activités Send, SendReply, Receive et ReceiveReply. Utilisez InArgument pour les activités Send et SendReply, OutArgument pour les activités Receive et ReceiveReply. Les arguments In sont utilisés avec les activités d'envoi, car les données sont transmises dans les activités. Les arguments Out sont utilisés avec les activités de réception, car les données sont transmises hors des activités, comme indiqué dans l'exemple suivant.

Receive reserveSeat = new Receive
{ 
    ... 
    Content = new ReceiveParametersContent
    {
        Parameters =
        {
            { "ReservationInfo", new OutArgument<ReservationRequest>(reservationInfo) }
        }
    }
};
SendReply reserveSeat = new SendReply
{ 
    ... 
    Request = reserveSeat,
    Content = new SendParametersContent
    {
        Parameters =
        {
            { "ReservationId", new InArgument<string>(reservationId) }
        }
    },
};

Lors de l'implémentation d'un service de workflow définissant une opération de demande/réponse qui retourne void, vous devez instancier une activité SendReply et définir la propriété Content sur une instance vide de l'un des types de contenu (SendMesageContent ou SendParametersContent), comme indiqué dans l'exemple suivant.

Receive rcv = new Receive()
{
ServiceContractName = "IService",
OperationName = "NullReturningContract",
Content = new ReceiveParametersContent( new Dictionary<string, OutArgument>() { { "message", new OutArgument<string>() } } )
};
SendReply sr = new SendReply()
{
Request = rcv
   Content = new SendParametersContent();
};

Ajouter une référence de service

Lors de l'appel d'un service de workflow à partir d'une application de workflow, Visual Studio 2010 génère des activités de messagerie personnalisées qui encapsulent les activités Send et ReceiveReply habituellement utilisées dans un MEP demande/réponse. Pour utiliser cette fonctionnalité, cliquez avec le bouton droit sur le projet client dans Visual Studio 2010 et sélectionnez Ajouter une référence de service. Tapez l'adresse de base du service dans la zone d'adresse et cliquez sur OK. Les services disponibles sont affichés dans la zone Services :. Développez le nœud du service pour afficher les contrats pris en charge. Sélectionnez le contrat que vous souhaitez appeler ; la liste des opérations disponibles s'affiche dans la zone Opérations. Vous pouvez alors spécifier l'espace de noms pour l'activité générée et cliquer sur OK. Un dialogue s'affiche indiquant que l'opération s'est achevée avec succès et que les activités personnalisées générées se trouveront dans la boîte à outils une fois le projet reconstruit. Il existe une activité pour chaque opération définie sur le contrat de service. Après avoir reconstruit le projet, vous pouvez faire glisser les activités personnalisées sur votre workflow et définir les propriétés nécessaires dans la fenêtre de propriétés.

Modèles d'activité de messagerie

Pour simplifier la configuration d'un MEP demande/réponse sur le client et le service, Visual Studio 2010 fournit deux modèles d'activité de messagerie. ReceiveAndSendReply est utilisé sur le service et SendAndReceiveReply est utilisé sur le client. Dans les deux cas, les modèles ajoutent les activités de messagerie appropriées à votre workflow. Sur le service, le modèle ReceiveAndSendReply ajoute une activité Receive suivie d'une activité SendReply. La propriété Request est automatiquement définie sur l'activité Receive. Sur le client, le modèle SendAndReceiveReply ajoute une activité Send suivie d'une activité ReceiveReply. La propriété Request est automatiquement définie sur l'activité Send. Pour utiliser ces modèles, il suffit de glisser-déplacer le modèle approprié sur votre workflow.

Activités de messagerie et transactions

Lorsqu'un appel est effectué à un service de workflow, vous pouvez souhaiter transmettre une transaction à l'opération de service. Pour cela, placez l'activité Receive dans une activité TransactedReceiveScope. L'activité TransactedReceiveScope contient une activité Receive et un corps. La transaction transmise au service reste ambiante pendant l'exécution du corps de l'activité TransactedReceiveScope. La transaction est effectuée lorsque le corps termine son exécution. Pour plus d'informations sur le sujet suivant les workflows et les transactions, consultez Transactions de workflow.

Partager via