Concepts des espaces de noms Azure Event Grid

Article
11/16/2023

Cet article vous présente les principaux concepts et fonctionnalités associés aux rubriques d’espace de noms.

Événements

Un événement correspond à la plus petite quantité d’informations décrivant intégralement quelque chose qui s’est produit dans le système. Nous faisons souvent référence à un événement en tant qu’événement discret, car il représente un fait distinct et autonome sur un système qui fournit un insight qui peut être actionnable. Chaque événement possède des informations communes telles que la source de l’événement, la time à laquelle l’événement a eu lieu et un identificateur unique. Chaque événement a également un type, qui est généralement un identificateur unique qui décrit le type d’annonce pour lequel l’événement est utilisé.

Par exemple, un événement concernant un fichier en cours de création dans le Stockage Azure a des informations détaillées sur le fichier, notamment la valeur lastTimeModified. Un événement Event Hubs contient l’URL du fichier capturé. Un événement concernant une nouvelle commande dans votre microservice Orders pourrait avoir un attribut orderId et un attribut URL pour la représentation de l’état de la commande. Voici quelques exemples supplémentaires de types d’événements : com.yourcompany.Orders.OrderCreated, org.yourorg.GeneralLedger.AccountChanged, io.solutionname.Auth.MaximumNumberOfUserLoginAttemptsReached.

Voici un exemple d’événement :

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

Un autre type d’événement

La communauté d’utilisateurs fait également référence aux événements en tant que messages qui portent un point de données, tels qu’une lecture d’appareil unique ou un clic sur une page d’application web. Ce type d’événement est généralement analysé sur une fenêtre de temps pour dériver des insights et effectuer une action. Dans la documentation d’Event Grid, nous faisons référence à ce type d’événement comme un point de données, des données de streaming ou simplement la télémétrie. Parmi les autres types de messages, ce type d’événements est utilisé avec la fonctionnalité de répartiteur MQTT (Message Queuing Telemetry Transport) d’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. Un CloudEvent est un type de message qui contient ce qui est communiqué, que l’on appelle données d’événement, ainsi que des métadonnées à son sujet. Les données d’événement dans les architectures pilotées par les événements portent généralement les informations annonçant une modification d’état système. Les métadonnées CloudEvents sont composées d’un ensemble d’attributs qui fournissent des informations contextuelles sur le message, comme son origine (le système source), son type, etc. Tous les messages valides respectant les spécifications CloudEvents doivent inclure les attributs de contexte requis suivants :

La spécification CloudEvents définit également des attributs facultatifs et de contexte d’extension que vous pouvez inclure lors de l’utilisation d’Event Grid.

Lors de l’utilisation d’Event Grid, CloudEvents est le format d’événement préféré en raison de ses cas d’usage bien documentés (modes de transfert d’événements, formats d’événements, etc.), de son extensibilité et de son interopérabilité améliorée. CloudEvents améliore l’interopérabilité en proposant un format d’événement commun pour la publication et la consommation des événements. Il permet des méthodes standards de routage et des outils uniformes qui gèrent des événements.

Modes de contenu CloudEvents

La spécification CloudEvents définit trois modes de contenu : binaire, structuré et par lots.

Important

Avec tout 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 du type de média défini dans Content-Type.

Prise en charge de CloudEvents

Ce tableau indique la prise en charge actuelle de la spécification CloudEvents :

Mode de contenu CloudEvents	Pris en charge ?
JSON structuré	Oui
JSON structuré par lots	Oui, pour les événements de publication
Binaire	Oui, pour les événements de publication

La taille maximale autorisée pour un événement est de 1 Mo. Les événements de plus de 64 Ko donnent lieu à une facturation par incréments de 64 Ko.

Mode de contenu structuré

Un message en mode de contenu structuré CloudEvents dispose à la fois des attributs de contexte et des données d’événement regroupés dans une charge utile HTTP.

Important

Actuellement, Event Grid prend en charge le format JSON CloudEvents avec HTTP.

Voici un exemple de CloudEvents en mode structuré à l’aide du format JSON. Les métadonnées (tous les attributs qui ne sont pas des « données ») et les données de message/événement (l’objet de « données ») sont toutes décrites à l’aide de JSON. Notre exemple inclut tous les attributs de contexte requis, ainsi que certains attributs facultatifs (subject, time et datacontenttype) et les attributs d’extension (comexampleextension1, comexampleothervalue).

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

Vous pouvez utiliser le format JSON avec du contenu structuré pour envoyer des données d’événement qui ne sont pas représentées par une valeur JSON. Pour ce faire, procédez comme suit :

Incluez un attribut datacontenttype avec le type de média dans lequel les données sont encodées.
Si le type de média est encodé dans un format de texte tel que text/plain, text/csv ou application/xml, vous devez utiliser un attribut data avec une chaîne JSON contenant ce que vous communiquez en tant que valeur.
Si le type de média représente un encodage binaire, vous devez utiliser un attribut data_base64 dont la valeur est une chaîne JSON contenant la valeur binaire codée en BASE64.

Par exemple, ce CloudEvent transporte les données d’événement encodées dans application/protobuf pour échanger des messages Protobuf.

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "datacontenttype" : "application/protobuf",
    "data_base64" : "VGhpcyBpcyBub3QgZW5jb2RlZCBpbiBwcm90b2J1ZmYgYnV0IGZvciBpbGx1c3RyYXRpb24gcHVycG9zZXMsIGltYWdpbmUgdGhhdCBpdCBpcyA6KQ=="
}

Pour plus d’informations sur l’utilisation des attributs data ou data_base64, consultez Gestion des données.

Pour plus d’informations sur ce mode de contenu, consultez la documentation de CloudEvents sur les spécifications du mode de contenu structuré HTTP.

Mode de contenu par lots

Event Grid prend actuellement en charge le mode de contenu par lots JSON lors de la publication de CloudEvents sur Event Grid. Ce mode de contenu utilise un tableau JSON rempli de CloudEvents en mode de contenu structuré. Par exemple, votre application peut publier deux événements à l’aide d’un tableau comme suit. De même, si vous utilisez le SDK de plan de données d’Event Grid, cette charge utile est également ce qui est envoyé :

[
    {
        "specversion": "1.0",
        "id": "E921-1234-1235",
        "source": "/mycontext",
        "type": "com.example.someeventtype",
        "time": "2018-04-05T17:31:00Z",
        "data": "some data"
    },
    {
        "specversion": "1.0",
        "id": "F555-1234-1235",
        "source": "/mycontext",
        "type": "com.example.someeventtype",
        "time": "2018-04-05T17:31:00Z",
        "data": {
            "somekey" : "value",
            "someOtherKey" : 9
        }
    }
]

Pour plus d’informations, consultez les spécifications de mode de contenu par lots de CloudEvents.

Traitement par lots

Votre application doit regrouper plusieurs événements dans un tableau afin d’obtenir une plus grande efficacité et un débit plus élevé avec une seule demande de publication. Les lots peuvent comporter jusqu’à 1 Mo. La taille maximale d’un événement est de 1 Mo.

Mode de contenu binaire

Un CloudEvent en mode de contenu binaire a ses attributs de contexte décrits en tant qu’en-têtes HTTP. Les noms des en-têtes HTTP sont le nom de l’attribut de contexte précédé de ce-. L’en-tête Content-Type reflète le type de média dans lequel les données d’événement sont encodées.

Important

Lorsque vous utilisez le mode de contenu binaire, l’en-tête HTTP ce-datacontenttype NE DOIT PAS également être présent.

Important

Si vous envisagez d’inclure vos propres attributs (c’est-à-dire des attributs d’extension) lors de l’utilisation du mode de contenu binaire, vérifiez que leurs noms se composent de lettres minuscules (a-z) ou de chiffres (0-9) en caractères ASCII et qu’ils ne dépassent pas une longueur de 20 caractères. Autrement dit, la convention d’affectation de noms pour l’affectation de noms aux attributs de contexte CloudEvents est plus restrictive que celle des noms d’en-tête HTTP valides. Tous les noms d’en-tête HTTP valides ne sont pas des noms d’attribut d’extension valides.

La charge utile HTTP représente les données d’événement encodées en fonction du type de média dans Content-Type.

Une requête HTTP utilisée pour publier un CloudEvent en mode de contenu binaire peut ressembler à cet exemple :

POST / HTTP/1.1
HOST mynamespace.eastus-1.eventgrid.azure.net/topics/mytopic
ce-specversion: 1.0
ce-type: com.example.someevent
ce-source: /mycontext
ce-id: A234-1234-1234
ce-time: 2018-04-05T17:31:00Z
ce-comexampleextension1: value
ce-comexampleothervalue: 5
content-type: application/protobuf

Binary data according to protobuf encoding format. No context attributes are included.

Quand utiliser le mode de contenu binaire ou structuré de CloudEvents

Vous pouvez utiliser le mode de contenu structuré si vous souhaitez une approche simple pour transférer des CloudEvents entre tronçons et protocoles. Étant donné qu’un CloudEvent en mode de contenu structuré contient le message et ses métadonnées, il est facile pour les clients de l’utiliser dans son ensemble et de le transférer vers d’autres systèmes.

Vous pouvez utiliser le mode de contenu binaire si vous savez que les applications en aval nécessitent uniquement le message sans aucune information supplémentaire (autrement dit, les attributs de contexte). Bien qu’avec le mode de contenu structuré, vous pouvez toujours récupérer les données d’événement (message) hors du CloudEvent, cela est plus facile si une application grand public a simplement le message dans la charge utile HTTP. Par exemple, d’autres applications peuvent utiliser des protocoles différents et peuvent s’intéresser uniquement à votre message principal, et non à ses métadonnées. En fait, les métadonnées peuvent être pertinentes uniquement pour le premier tronçon immédiat. Dans ce cas, disposer des données que vous souhaitez échanger sans ses métadonnées se prête à une gestion et à un transfert plus faciles.

Serveurs de publication

Un éditeur est l’application qui envoie des événements à Event Grid. Il peut s’agir de la même application d’où proviennent les événements, la source d’événement. Vous pouvez publier des événements à partir de votre propre application lorsque vous utilisez des rubriques d’espace de noms.

Sources d’événement

La source d’un événement désigne l’endroit où l’événement se produit. Chaque source d’événement prend en charge un ou plusieurs types d’événements. Par exemple, votre application est la source d’événements pour les événements personnalisés définis par votre système. Lorsque vous utilisez des rubriques d’espace de noms, les sources d’événements prises en charge sont vos propres applications.

Espaces de noms

Un espace de noms Event Grid est un conteneur de gestion pour les ressources suivantes :

Ressource	Protocole pris en charge
Rubriques d’espace de noms	HTTP
Espaces de rubriques	MQTT
Clients	MQTT
Groupes de clients	MQTT
Certificats de l’autorité de certification	MQTT
Liaisons d’autorisation	MQTT

Avec un espace de noms Azure Event Grid, vous pouvez regrouper les ressources associées et les gérer en tant qu’unité unique dans votre abonnement Azure. Elle vous donne un nom de domaine complet (FQDN).

Un espace de noms expose deux points de terminaison :

Un point de terminaison HTTP pour prendre en charge les exigences générales de messagerie à l’aide de rubriques d’espace de noms.
Un point de terminaison MQTT pour la messagerie IoT ou des solutions qui utilisent MQTT.

Un espace de noms fournit également des points de terminaison réseau intégrés DNS. Il fournit aussi une gamme de fonctionnalités de contrôle d’accès et de gestion de l’intégration réseau, telles que le filtrage d’entrée IP publique et les liaisons privées. Il s’agit également du conteneur d’identités managées utilisé pour les ressources contenues dans l’espace de noms.

Voici quelques points supplémentaires sur les espaces de noms :

L’espace de noms est une ressource suivie avec des propriétés tags et location. Une fois créée, elle se trouve dans resources.azure.com.
Le nom de l’espace de noms peut être compris entre 3 et 50 caractères. Il peut inclure des caractères alphanumériques, un trait d’union(-), et aucun espace.
Le nom doit être unique pour chaque région.
Régions actuellement prises en charge : USA Centre, Asie Est, USA Est, USA Est 2, Europe Nord, USA Centre Sud, Asie Sud-Est, Émirats arabes unis Nord, Europe Ouest, USA Ouest 2, USA Ouest 3.

Unités de débit

Les unités de débit (TU) définissent la capacité de débit d’entrée et de sortie dans les espaces de noms. Si vous souhaitez obtenir plus d’informations, consultez Quotas et limites Azure Event Grid.

Rubriques

Une rubrique contient les événements qui ont été publiés sur Event Grid. Vous utilisez généralement une ressource de rubrique pour une collection d’événements associés. Nous avons souvent fait référence à des rubriques à l’intérieur d’un espace de noms en tant que rubriques d’espace de noms.

Rubriques d’espace de noms

Les rubriques d’espace de noms sont des rubriques créées dans un espace de noms Event Grid. Votre application publie des événements sur un point de terminaison d’espace de noms HTTP spécifiant une rubrique d’espace de noms dans laquelle les événements publiés sont contenus logiquement. Lorsque vous concevez votre application, vous pouvez choisir le nombre de rubriques à créer. Pour les solutions volumineuses, créez une un espace de noms pour chaque catégorie d’événements associés. Par exemple, considérez une application qui gère les comptes d’utilisateur et une autre application sur les commandes des clients. Il est peu probable que tous les abonnés aux événements souhaitent des événements des deux applications. Pour séparer les problèmes, créez deux rubriques d’espace de noms : une pour chaque application. Laissez les consommateurs d’événements s’abonner à la rubrique en fonction de leurs besoins. Pour les solutions de petite taille, vous pouvez à la place envoyer tous les événements à une seule rubrique.

Les rubriques d’espace de noms prennent en charge la remise pull et la remise push. Consultez quand utiliser la livraison pull ou push pour vous aider à déterminer si la livraison pull est la bonne approche en fonction de vos besoins.

Abonnements à des événements

Un abonnement aux événements est une ressource de configuration associée à une seule rubrique. Entre autres, vous utilisez un abonnement aux événements pour définir des critères de sélection d’événements afin de définir la collection d’événements disponible pour un abonné sur l’ensemble total d’événements disponibles dans une rubrique. Vous pouvez filtrer des événements en fonction des exigences de l’abonné. Par exemple, vous pouvez filtrer des événements par leur type d’événement. Vous pouvez également définir des critères de filtre sur des propriétés de données d’événement, si vous utilisez un objet JSON comme valeur pour la propriété données. Pour plus d’informations sur les propriétés des ressources, recherchez les opérations de plan de contrôle dans l’API REST Event Grid.

Pour obtenir un exemple de création d’abonnements pour les rubriques d’espace de noms, consultez Publier et consommer des messages à l’aide de rubriques d’espace de noms à l’aide de l’interface CLI.

Remarque

Les abonnements aux événements sous une rubrique d’espace de noms présentent un modèle de ressource simplifié par rapport à celui utilisé pour des rubriques personnalisées, de domaine, de partenaire et système (Event Grid de base). Si vous souhaitez obtenir plus d’informations, consultez Créer, afficher et gérer des abonnements à des événements.

Livraison par extraction

Avec la remise pull, votre application se connecte à Event Grid pour lire les messages à l’aide de la sémantique de type file d’attente. Lorsque les applications se connectent à Event Grid pour consommer des événements, elles contrôlent le taux de consommation des événements et son minutage. Les applications grand public peuvent également utiliser des points de terminaison privés lors de la connexion à Event Grid pour lire des événements à l’aide de l’espace IP privé.

La remise pull prend en charge les opérations suivantes pour lire les messages et contrôler l’état des messages : recevoir, accuser réception, publier, rejeteret renouveler le verrou. Pour en savoir plus, consultez la vue d’ensemble de la remise pull.

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

Avec la remise push, Event Grid envoie des événements à une destination configurée dans un abonnement à des événements (de mode de remise) push. Il fournit une logique de nouvelle tentative robuste si la destination n’est pas en mesure de recevoir des événements.

Important

La remise push des espaces de noms Event Grid prend actuellement en charge Azure Event Hubs en tant que destination. À l’avenir, les espaces de noms Event Grid prendront en charge davantage de destinations, y compris toutes les destinations prises en charge par Event Grid De base.

Remise d’événements Event Hubs

Event Grid utilise le Kit de développement logiciel (SDK) Event Hubs pour envoyer des événements à Event Hubs en utilisant AMQP. Les événements sont envoyés en tant que tableau d’octets, où chaque élément du tableau contient un CloudEvent.

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.

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

Pour une présentation d’Event Grid, consultez À propos d’Event Grid.
Pour commencer à utiliser des rubriques d’espace de noms, reportez-vous aux événements de publication à l’aide des rubriques d’espace de noms.

Concepts des espaces de noms Azure Event Grid

Événements

Un autre type d’événement

CloudEvents

Modes de contenu CloudEvents

Prise en charge de CloudEvents

Mode de contenu structuré

Mode de contenu par lots

Traitement par lots

Mode de contenu binaire

Quand utiliser le mode de contenu binaire ou structuré de CloudEvents

Serveurs de publication

Sources d’événement

Espaces de noms

Unités de débit

Rubriques

Rubriques d’espace de noms

Abonnements à des événements

Livraison par extraction

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

Livraison push

Remise d’événements Event Hubs

Livraison push-and-pull

Quand utiliser la livraison push vs la livraison pull

Livraison par extraction

Livraison push

Étapes suivantes

Ressources supplémentaires