Remise Push de messages et nouvelle tentative avec les rubriques d’espace de noms

Les espaces de noms Event Grid de remise Push fournissent une remise durable. Event Grid tente de remettre immédiatement chaque message au moins une fois pour chaque abonnement correspondant. Si le point de terminaison d’un abonné n’accuse pas réception d’un événement ou si une défaillance se produit, Event Grid effectue une nouvelle tentative de remise conformément à une planification de nouvelles tentatives et une stratégie de nouvelles tentatives fixes. Par défaut, Event Grid distribue un seul événement à la fois à l’abonné.

Abonnement à un événement

Un abonnement aux événements est une ressource de configuration associée à une rubrique d’espace de noms unique. 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. À l’aide d’un abonnement aux événements, vous définissez également le point de terminaison de destination auquel les événements sont envoyés. En outre, un abonnement aux événements vous permet de définir d’autres propriétés, telles que le nombre maximal de nouvelles tentatives de remise et la durée de vie des événements, qui définissent le comportement d’exécution de la remise des événements.

Planification des nouvelles tentatives

Quand Event Grid reçoit une erreur liée à une tentative de remise d’événement, il décide s’il doit retenter la remise, en fonction du type d’erreur.

Si l’erreur retournée par le point de terminaison abonné est une erreur liée à la configuration qui ne peut pas être corrigée à l’aide de nouvelles tentatives, Event Grid envoie l’événement à une destination de lettres mortes configurée. Si aucune lettre morte n’est configurée, l’événement est supprimé. Par exemple, un événement est mis dans la file d’attente de lettres mortes ou supprimé lorsque le point de terminaison configuré sur l’abonnement à l’événement est inaccessible car il a été supprimé. La nouvelle tentative de remise ne se produit pas pour les conditions et erreurs suivantes :

Conditions :

• ArgumentException
• TimeoutException
• UnauthorizedAccessException
• OperationCanceledException
• SocketException |

Codes d’erreur

• 404 - NotFound
• 401 - Unauthorized
• 403 - Forbidden
• 400 -BadRequest
• 414 RequestUriTooLong

Si la condition ou l’erreur retournée par le point de terminaison abonné ne figure pas dans les listes ci-dessus, Event Grid fait de son mieux pour effectuer de nouvelles tentatives conformément à la planification de nouvelle tentative exponentielle suivante :

• 0 seconde (nouvelle tentative immédiate)
• 10 secondes
• 30 secondes
• 1 minute
• 5 minutes

Après cinq minutes, Event Grid continue de réessayer toutes les cinq minutes jusqu’à ce que l’événement soit remis ou que le nombre maximal de nouvelles tentatives ou la durée de vie de l’événement soit atteint(e).

Stratégie de nouvelles tentatives

Vous pouvez personnaliser la stratégie de nouvelle tentative à l’aide des deux propriétés de configuration d’abonnement aux événements suivantes. Un événement est supprimé (aucune lettre morte configurée) ou mis dans la file d’attente de lettres mortes si l’une des propriétés atteint sa limite configurée.

• Nombre maximal de remises : la valeur doit être un entier compris entre 1 et 10. La valeur par défaut est 10. Pour la remise Push, cette propriété définit la quantité maximale de tentatives de remise.
• Rétention : cette propriété est également appelée event time to live. La valeur doit être une valeur de durée ISO 8601 avec une précision de l’ordre de la minute. À partir de l’heure de publication de l’événement, cette propriété définit l’intervalle de temps après lequel le message expire. La valeur minimale autorisée est « PT1M » (une minute). La valeur maximale autorisée est soit sept jours, soit la durée de rétention de la rubrique sous-jacente (la valeur la plus faible est retenue). Le portail Azure offre une expérience utilisateur simple où vous spécifiez les jours, heures et minutes sous forme d’entiers.

Traitement par lot des sorties

Lorsque vous utilisez des Webhooks comme type de point de terminaison de destination, Event Grid envoie par défaut chaque événement individuellement aux abonnés. Vous pouvez configurer Event Grid pour que les événements soient remis par lot afin d’améliorer les performances HTTP dans les scénarios à débit élevé. Le traitement par lot est désactivé par défaut, et peut être activé pour chaque abonnement aux événements.

Lorsque vous utilisez Event Hubs comme type de point de terminaison de destination, Event Grid traite toujours les événements par lot afin d’optimiser l’efficacité et les performances. Aucune configuration de stratégie de traitement par lot n’est disponible, car par défaut Event Grid gère le comportement de traitement par lot lors de la remise à Azure Event Hubs.

Stratégie de traitement par lot

La livraison par lot a deux paramètres :

• Nombre maximum d’événements par lot : nombre maximum d’événements qu’Event Grid livre par lot. La valeur doit être un entier compris entre 1 et 5 000. Ce nombre n’est jamais dépassé. Toutefois, moins d’événements peuvent être remis si aucun autre événement n’est disponible au moment de la remise. Event Grid ne retarde pas la livraison des événements pour créer un lot si moins d’événements sont disponibles.
• Taille de lot préférée en kilo-octets : plafond cible pour la taille de lot en kilo-octets. La valeur doit être un nombre compris entre 1 et 1 024. Comme pour le nombre maximal d’événements, la taille du lot peut être inférieure si aucun autre événement n’est disponible au moment de la remise. Il est possible qu’un lot soit plus grand que la taille de lot préférée si un événement unique est plus volumineux que la taille préférée. Par exemple, si la taille préférée est de 4 Ko et qu’un événement de 10 Ko est envoyé (push) à Event Grid, l’événement de 10 Ko est remis plutôt que supprimé.

La remise par lot est configurée séparément pour chaque abonnement aux événements via le portail, l’interface CLI, PowerShell ou les Kits de développement logiciel (SDK).

Comportement du traitement par lots

• Tout ou aucun

  Le service Event Grid fonctionne selon le principe du tout ou rien. Il ne prend pas en charge la réussite partielle d’une livraison par lot. Les abonnés doivent veiller à demander uniquement un nombre d’événements par lot qu’ils peuvent raisonnablement gérer en 30 secondes.

• Traitement par lot optimiste

  Les paramètres de stratégie de traitement par lot n’imposent pas de limites strictes au comportement du traitement par lot. Ils sont donc respectés dans la limite des possibilités. Lorsque les fréquences d’événements sont faibles, vous observerez souvent que la taille de lot est inférieure au nombre maximal d’événements demandés par lot.

• La valeur par défaut est DÉSACTIVÉ

  Par défaut, Event Grid ajoute un seul événement à chaque demande de livraison. Pour activer le traitement par lot, vous devez définir l’un des paramètres mentionnés dans Stratégie de traitement par lot.

• Valeurs par défaut

  Lors de la création d’un abonnement aux événements, il n’est pas nécessaire de spécifier les deux paramètres (nombre maximal d’événements par lot et taille de lot approximative en kilo-octets). Si un seul paramètre est défini, Event Grid utilise les valeurs par défaut. Pour connaître les valeurs par défaut et la manière de les remplacer, consultez les sections suivantes.

Portail Azure

Ces paramètres s’affichent sous l’onglet Fonctionnalités supplémentaires de la page Abonnement aux événements ou une fois l’abonnement aux événements créé, dans l’option de menu Configuration lors de l’accès à l’abonnement aux événements.

Événements de lettres mortes

Lorsque Event Grid ne peut pas remettre un événement dans un laps de temps donné ou après avoir essayé de remettre l’événement un certain nombre de fois, il envoie l’événement à un compte de stockage. Ce processus est appelé mise en file d’attente de lettres mortes. Event Grid met un événement en file d’attente de lettres mortes lorsque l’une des conditions suivantes est remplie.

• L’événement n’est pas remis pendant la durée de vie (rétention définie dans l’abonnement aux événements).
• Le nombre de tentatives de livraison de l’événement a dépassé la limite.

Si l’une des conditions est remplie, l’événement est supprimé ou mis en file d’attente de lettres mortes. Par défaut, Event Grid n’active pas cette fonctionnalité. Pour l’activer, vous devez spécifier le compte de stockage dans lequel les événements non remis seront conservés au moment de créer l’abonnement aux événements. Les événements sont lus à partir de ce compte de stockage pour résoudre les remises.

Event Grid envoie un événement à l’emplacement des lettres mortes lorsqu’il a effectué toutes ses nouvelles tentatives. Si Event Grid reçoit un code de réponse 400 (requête incorrecte) ou 413 (entité de requête trop grande), il planifie immédiatement l’événement pour la file d’attente de lettres mortes. Ces codes de réponse indiquent que la diffusion de l’événement va échouer.

L’expiration de la durée de vie est vérifiée uniquement lors de la prochaine tentative de livraison planifiée. Par conséquent, même si la durée de vie expire avant la prochaine tentative de livraison planifiée, l’expiration de l’événement est vérifiée uniquement au moment de la prochaine livraison, puis devient lettre morte par la suite.

Un délai de cinq minutes s’écoule entre la dernière tentative de remise d’un événement et le moment où il est placé dans la file d’attente de lettres mortes. Ce décalage est destiné à réduire le nombre d’opérations de stockage d’objets blob. Si l’emplacement des lettres mortes est indisponible pendant quatre heures, l’événement est abandonné.

Avant de définir l’emplacement des lettres mortes, vous devez disposer d’un compte de stockage avec un conteneur. Vous devez indiquer le point de terminaison de ce conteneur au moment de créer l’abonnement aux événements. Le point de terminaison se présente sous la forme suivante : /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

Vous souhaiterez peut-être être averti lorsqu’un événement a été envoyé à l’emplacement des lettres mortes. Pour répondre aux événements non remis à l’aide d’Event Grid, créez un abonnement aux événements pour le stockage Blob de lettres mortes. Chaque fois que votre stockage Blob de lettres mortes reçoit un événement non remis, Event Grid notifie votre gestionnaire. Le gestionnaire répond par les mesures que vous voulez prendre pour réconcilier les événements non remis.

Lors de la configuration de la mise en file d’attente de lettres mortes, vous devez ajouter l’identité managée au rôle de contrôle d’accès en fonction du rôle (RBAC) approprié sur le compte Stockage Azure qui contiendra les événements de lettres mortes. Pour plus d’informations, consultez Destinations et rôles Azure pris en charge.

Formats d’événement de livraison

Cette section fournit des exemples d’événements et d’événements de lettres mortes à l’aide du schéma CloudEvents 1.0, le format de métadonnées de message pris en charge dans les rubriques d’espace de noms.

Schéma CloudEvents 1.0

Événement

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    }
}

Événement de lettres mortes

[
  {
    "deadLetterProperties": {
      "deadletterreason": "Maximum delivery attempts was exceeded.",
      "deliveryattempts": 1,
      "deliveryresult": "Event was not acknowledged nor rejected.",
      "publishutc": "2023-11-01T20:33:51.4521467Z",
      "deliveryattemptutc": "2023-11-01T20:33:52.3692079Z"
    },
    "event": {
      "comexampleextension1": "value1",
      "id": "A234-1234-1234",
      "comexampleothervalue": "5",
      "datacontenttype": "text/xml",
      "specversion": "1.0",
      "time": "2018-04-05T17:31:00Z",
      "source": "/mycontext",
      "type": "com.example.someevent",
      "data": <your-event-data>
    }
  }
]

LastDeliveryOutcome: Probation

Un abonnement aux événements est mis en probation par Event Grid pendant une durée déterminée si les remises d’événements vers cette destination commencent à échouer. La durée de probation n’est pas la même pour les différentes erreurs retournées par le point de terminaison de destination. Si un abonnement aux événements est en probation, les événements peuvent être placés en file d’attente de lettres mortes ou être annulés sans tentative de remise, en fonction du code d’erreur pour lequel il est en probation.

État de distribution du message

Event Grid utilise les codes de réponse HTTP pour accuser réception des événements.

Codes de réussite

Event Grid considère uniquement les codes de réponse HTTP suivants en tant que livraisons réussies. Tous les autres codes d’état sont considérés comme des échecs de remise, et font l’objet de nouvelles tentatives ou de mise en file d’attente de lettres mortes, le cas échéant. Lorsqu'il reçoit un code d'état réussi, Event Grid considère la livraison comme terminée.

• 200 OK
• 201 Créé
• 202 Accepté
• 203 Informations ne faisant pas autorité
• 204 Pas de contenu

Codes d’échec

Tous les codes ne figurant pas dans les codes ci-dessus (200 à 204) sont considérés comme des échecs et feront l’objet de nouvelles tentatives si nécessaire. Certains sont associés à des stratégies de nouvelle tentative spécifiques (voir ci-dessous). Toutes les autres suivent la planification de nouvelle tentative standard. Il est important de garder à l’esprit qu’en raison de la nature hautement parallélisée de l’architecture d'Event Grid, le comportement d'une nouvelle tentative n'est pas déterministe.

Propriétés de remise personnalisées

Les abonnements aux événements vous permettent de définir des en-têtes HTTP qui sont inclus dans les événements remis. Cette fonctionnalité vous permet de définir des en-têtes personnalisés requis par une destination. Vous pouvez configurer jusqu’à 10 en-têtes lors de la création d’un abonnement aux événements. La valeur de chaque en-tête ne doit pas être supérieure à 4 096 (4 Ko) octets. Vous pouvez définir des en-têtes personnalisés sur les événements remis aux destinations suivantes :

• webhooks
• Azure Event Hubs

Étapes suivantes

• Remettre des événements aux points de terminaison de Webhook.