Remise pull avec HTTP

  • Article

Cet article s’appuie sur Qu’est-ce qu’Azure Event Grid ? et sur l’article de présentation des concepts Event Grid pour fournir des informations essentielles avant que vous ne commenciez à utiliser la remise pull d’Event Grid sur HTTP. Il couvre les concepts fondamentaux, les modèles de ressources et les modes de livraison de messages pris en charge. À la fin de ce document, vous trouverez des liens utiles vers des articles qui vous guideront dans l’utilisation d’Event Grid et d’autres articles contenant des informations conceptuelles détaillées.

Notes

Ce document vous aide à démarrer avec les fonctionnalités Event Grid qui utilisent le protocole HTTP. Cet article convient aux utilisateurs qui ont besoin d’intégrer des applications dans le cloud. Si vous avez besoin de communiquer des données d’appareil IoT, consultez Vue d’ensemble de la fonctionnalité MQTT Broker dans Azure Event Grid.

CloudEvents

Les rubriques d’espace de noms Event Grid acceptent les événements conformes à la spécification CloudEvents 1.0 standard ouverte de la Cloud Native Computing Foundation (CNCF) à l’aide de la liaison de protocole HTTP avec le format JSON.

Pour plus d’informations, consultez les concepts de CloudEvents.

Modes de contenu CloudEvents

La spécification CloudEvents définit les trois modes de contenu que vous pouvez utiliser : binaire, structuré et par lots.

Important

Avec n’importe quel mode de contenu, vous pouvez échanger du texte (JSON, texte/*, etc.) ou des données d’événement encodées binaires. Le mode de contenu binaire n’est pas utilisé exclusivement pour l’envoi de données binaires.

Les modes de contenu ne concernent pas l’encodage que vous utilisez, binaire ou texte, mais la façon dont les données d’événement et leurs métadonnées sont décrites et échangées. Le mode de contenu structuré utilise une structure unique, par exemple un objet JSON, où les attributs de contexte et les données d’événement sont regroupés dans la charge utile HTTP. Le mode de contenu binaire sépare les attributs de contexte, qui sont mappés aux en-têtes HTTP, et les données d’événement, qui correspondent à la charge utile HTTP encodée en fonction de la valeur du type de média dans Content-Type.

Pour plus d’informations, consultez Modes de contenu CloudEvents.

Messages et événements

Un CloudEvent comporte généralement des données d’événement qui annoncent une occurrence dans un système, autrement dit, une modification de l’état du système. Néanmoins, vous pouvez transmettre n’importe quel type de données quand vous utilisez CloudEvents. Par exemple, vous pouvez utiliser le format d’échange CloudEvents pour envoyer un message de commande afin de demander une action à une application en aval. Autre exemple : quand vous routez des messages depuis le MQTT broker d’Event Grid vers une rubrique. Dans le cadre de ce scénario, vous routez un message MQTT wrappé dans une enveloppe CloudEvents.

Livraison par extraction

Avec la remise pull, votre application se connecte à Event Grid pour lire CloudEvents à l’aide de la sémantique de type file d’attente.

La remise pull offre ces avantages en termes de consommation d’événements :

  • Consommez les événements à votre propre rythme, à grande échelle ou selon un débit d’entrée pris en charge par votre application.

  • Consommez les événements au moment qui vous convient. Par exemple, en fonction des besoins métier, les messages sont traités la nuit.

  • Consommez les événements sur une liaison privée afin que vos données utilisent un espace IP privé.

Remarque

  • Les espaces de noms fournissent un modèle de ressource plus simple avec un seul type de rubrique. Actuellement, Event Grid prend en charge la publication de vos propres événements d’application via des rubriques d’espace de noms. Vous ne pouvez pas consommer d’événements à partir de services Azure ou de systèmes SaaS partenaires à l’aide de rubriques d’espace de noms. Vous ne pouvez pas non plus créer des rubriques système, des rubriques de domaine ou des rubriques de partenaires dans un espace de noms.
  • Les rubriques d’espace de noms prennent en charge le format JSON CloudEvents.

Abonnements aux événements de file d’attente

Lors de la réception d’événements ou l’utilisation d’opérations qui gèrent l’état des événements, une application spécifie un point de terminaison HTTP d’espace de noms, un nom de rubrique et le nom d’un abonnement aux événements de file d’attente. Un abonnement aux événements de file d’attente a son deliveryMode défini sur « queue ». Les abonnements aux événements de file d’attente servent à consommer des événements à l’aide de l’API de remise pull. Pour plus d’informations sur la manière de créer ces ressources, consultez créer des espaces de noms, des rubriques et des abonnements aux événements.

Vous utilisez un abonnement aux événements pour définir les critères de filtrage des événements et, ce faisant, vous définissez efficacement l’ensemble des événements qui sont disponibles pour la consommation par l’intermédiaire de cet abonnement. Une ou plusieurs applications d’abonné (consommateur) peuvent se connecter au même point de terminaison d’espace de noms et utiliser le même abonnement aux rubriques et événements.

Diagramme de haut niveau d’un éditeur et d’un consommateur utilisant un abonnement à un événement. Le consommateur utilise la livraison pull.

Opérations de remise pull

Votre application utilise les opérations suivantes lors de l’utilisation de la remise pull.

  • Une opération de réception est utilisée pour lire un ou plusieurs événements à l’aide d’une requête unique à Event Grid. Par défaut, le répartiteur attend jusqu’à 60 secondes que les événements soient disponibles. Par exemple, les événements deviennent disponibles pour la remise quand ils sont publiés pour la première fois. Une demande de réception réussie retourne aucun ou plusieurs événements. Si des événements sont disponibles, cela retourne autant d’événements disponibles que possible jusqu’au nombre d’événements demandé. Event Grid retourne également un jeton de verrouillage pour chaque lecture d’événement.
  • Un jeton de verrouillage est un type de handle qui identifie un événement que vous pouvez utiliser pour contrôler son état.
  • Une fois qu’une application consommateur reçoit un événement et le traite, elle accuse réception de cet événement. Cette opération indique à Event Grid de supprimer l’événement afin qu’il ne soit pas remis à nouveau à un autre client. L’application consommateur reconnaît un ou plusieurs jetons avec une seule requête en spécifiant leurs jetons de verrouillage avant leur expiration.

Dans d’autres occasions, votre application consommateur peut vouloir libérer ou rejeter des événements.

  • Votre application consommateur libère un événement reçu pour signaler à Event Grid qu’elle n’est pas prête à traiter cet événement et à le rendre disponible pour une nouvelle remise. Pour cela, elle appelle l’opération libérer avec les jetons de verrouillage qui identifient les événements à retourner à Event Grid. Votre application peut contrôler si l’événement doit être libéré immédiatement ou si un délai doit être observé avant que l’événement ne soit disponible pour une nouvelle remise.

  • Vous pouvez choisir de rejeter un événement s’il existe une condition, éventuellement permanente, qui empêche votre application consommateur de traiter cet événement. Par exemple, un message mal formé peut être rejeté, car il ne peut pas être analysé correctement. Les événements rejetés sont en lettres mortes, si une destination de lettre morte est disponible. Sinon, ils sont abandonnés.

Étendue sur laquelle les opérations de remise pull s’exécutent

Lorsque vous appelez une opération recevoir, accuser réception, libérer, rejeter ou renouveler le verrouillage, ces actions sont exécutées dans le contexte de l’abonnement à l’événement. Par exemple, si vous accusez réception d’un événement, cet événement n’est plus disponible par le biais de l’abonnement à l’événement utilisé lors de l’appel de l’action accuser réception. D’autres abonnements à des événements peuvent quand même avoir le « même » événement disponible. Cela est dû au fait qu’un abonnement aux événements obtient une copie des événements publiés. Ces copies d’événements sont effectivement distinctes les unes des autres entre les abonnements aux événements. Chaque événement a son propre état qui est indépendant des autres événements.

Forme des données lors de la réception d’événements à l’aide de la remise pull

Lors de la remise d’événements à l’aide de la remise pull, Event Grid inclut un tableau d’objets qui, à son tour, inclut les objets event et brokerProperties. La valeur de la propriété event est le CloudEvent remis en mode de contenu structuré. L’objet brokerProperties contient le jeton de verrouillage associé au CloudEvent remis. L’objet json suivant est un exemple de réponse d’une opération recevoir qui retourne deux événements :

{
    "value": [
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDXYS23Z+5Hq754VqQjxywE",
                "deliveryCount": 2
            },
            "event": {
                "specversion": "1.0",
                "id": "A234-1234-1235",
                "source": "/mycontext",
                "time": "2018-04-05T17:31:00Z",
                "type": "com.example.someeventtype",
                "data": "some data"
            }
        },
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDLeaL+nRJLNq3/5NXd/T0b",
                "deliveryCount": 1
            },
            "event": {
                "specversion": "1.0",
                "id": "B688-1234-1235",
                "source": "/mycontext",
                "type": "com.example.someeventtype",
                "time": "2018-04-05T17:31:00Z",
                "data": {
                    "somekey" : "value",
                    "someOtherKey" : 9
                }
            }
        }
    ]
}

Livraison push-and-pull

Event Grid prend en charge la remise d’événements push et pull à l’aide de HTTP. Avec la remise push, vous définissez une destination dans un abonnement aux événements, un webhook ou un service Azure, auxquels Event Grid envoie des événements. Avec la livraison pull, les applications abonnées se connectent à Event Grid pour consommer des événements. La remise pull est prise en charge pour les rubriques d’un espace de noms Event Grid.

Important

Event Hubs est pris en charge en tant que destination pour les abonnements aux rubriques d’espace de noms. Dans les prochaines versions, les espaces de noms Event Grid prendront en charge toutes les destinations actuellement disponibles dans Event Grid de base, ainsi que d’autres destinations.

Diagramme de haut niveau montrant la livraison push-and-pull avec le type de ressources impliquées.

Quand utiliser la livraison push vs la livraison pull

Voici des instructions générales pour vous aider à décider quand utiliser la livraison par extraction ou par envoi.

Livraison par extraction

  • Vous avez besoin d’un contrôle total quant au moment où recevoir des événements. Par exemple, votre application peut ne pas fonctionner tout le temps, elle peut ne pas être assez stable ou bien vous traitez des données à certains moments.
  • Vous avez besoin d’un contrôle total sur la consommation des événements. Par exemple, un service ou une couche en aval dans votre application grand public présente un problème qui vous empêche de traiter les événements. Dans ce cas, l’API de livraison pull permet à l’application grand public de libérer un événement déjà lu sur le répartiteur afin qu’il puisse être livré ultérieurement.
  • Vous souhaitez utiliser des liaisons privées lors de la réception d’événements, ce qui n’est possible qu’avec la remise pull, et non avec la remise push.
  • Vous n’avez pas la possibilité d’exposer un point de terminaison et d’utiliser la livraison push, mais vous pouvez vous connecter à Event Grid pour consommer des événements.

Livraison push

  • Vous souhaitez éviter l’interrogation constante pour déterminer si un changement d’état système s’est produit. Vous utilisez plutôt Event Grid pour vous envoyer des événements au moment où les changements d’état se produisent.
  • Vous disposez d’une application qui ne peut pas effectuer d’appels sortants. Par exemple, l’exfiltration des données peut préoccuper votre organisation. Toutefois, votre application peut recevoir des événements via un point de terminaison public.

Étapes suivantes

Les articles suivants vous fournissent des informations sur l’utilisation d’Event Grid ou des informations supplémentaires sur les concepts.