Diagnostiquer les problèmes de perte des notifications dans Azure Notification Hubs
L’une des questions les plus fréquentes concernant Azure Notification Hubs concerne les notifications qui sont envoyées à partir d’une application et qui n’apparaissent pas sur les appareils clients. Les clients veulent savoir où se trouvent ces notifications, pourquoi elles se sont perdues et comment résoudre ce problème. Cet article explique les raisons pour lesquelles les notifications peuvent être perdues ou ne pas apparaître sur les appareils. Il indique également comment déterminer la cause racine du problème.
En premier lieu, il est essentiel de comprendre la manière dont Notification Hubs envoie (push) les notifications vers un appareil.
Dans un flux de notification d’envoi type, le message est envoyé par le serveur d’applications backend à Notification Hubs. Notification Hubs traite toutes les inscriptions. Il prend en compte les balises configurées et les expressions de balise pour déterminer les cibles. Les cibles correspondent à toutes les inscriptions qui doivent recevoir la notification Push. Ces inscriptions peuvent couvrir n’importe lesquelles de nos plateformes prises en charge : Android, Baidu (appareils Android en Chine), Fire OS (Amazon) iOS, Windows et Windows Phone.
Une fois les cibles établies, Notification Hubs envoie (push) des notifications au service de notifications Push correspondant à la plateforme de l’appareil. Il peut s’agir, par exemple, d’Apple Push Notification Service (APNs) pour iOS et macOS ou de Firebase Cloud Messaging (FCM) pour les appareils Android. Notification Hubs envoie les notifications regroupées en plusieurs lots d’inscriptions. Il s’authentifie auprès du service de notifications Push correspondant, en fonction des informations d’identification que vous avez définies dans le Portail Azure, sous Configurer un hub de notification. Le service de notifications Push transmet alors les notifications aux appareils clients correspondants.
Le dernier tronçon de remise des notifications se situe entre le service de notifications Push de la plateforme et l’appareil. La remise des notifications peut échouer lors de l’une des quatre phases du processus de notifications Push (client, serveur d’applications principal, Notification Hubs et service de notifications Push de la plateforme). Pour plus d’informations sur l’architecture de Notification Hubs, consultez Présentation de Notification Hubs.
L’échec de la remise des notifications peut se produire lors de la phase de test ou de préproduction initiale. À ce stade, la perte des notifications peut indiquer un problème de configuration. Si un échec de remise des notifications se produit lors de la phase de production, il se peut qu’une partie ou la totalité des notifications soient perdues. Cela indique un problème plus complexe lié à l’application ou au type de messagerie.
La section ci-après présente les scénarios, des plus courants aux plus rares, dans lesquels les notifications peuvent être perdues.
Configuration incorrecte de Notification Hubs
Pour envoyer des notifications au service de notifications Push adapté, Notification Hubs doit s’authentifier dans le contexte de votre application. Vous devez créer un compte de développeur avec le service de notification de la plateforme cible (Microsoft, Apple, Google, etc.). Ensuite, vous devez inscrire votre application auprès du système d’exploitation, grâce auquel vous obtenez un jeton ou une clé qui vous permet de travailler avec le PNS (Platform Notification System) cible.
Vous devez ajouter ces informations d’identification de plateforme dans le portail Azure. Si aucune notification n’arrive sur l’appareil, la première chose à faire consiste à vérifier que les informations d’identification configurées dans Notification Hubs sont correctes. Les informations d’identification doivent correspondre à celles de l’application qui a été créée sous un compte de développeur propre à la plateforme.
Pour obtenir des instructions pas à pas pour ce processus, consultez Bien démarrer avec Azure Notification Hubs.
Voici certaines erreurs de configuration courantes :
Emplacement du nom du hub de notification
Vérifiez que le nom de votre hub de notification (sans fautes de frappe) est le même dans chacun de ces emplacements :
- Là où vous vous êtes inscrit auprès du client
- Là où vous envoyez des notifications à partir du serveur principal
- Là où vous avez configuré les informations d’identification du service de notifications Push
Vérifiez que vous utilisez les chaînes de configuration de signature d’accès partagé correctes sur le client et sur le serveur d’applications principal. En règle générale, vous devez utiliser DefaultListenSharedAccessSignature sur le client et DefaultFullSharedAccessSignature sur le serveur d’applications principal. Cette opération autorise l’envoi de notifications à Notification Hubs.
Configuration du nom du point d’accès (APN)
Vous devez disposer de deux hubs différents : l’un pour la production, et l’autre pour les tests. Vous devez charger le certificat que vous utilisez dans un environnement de bac à sable dans un hub différent du certificat/hub que vous utiliserez en production. N’essayez pas de charger plusieurs types de certificats dans un même hub. Cela entraînerait l’échec de la remise des notifications.
Si vous chargez par inadvertance plusieurs types de certificats dans un même hub, supprimez ce dernier et créez-en un autre. Si vous ne pouvez pas supprimer le hub pour une raison quelconque, vous devez au moins supprimer toutes les inscriptions effectuées auprès de ce hub.
Configuration de Firebase Cloud Messaging (FCM)
Remarque
Pour plus d’informations sur les étapes de dépréciation et de migration de Firebase Cloud Messaging, consultez Migration de Google Firebase Cloud Messaging.
Vérifiez que la clé serveur que vous avez obtenue auprès de Firebase correspond à celle que vous avez inscrite dans le Portail Azure.
Vérifiez que vous avez configuré l’ID de projet dans le client. La valeur de l’ID de projet se trouve dans le tableau de bord Firebase.
Problèmes de l’application
Balises et expressions de balise
Si vous utilisez des balises ou des expressions de balise pour segmenter votre public, il est possible qu’aucune cible ne soit trouvée lorsque vous envoyez la notification. Cette erreur repose sur les balises ou expressions de balise que vous spécifiez dans votre appel d’envoi.
Lorsque vous envoyez une notification, examinez vos inscriptions pour vérifier que les balises correspondent. Ensuite, vérifiez uniquement l’accusé de réception des clients qui disposent de ces inscriptions.
Par exemple, supposons que toutes vos inscriptions auprès de Notification Hubs utilisent la balise « Politique ». Si vous envoyez par la suite une notification avec la balise « Sports », la notification ne sera envoyée à aucun appareil. Un cas complexe peut impliquer des expressions de balise où vous êtes inscrit à l’aide de « Tag A » ou de « Tag B », mais vous avez ciblé « Tag A && Tag B ». La section conseils de diagnostic automatique plus loin dans l’article vous montre comment passer en revue vos inscriptions et leurs étiquettes.
Problèmes liés aux modèles
Si vous utilisez des modèles, suivez bien les instructions décrites dans la section Modèles.
Inscriptions non valides
Si le hub de notification a été configuré de manière adéquate, et que les balises ou expressions de balise ont été correctement utilisées, des cibles valides sont trouvées. Les notifications doivent être envoyées à ces cibles. Notification Hubs déclenche ensuite plusieurs traitements en parallèle. Chaque lot envoie des messages à un ensemble d’inscriptions.
Notes
Étant donné que Notification Hubs traite plusieurs lots en parallèle, l’ordre dans lequel les notifications sont remises n’est pas garanti.
Notification Hubs est optimisé pour le modèle de remise de messages de type « une fois maximum ». Nous tentons une déduplication de sorte qu’aucune notification ne soit remise plus d’une fois au même périphérique. Le processus contrôle les inscriptions pour vérifier qu’un seul message est envoyé par identificateur d’appareil avant son envoi au service de notifications Push.
Chaque lot est envoyé au service de notifications Push qui, à son tour, accepte et valide les inscriptions. Au cours de ce processus, il est possible que le service de notifications Push détecte une erreur au niveau d’une ou de plusieurs inscriptions dans un lot. Le service de notifications Push renvoie alors une erreur à Notification Hubs, et le processus s’arrête. Le service de notifications Push abandonne alors l’intégralité du lot. Cela est particulièrement vrai pour Apple Push Notification Service (APNs), qui utilise un protocole de flux TCP.
Dans ce cas, l’inscription défaillante est supprimée de la base de données. Ensuite, la remise des notifications est retentée pour les appareils restants du lot.
Pour plus d’informations sur les erreurs concernant l’échec de tentative de remise pour une inscription, vous pouvez utiliser les API REST de Notification Hubs Per Message Telemetry: Get Notification message telemetry (Télémétrie par message : télémétrie d’obtention de messages de notification) et PNS feedback (Commentaires du service de notifications Push). Pour obtenir un exemple de code, consultez l’exemple d’API REST d’envoi.
Problèmes liés au service de notifications Push
Une fois que le service de notifications Push a reçu la notification, il remet la notification à l’appareil. À ce stade, Notification Hubs n’a aucun contrôle sur la remise de la notification à l’appareil.
Les services de notifications de plateforme étant très performants, les notifications arrivent généralement sur les appareils en quelques secondes. Si le service de notifications Push est soumis à une limitation, Notification Hubs applique une stratégie d’interruption exponentielle. Si le service de notifications Push reste inaccessible pendant 30 minutes, l’une des stratégies mises en place consiste à faire expirer et supprimer définitivement ces messages.
Si un service de notifications Push tente de remettre une notification alors que l’appareil est hors connexion, la notification est stockée par le service pendant une période limitée. La notification est envoyée à l’appareil lorsque celui-ci est de nouveau disponible.
Chaque application ne stocke qu’une seule notification récente. Si plusieurs notifications sont envoyées pendant qu’un appareil se trouve hors connexion, chaque nouvelle notification provoque la suppression de la précédente. La conservation de la dernière notification uniquement est appelée fusion des notifications dans APNs et réduction dans FCM. (FCM utilise une clé de réduction.) Lorsque l’appareil reste hors connexion pendant une longue période, les notifications qui étaient stockées pour l’appareil sont supprimées. Pour plus d’informations, consultez les articles APNs Overview (Présentation d’Apple Push Notification Service) et About FCM messages (À propos des messages Firebase Cloud Messaging).
Avec Notification Hubs, vous pouvez transmettre une clé de fusion par le biais d’un en-tête HTTP à l’aide de l’API SendNotification générique. Par exemple, pour le SDK .NET, vous devez utiliser SendNotificationAsync. L’API SendNotification accepte également les en-têtes HTTP qui sont transmis tels quels au service de notifications Push correspondant.
Conseils d’autodiagnostic
Vous trouverez ci-après différentes méthodes permettant de déterminer la cause racine des pertes de notifications dans Notification Hubs.
Vérification des informations d’identification
Portail des développeurs du service de notifications Push
Vérifiez les informations d’identification dans le portail des développeurs du service de notifications Push correspondant (Apple Push Notification Service, Firebase Cloud Messaging, service de notification Windows, etc.). Pour plus d’informations, consultez Tutoriel : Envoyer des notifications vers des applications de plateforme Windows universelle à l’aide d’Azure Notification Hubs.
Portail Azure
Pour vérifier et comparer les informations d’identification avec celles que vous avez obtenues par le biais du portail des développeurs du service de notifications Push, dans le Portail Azure, accédez à l’onglet Stratégies d’accès.
Vérification des inscriptions
Visual Studio
Dans Visual Studio, vous pouvez vous connecter à Azure par l’intermédiaire de l’Explorateur de serveurs pour afficher et gérer un ensemble de services Azure, y compris Notifications Hubs. Ce raccourci est particulièrement utile pour votre environnement de développement et de test.
Vous pouvez visualiser et gérer toutes les inscriptions de votre hub. Les inscriptions peuvent être classées par plateforme, par type (native ou basée sur un modèle), par balise, par identificateur de service de notifications Push, par ID d’inscription et par date d’expiration. Dans cette page, vous pouvez également modifier une inscription. Cette fonctionnalité est particulièrement utile pour la modification des balises.
Dans l’Explorateur de serveurs, cliquez avec le bouton droit sur votre hub de notification, puis sélectionnez Diagnostiquer.
La page ci-après apparaît :
Basculez vers la page Inscriptions d’appareil :
Vous pouvez utiliser la page Test d’envoi pour envoyer un message de notification de test :
Remarque
Utilisez Visual Studio pour modifier les inscriptions uniquement pendant les phases de développement ou de test, et avec un nombre limité d’inscriptions. Si vous avez besoin de modifier vos inscriptions en bloc, utilisez la fonctionnalité d’exportation et d’importation des inscriptions décrite dans Guide pratique pour exporter et modifier des inscriptions en bloc.
Explorateur Service Bus
De nombreux clients utilisent Service Bus Explorer pour afficher et gérer leurs hubs de notification. Service Bus Explorer est un projet open source.
Vérification des notifications de messages
Portail Azure
Pour envoyer une notification de test à vos clients sans backend de service opérationnel, sous Support + dépannage, sélectionnez Envoi de test.
Visual Studio
Vous pouvez également envoyer des notifications de test à partir de Visual Studio.
Résoudre les échecs de remise de notification et analyser les résultats des notifications
Propriété EnableTestSend
Lorsque vous envoyez une notification par le biais de Notification Hubs, la notification est d’abord mise en file d’attente. Notification Hubs détermine les cibles qui conviennent, puis envoie la notification au service de notifications Push. Si vous utilisez l’API REST ou l’un des Kits de développement logiciel (SDK) clients, le renvoi de votre appel d’envoi signifie uniquement que le message est placé dans la file d’attente de Notification Hubs. Ce renvoi ne fournit aucun insight sur ce qui s’est passé lorsque Notification Hubs a finalement envoyé la notification au service de notifications Push.
Si votre notification n’arrive pas jusqu’à l’appareil client, une erreur s’est peut-être produite au moment où Notification Hubs a tenté de remettre la notification au service de notifications Push. Par exemple, la taille de la charge utile peut dépasser le seuil maximal autorisé par le service de notifications Push, ou les informations d’identification configurées dans Notification Hubs peuvent ne pas être valides.
Pour comprendre ce qu’il s’est passé lors d’une erreur du service de notifications Push, vous pouvez utiliser la propriété EnableTestSend. Cette propriété est activée automatiquement lorsque vous envoyez des messages de test à partir du portail ou du client Visual Studio. Vous pouvez visualiser des informations de débogage détaillées à l’aide de cette propriété, ainsi que par le biais des API. Actuellement, vous pouvez l’utiliser dans le SDK .NET. Il est prévu que cette propriété soit ajoutée à tous les Kits de développement logiciel (SDK) clients.
Pour utiliser la propriété EnableTestSend avec l’appel REST, ajoutez un paramètre de chaîne de requête appelé test à la fin de votre appel d’envoi. Par exemple :
https://mynamespace.servicebus.windows.net/mynotificationhub/messages?api-version=2013-10&test
Exemple de Kit de développement logiciel (SDK) .NET
Voici un exemple d’utilisation du SDK .NET pour envoyer une notification (toast) sous forme de fenêtre contextuelle native :
NotificationHubClient hub = NotificationHubClient.CreateClientFromConnectionString(connString, hubName);
var result = await hub.SendWindowsNativeNotificationAsync(toast);
Console.WriteLine(result.State);
À la fin de l’exécution, result.State indique seulement la valeur Enqueued. Les résultats ne fournissent aucun insight sur ce qui est arrivé à votre notification Push.
Ensuite, vous pouvez utiliser la propriété booléenne EnableTestSend. Utilisez la propriété EnableTestSend quand vous initialisez NotificationHubClient pour obtenir des informations détaillées sur les erreurs du service de notifications Push qui se produisent lors de l’envoi de la notification. Le retour de l’appel d’envoi nécessite davantage de temps, car cet appel doit attendre que Notification Hubs ait remis la notification au service de notifications Push.
bool enableTestSend = true;
NotificationHubClient hub = NotificationHubClient.CreateClientFromConnectionString(connString, hubName, enableTestSend);
var outcome = await hub.SendWindowsNativeNotificationAsync(toast);
Console.WriteLine(outcome.State);
foreach (RegistrationResult result in outcome.Results)
{
Console.WriteLine(result.ApplicationPlatform + "\n" + result.RegistrationId + "\n" + result.Outcome);
}
Exemple de sortie
DetailedStateAvailable
windows
7619785862101227384-7840974832647865618-3
The Token obtained from the Token Provider is wrong
Ce message indique que les informations d’identification configurées dans Notification Hubs ne sont pas valides, ou qu’il existe un problème avec les inscriptions dans le hub. Supprimez cette inscription et laissez le client la recréer avant d’envoyer le message.
Notes
L’utilisation de la propriété EnableTestSend entraîne une limitation importante. Utilisez cette option uniquement dans un environnement de développement et de test, et avec un ensemble limité d’inscriptions. Les notifications de débogage sont envoyées à un maximum de 10 appareils. En outre, le traitement des envois de débogage est limité à 10 envois par minute. Les notifications de débogage sont également exclues du contrat de niveau de service Microsoft Azure Notification Hubs.
Révision de la télémétrie
Portail Azure
Le portail vous permet d’obtenir un aperçu rapide de toutes les activités sur votre hub de notification.
Sous l’onglet Vue d’ensemble, vous pouvez voir les inscriptions, les notifications et les erreurs regroupées par plateforme.
Sous l’onglet Journal d’activité, vous pouvez ajouter d’autres métriques relatives à la plateforme pour une vue approfondie. Vous pouvez ainsi obtenir des informations plus précises sur les erreurs qui sont renvoyées lorsque Notification Hubs tente d’envoyer la notification au service de notifications Push.
Sous l’onglet Vue d’ensemble, commencez par consulter les Messages entrants, les Opérations d’inscription et les Notifications réussies. Accédez ensuite à l’onglet de la plateforme pour examiner les erreurs relatives à ce service de notifications Push.
Si les paramètres d’authentification du hub de notification sont incorrects, le message Erreur d’authentification PNS s’affiche. Ce message indique qu’il est nécessaire de vérifier les informations d’identification du service de notifications Push.
Accès par programme
Pour plus d’informations sur l’accès par programmation, consultez l’article Accès par programme.
Notes
Plusieurs fonctionnalités de télémétrie, comme l’exportation et l’importation des inscriptions, et l’accès à la télémétrie via des API, sont disponibles uniquement avec le niveau de service Standard. Si vous essayez d’utiliser ces fonctionnalités à partir du niveau de service Gratuit ou De base, vous obtiendrez un message d’exception en cas d’utilisation du Kit de développement logiciel (SDK). Si vous utilisez les fonctionnalités directement à partir des API REST, vous obtiendrez une erreur HTTP 403 (Interdit).
Pour utiliser les fonctionnalités de télémétrie, commencez par vérifier dans le Portail Azure que vous utilisez le niveau de service Standard.