Écrire une application d’écoute pour une solution Azure

Ce rubrique décrit comment écrire une application d’écoute de solution Azure qui peut lire les messages publiés sur le Azure Service Bus. Microsoft Dataverse Pour commencer, vous devez vous familiariser avec la manière d’écrire un écouteur Azure Service Bus avant d’essayer de découvrir les spécificités d’un écouteur Dataverse. Pour plus d’informations, voir la Documentation Azure Service Bus.

Écrire un écouteur de file d’attente

Une file d’attente messages est un référentiel de messages reçu au point de terminaison de service bus. Un écouteur de file d’attente est une application qui lit et traite les messages mis en file d’attente. Comme les messages de bus des services sont stockés dans une file d’attente, un écouteur n’a pas besoin d’effectuer une écoute active pour que les messages soient reçus dans la file d’attente. Un écouteur de file d’attente peut être démarré après l’arrivée des messages dans la file d’attente et continuer à traiter ces messages. Les autres types d’auditeurs abordés dans la section suivante doivent écouter activement, sinon ils manqueront l’occasion de lire un message. Ces messages peuvent provenir de Dataverse ou d’une autre source.

Vous pouvez effectuer une lecture destructive du message en utilisant Receive en mode ReceiveMode.ReceiveAndDelete , où le message est lu et supprimé de la file d’attente, ou une lecture non destructive en utilisant le mode ReceiveMode.PeekLock , où le message est lu mais toujours disponible dans la file d’attente. Pour plus d’informations sur les messages de lecture d’une file d’attente, voir Comment recevoir des messages depuis une file d’attente.

Une rubrique est similaire à une file d’attente mais implémente un modèle de publication/d’abonnement. Un ou plusieurs écouteurs peuvent s’abonner à la rubrique et recevoir des messages de sa file d’attente. Pour plus d’informations, voir : Files d’attente, rubriques et abonnements

L’utilisation des files d’attente et des rubriques dans votre conception du logiciel multi-système peut entraîner le découplage des systèmes. Si l’application d’écoute devient indisponible, la livraison du message depuis Dataverse réussit quand même et l’application d’écoute peut continuer à traiter le message de la file d’attente lorsqu’elle est de nouveau en ligne. Pour plus d’informations, voir : Files d’attente, rubriques et abonnements

Écrire un écouteur unidirectionnel, bidirectionnel ou REST

En plus de l’écouteur de file d’attente décrit précédemment, vous pouvez écrire un écouteur pour trois autres contrats Service Bus pris en charge par Dataverse : unidirectionnel, bidirectionnel et REST. Un écouteur unidirectionnel peut lire et traiter un message publié sur le bus des services. Un écouteur bidirectionnel peut effectuer la même chose mais peut également renvoyer une chaîne de quelques informations dans Dataverse. Un écouteur REST fait la même chose que l’écouteur bidirectionnel sauf qu’il fonctionne avec un point de terminaison REST. Notez que ces auditeurs doivent effectuer une écoute active au niveau du point de terminaison de service pour lire un message envoyé via le bus des services. Si l’écouteur n’écoute pas lorsque Dataverse tente de publier un message sur le bus des services, le message ne sera pas envoyé.

L’écriture d’un écouteur est structurée autour de ce qui est appelé ABC : Address (adresse), Binding (liaison) et Contract (contrat).

Écouteur unidirectionnel

• Adresse : URI de service

• Liaison : WS2007HttpRelayBinding

• Contrat : IServiceEndpointPlugin

Lorsque votre écouteur est inscrit avec un point de terminaison, la méthode Execute de l’écouteur est appelée lorsqu’un message est publié sur le bus des services par Dataverse. La méthode Execute ne retourne aucune donnée à partir de l’appel de la méthode. Pour plus d’informations, voir l’exemple d’écouteur à sens unique Exemple : écouteur unidirectionnel.

Écouteur bidirectionnel

• Adresse : URI de service

• Liaison : WS2007HttpRelayBinding

• Contrat : ITwoWayServiceEndpointPlugin

Pour ce contrat bidirectionnel, la méthode Execute renvoie une chaîne de l’appel de méthode. Pour plus d’informations, voir l’exemple d’écouteur bidirectionnel Exemple : écouteur bidirectionnel.

Écouteur REST

• Adresse : URI de service

• Liaison : WebHttpRelayBinding

• Contrat : IWebHttpServiceEndpointPlugin

Pour le contrat REST, la méthode Execute renvoie une chaîne de l’appel de méthode. Reportez-vous à l’exemple d’écouteur REST Exemple : Port d’écoute REST, pour plus d’informations. Notez que dans l’exemple d’écouteur REST, un WebServiceHost est instancié et non un ServiceHost, comme c’est le cas dans l’exemple bidirectionnel.

Filtrer les messages

Il existe un ensemble de propriétés contenant des informations supplémentaires ajoutées à chaque message négocié Propriétés propriété envoyée depuis Dataverse. L’ensemble de propriétés, disponibles avec les points de terminaison des files d’attente, relais et des rubriques, contient les informations suivantes :

• URI de l’organisation
• ID de l’utilisateur appelant
• ID de l’utilisateur émetteur
• Nom logique de la table
• Nom de la requête

Ces informations identifient l’organisation, l’utilisateur, la table et la demande de message traitée par Dataverse résultant du message de bus des services en cours de publication. La disponibilité de ces propriétés indique que le message a été envoyé depuis Dataverse. Votre code d’écouteur peut décider comment traiter le message à partir de ces valeurs.

Lisez le contexte de données dans plusieurs formats de données

Le contexte de données de l’opération Dataverse actuelle est transmis à votre application d’écoute pour solution Azure dans le corps d’un message service bus. Dans les versions précédentes, seul un format binaire .NET était pris en charge. Pour une interopérabilité entre les plateformes (non .NET) , vous pouvez désormais spécifier un des trois formats de données pour le corps du message : .NET binaire, JSON ou XML. Ce format est spécifié dans la colonne MessageFormat de la table ServiceEndpoint.

Lors de la réception de messages, votre application d’écoute peut lire le contexte de données dans le corps du message en fonction du contentType du message, comme indiqué dans l’exemple de code.

var receivedMessage = inboundQueueClient.Receive(TimeSpan.MaxValue);  
  
if (receivedMessage.ContentType == "application/msbin1")  
{  
    RemoteExecutionContext context = receivedMessage.GetBody<RemoteExecutionContext>();  
}  
else if (receivedMessage.ContentType == "application/json")  
{  
    //string jsonBody = new StreamReader(receivedMessage.GetBody<Stream>(), Encoding.UTF8).ReadToEnd();  
    RemoteExecutionContext contextFromJSON = receivedMessage.GetBody<RemoteExecutionContext>(  
        new DataContractJsonSerializer(typeof(RemoteExecutionContext)));  
}  
else if (receivedMessage.ContentType == "application/xml")  
{  
    //string xmlBody = new StreamReader(receivedMessage.GetBody<Stream>(), Encoding.UTF8).ReadToEnd();  
    RemoteExecutionContext contextFromXML = receivedMessage.GetBody<RemoteExecutionContext>(  
        new DataContractSerializer(typeof(RemoteExecutionContext)));  
}  

Voir aussi

Extensions Azure
Écrire un plug-in compatible Azure personnalisé
Exemple : écouteur unidirectionnel
Exemple : écouteur bidirectionnel
Exemple : Port d’écoute REST
Utilisation des données Dataverse dans votre solution Azure
Utilisation des données d’événement Dataverse dans votre solution Azure Event Hub