Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Les activités de messagerie permettent aux flux de travail d’envoyer et de recevoir des messages WCF. En ajoutant des activités de messagerie à un flux de travail, vous pouvez modéliser n’importe quel modèle d’échange de messages arbitrairement complexe (MEP).
Modèles d’échange de messages
Il existe trois modèles d’échange de messages de base :
Datagram : en utilisant le MEP datagramme, 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 en transit et n’atteindre jamais le service. Si le client envoie un message, il 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.
Réponse à la demande : lors de l’utilisation du meP de demande-réponse, le client envoie un message au service, le service effectue le traitement requis, puis renvoie une réponse au client. Le modèle se compose de paires demande-réponse. Des exemples d’appels de demande-réponse sont des appels de procédure distante (RPC) et des requêtes GET du navigateur. Ce modèle est également appelé demi-duplex.
Duplex : lorsque vous utilisez le MP duplex, le client et le service peuvent envoyer des messages entre eux 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
.NET Framework 4.6.1 définit les activités de messagerie suivantes :
SendReply - Utilisez 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- Utilisez l’activité Receive pour recevoir un message.
ReceiveReply - Utilisez l’activité ReceiveReply pour recevoir un message de réponse. Cette activité est utilisée par les clients de service de workflow lors de l’implémentation d’un MEP de 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 flux de travail, utilisez une Send activité pour envoyer le message. Pour recevoir ce message dans un flux de travail, utilisez une Receive activité. Les activités Send et Receive ont chacune une propriété nommée Content. Cette propriété contient les données 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 Send activité pour envoyer le message et une ReceiveReply activité 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 Request propriété. 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 nature longue des flux de travail, il est important que le modèle de communication duplex prend également en charge les conversations longues. Pour prendre en charge les conversations longues, les clients qui lancent la conversation doivent fournir au service une occasion de le rappeler ultérieurement lorsque les données sont disponibles. Par exemple, une demande de bon de commande est soumise pour approbation du responsable, mais elle peut ne pas être traitée pendant un jour, une semaine ou même une année ; le flux de travail qui gère l’approbation de bon de commande doit savoir reprendre une fois l’approbation donnée. Ce modèle de communication duplex est pris en charge dans les flux de travail à 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 en utilisant CorrelationHandle. Sur l'activité Send, définissez ce gestionnaire de corrélation comme valeur de la propriété CorrelatesWith. Pour plus d’informations, consultez Durable Duplex.
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 des 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 l'activité Receive ou ReceiveReply reçoivent. Le .NET Framework définit deux classes connexes appelées ReceiveMessageContent et ReceiveParametersContent les deux dérivées de ReceiveContent. Définissez la propriété Receive de l’activité ReceiveReply ou Content sur une instance de l’un de ces types pour recevoir des données dans un service de flux de travail. Le type à utiliser dépend du type de données reçues par l’activité. Si l’activité reçoit un Message objet ou un type de contrat de message, utilisez ReceiveMessageContent. Si l’activité reçoit un ensemble de contrats de données ou de types XML qui peuvent être sérialisés, utilisez ReceiveParametersContent.
ReceiveParametersContent vous permet d’envoyer plusieurs paramètres, tandis que ReceiveMessageContent vous ne pouvez envoyer qu’un seul objet, le message (ou le type de contrat de message).
Remarque
ReceiveMessageContent peut également être utilisé avec un seul contrat de données ou un type XML qui peut être sérialisé. La différence entre l'utilisation de ReceiveParametersContent avec un seul paramètre et le passage direct de l'objet à ReceiveMessageContent réside dans le format de transmission. Le contenu du paramètre est encapsulé dans un élément XML qui correspond au nom de l’opération et l’objet sérialisé est encapsulé dans un élément XML à l’aide du nom du 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. Au lieu de cela, l’objet sérialisé est 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 l'activité SendReply. Le .NET Framework définit deux types connexes appelés SendMessageContent et SendParametersContent les deux dérivés de SendContent. Définissez la propriété Send de l’activité SendReply ou Content sur une instance de l’un de ces types pour envoyer des données depuis un service de flux de travail. Le type à utiliser dépend du type de données que l’activité envoie. Si l’activité envoie un Message objet 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, tandis que SendMessageContent vous ne pouvez envoyer qu’un seul objet, le message (ou le type de contrat de message).
Lors de la programmation impérative avec les activités de messagerie, vous utilisez les génériques InArgument<T> et OutArgument<T> pour encapsuler les objets que vous affectez aux propriétés de message ou de paramètres des activités Send, SendReply, Receive et ReceiveReply. Utiliser InArgument<T> pour les activités Send et SendReply, et OutArgument<T> pour les activités Receive et ReceiveReply. Les arguments In sont utilisés avec les activités d’envoi, car les données sont passées dans les activités.
Out les arguments sont utilisés avec les activités de réception, car les données sont transférées à l'extérieur des activités, comme illustré 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 flux de travail qui définit une opération de requête/réponse qui retourne void, vous devez instancier une SendReply activité et définir la Content propriété sur une instance vide d’un des types de contenu (SendMessageContent ou SendParametersContent) comme illustré 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 flux de travail à partir d’une application de flux de travail, Visual Studio 2012 génère des activités de messagerie personnalisées qui encapsulent les activités habituelles Send et ReceiveReply utilisées dans un MEP de demande/réponse. Pour utiliser cette fonctionnalité, cliquez avec le bouton droit sur le projet client dans Visual Studio, puis sélectionnez Ajouter une>référence de service. Tapez l’adresse de base du service dans la zone d’adresse, puis cliquez sur Go. Les services disponibles sont affichés dans la zone Services : Développez le nœud de service pour afficher les contrats pris en charge. Sélectionnez le contrat que vous souhaitez appeler et la liste des opérations disponibles s’affiche dans la zone Opérations . Vous pouvez ensuite spécifier l’espace de noms de l’activité générée, puis cliquer sur OK. Vous voyez ensuite une boîte de dialogue indiquant que l’opération s’est terminée correctement et que les activités personnalisées générées se trouvent dans la boîte à outils après avoir reconstruit le projet. 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 et déposer les activités personnalisées sur votre flux de travail et définir les propriétés requises dans la fenêtre des propriétés.
Modèles d’activité de messagerie
Pour faciliter la configuration d’un meP de requête/réponse sur le client et le service, Visual Studio 2012 fournit deux modèles d’activité de messagerie.
System.ServiceModel.Activities.Design.ReceiveAndSendReply est utilisé sur le service et System.ServiceModel.Activities.Design.SendAndReceiveReply est utilisé sur le client. Dans les deux cas, les modèles ajoutent les activités de messagerie appropriées à votre flux de travail. Sur le service, le System.ServiceModel.Activities.Design.ReceiveAndSendReply ajoute une activité Receive suivie d'une activité SendReply. La propriété Request est automatiquement définie pour l’activité Receive. Sur le client, le System.ServiceModel.Activities.Design.SendAndReceiveReply ajoute une activité Send suivi d’un ReceiveReply. La propriété Request est automatiquement définie pour l’activité Send. Pour utiliser ces modèles, faites glisser et déposez le modèle approprié sur votre flux de travail.
Activités et transactions de messagerie
Lorsqu’un appel est effectué à un service de workflow, vous pouvez souhaiter transmettre une transaction à l’opération de service. Pour ce faire, placez l’activité Receive au sein d’une TransactedReceiveScope activité. 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 se termine une fois l’exécution du corps terminée. Pour plus d’informations sur les flux de travail et les transactions, consultez Transactions de flux de travail.