FAQ sur le protocole d'API REST Office 365 Message Trace

Quels sont les droits requis pour collecter les journaux à partir de l'API REST Office 365 Message Trace ?

Utilisez les autorisations d'application accordées à votre entité de service dans Microsoft Entra ID pour accéder aux données de traçage des messages dans Exchange Online. Pour plus d'informations, consultez : Autorisations de l'API Message Trace ( https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/graph-api-message-trace#permissions-required ).

Quelles sont les informations contenues dans les événements collectés par un protocole d'API REST de trace de message Microsoft Office 365 ?

Le protocole de l'API REST « Microsoft Message Trace » renvoie les informations de traçage d'un message électronique lors de son transit au sein de l'organisation Exchange Online. La fonctionnalité de suivi des messages permet aux administrateurs de tenant de suivre le cycle de vie d'un e-mail, de déterminer son statut de livraison (livré, en attente, échec ou en quarantaine) et de connaître les actions qui lui ont été appliquées. Pour chaque message, elle renvoie des champs tels que l'expéditeur, le destinataire, l'objet, la date et l'heure de réception, le statut et les événements de suivi associés au message

Pour obtenir la liste complète des champs disponibles, consultez la ressource « Message Trace » ( https://learn.microsoft.com/en-us/graph/api/resources/exchangemessagetrace?view=graph-rest-1.0 ).

A quoi sert l'option de retardement des événements ?

L'option de retardement des événements est utilisée pour éviter que des événements ne soient manquants. Les événements manqués, dans ce contexte, se produisent parce qu'ils deviennent disponibles après que le protocole a mis à jour sa plage de requêtes à une période plus récente que l'heure d'arrivée de l'événement. Si un événement s'est produit mais n'a pas été publié via l'API REST Microsoft Message Trace, le protocole ne parvient pas à récupérer cet événement lorsqu'il interroge l'API pour connaître l'heure de création de cet événement.

Exemple 1 : l'exemple suivant montre comment un événement peut être perdu.

Le protocole interroge l'API Microsoft Message Trace à 14 h afin de collecter les événements survenus entre 13 h et 13 h 59. La réponse de l'API Microsoft Message Trace renvoie les événements disponibles dans l'API Microsoft Message Trace entre 13 h 00 et 13 h 59. Le protocole fonctionne comme si tous les événements étaient d'abord collectés, puis envoie la requête suivante à l'API Microsoft Message Trace à 15 h afin de récupérer les événements survenus entre 13 h 45 et 14 h 59. Le problème avec ce scénario est que l'API Microsoft Message Trace pourrait ne pas inclure tous les événements qui se sont produits entre 13 h 00 et 13 h 59. Si un événement s'est produit à 13 h 58, il se peut qu'il ne soit disponible dans l'API Microsoft Message Trace qu'à partir de 14 h 03. Cependant, le protocole a déjà interrogé la plage horaire de 13h00 à 13h59 et ne peut pas réinterroger cette plage sans obtenir d'événements dupliqués. Ce délai peut varier entre 1 minute et 24 heures.

Exemple 2 : l'exemple suivant montre l'exemple 1, sauf que dans ce scénario un délai de 15 minutes est ajouté.

Cet exemple utilise un délai de 15 minutes lorsque le protocole effectue des appels de requête. Lorsque le protocole envoie une requête à l'API Microsoft Message Trace à 14 h, il recueille les événements survenus entre 13 h et 13 h 45. Le protocole fonctionne comme si tous les événements avaient été collectés : il envoie la requête suivante à l'API Microsoft Message Trace à 15 h et collecte tous les événements survenus entre 13 h 45 et 14 h 45. Au lieu de manquer l'événement, comme dans l'exemple 1, il est récupéré dans l'appel de requête suivant entre 13h45 et 14h45.

Exemple 3 : l'exemple suivant montre l'exemple 2, sauf que dans ce scénario les événements sont disponibles un jour plus tard.

Si l'événement s'est produit à 13 h 58, mais qu'il n'a été mis à la disposition de l'API Microsoft Message Trace qu'à 13 h 57 le lendemain, le délai d'événement décrit dans l'exemple 2 ne prendra plus en compte cet événement. Au lieu de cela, le délai d'événement doit être défini sur une valeur plus élevée, dans ce cas 24 heures.

Comment fonctionne l'option de retardement des événements ?

Au lieu d'interroger entre l'heure du dernier événement reçu et l'heure actuelle, le protocole interroge entre l'heure du dernier événement reçu et l'heure actuelle - <délai d'événement>. Le délai d'événement est exprimé en secondes. Par exemple, un délai de 15 minutes (900 secondes) signifie une interrogation jusqu'à 15 minutes plus tôt. Cette requête accorde à l'API Microsoft Message Trace un délai de 15 minutes pour rendre un événement disponible avant que celui-ci ne soit perdu. Lorsque l'écart entre l 'heure actuelle et < event delay > est inférieur à l 'heure du dernier événement reçu, le protocole n'interroge pas l'API Microsoft Message Trace; il attend que cette condition disparaisse avant de procéder à l'interrogation.

Quelle valeur dois-je utiliser pour l'option de retardement des événements ?

L'API Message Trace de Microsoft peut retarder la disponibilité de l'événement jusqu'à 24 heures. Pour éviter que des événements ne soient manqués, la valeur de l'option de paramètre Retardement des événements peut être définie sur 24 heures. Cependant, plus le délai d'événement est important, moins les résultats sont en temps réel. Avec un délai d'événement de 24 heures, vous ne voyez les événements que 24 heures après leur apparition. La valeur dépend du niveau de risque que vous êtes prêt à prendre et de l'importance des données en temps réel. Ce délai par défaut de 15 minutes fournit une valeur qui est définie en temps réel et empêche également la plupart des événements d'être manqués.

Pour plus d'informations sur la fonctionnalité de traçage des messages, notamment les questions fréquemment posées par les utilisateurs, les scénarios de dépannage et le comportement des données, consultez la FAQ sur le traçage des messages Microsoft ( https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/message-trace-FAQ ).