Diagnostisera borttagna meddelanden i Azure Notification Hubs

En vanlig fråga om Azure Notification Hubs är hur du felsöker när meddelanden från ett program inte visas på klientenheter. Kunder vill veta var och varför meddelanden har tagits bort och hur problemet kan åtgärdas. Den här artikeln identifierar varför meddelanden kan komma att tas bort eller inte tas emot av enheter. Den förklarar också hur du fastställer rotorsaken.

Det är viktigt att först förstå hur Notification Hubs skickar meddelanden till en enhet.

I ett vanligt flöde för att skicka meddelanden skickas meddelandet från programmets serverdel till Notification Hubs. Notification Hubs bearbetar alla registreringar. Den tar hänsyn till de konfigurerade taggarna och tagguttrycken för att fastställa mål. Målen är de registreringar som måste ta emot push-meddelandet. Dessa registreringar kan omfatta alla våra plattformar som stöds: Android, Baidu (Android-enheter i Kina), Fire OS (Amazon) iOS, Windows och Windows Telefon.

När målen har upprättats skickar Notification Hubs meddelanden till push-meddelandetjänsten för enhetsplattformen. Exempel är Apple Push Notification Service (APN) för iOS och macOS och Firebase Cloud Messaging (FCM) för Android-enheter. Notification Hubs skickar meddelanden som delas upp i flera batchar med registreringar. Den autentiserar med respektive push-meddelandetjänst, baserat på de autentiseringsuppgifter som du angav i Azure-portalen, under Konfigurera Meddelandehubb. Push-meddelandetjänsten vidarebefordrar sedan meddelandena till respektive klientenheter.

Den sista delen av meddelandeleveransen är mellan plattformens push-meddelandetjänst och enheten. Meddelandeleveransen kan misslyckas i någon av de fyra stegen i push-meddelandeprocessen (klient, programserverdel, Notification Hubs och plattformens push-meddelandetjänst). Mer information om Notification Hubs-arkitekturen finns i Översikt över Notification Hubs.

Det går inte att leverera meddelanden under den inledande test-/mellanlagringsfasen. Borttagna meddelanden i det här skedet kan tyda på ett konfigurationsproblem. Om det inte går att leverera meddelanden i produktion kan vissa eller alla meddelanden tas bort. Ett djupare problem med program- eller meddelandemönster anges i det här fallet.

I nästa avsnitt tittar vi på scenarier där meddelanden kan tas bort, allt från vanliga till sällsynta.

Felkonfiguration av Notification Hubs

För att skicka meddelanden till respektive push-meddelandetjänst måste Notification Hubs autentisera sig själv i kontexten för ditt program. Du måste skapa ett utvecklarkonto med målplattformens meddelandetjänst (Microsoft, Apple, Google osv.). Sedan måste du registrera ditt program med operativsystemet där du får en token eller nyckel som du använder för att arbeta med mål-PNS.

Du måste lägga till autentiseringsuppgifter för plattformen i Azure-portalen. Om inga meddelanden når enheten är det första steget att se till att rätt autentiseringsuppgifter har konfigurerats i Notification Hubs. Autentiseringsuppgifterna måste matcha programmet som skapas under ett plattformsspecifikt utvecklarkonto.

Stegvisa instruktioner för att slutföra den här processen finns i Komma igång med Azure Notification Hubs.

Här följer några vanliga felkonfigurationer att söka efter:

Plats för meddelandehubbens namn

Kontrollera att namnet på meddelandehubben (utan stavfel) är detsamma på var och en av dessa platser:

• Där du registrerar dig från klienten
• Var du skickar meddelanden från serverdelen
• Där du konfigurerade autentiseringsuppgifterna för push-meddelandetjänsten

Se till att du använder rätt konfigurationssträngar för signatur för delad åtkomst på klienten och programmets serverdel. I allmänhet måste du använda DefaultListenSharedAccessSignature på klienten och DefaultFullSharedAccessSignature på programmets serverdel. Detta ger behörighet att skicka meddelanden till Notification Hubs.

APN-konfiguration

Du måste underhålla två olika hubbar: en för produktion och en annan för testning. Du måste ladda upp certifikatet som du använder i en sandbox-miljö till en separat hubb än det certifikat/hubb som du ska använda i produktion. Försök inte ladda upp olika typer av certifikat till samma hubb. Det orsakar meddelandefel.

Om du oavsiktligt laddar upp olika typer av certifikat till samma hubb bör du ta bort hubben och börja om från början med en ny hubb. Om du av någon anledning inte kan ta bort hubben måste du åtminstone ta bort alla befintliga registreringar från hubben.

FCM-konfiguration

1. Kontrollera att servernyckeln som du hämtade från Firebase matchar den servernyckel som du registrerade i Azure-portalen.

   

2. Kontrollera att du har konfigurerat projekt-ID på klienten. Du kan hämta värdet för Project ID från Firebase-instrumentpanelen.

   

Programproblem

Taggar och tagguttryck

Om du använder taggar eller tagguttryck för att segmentera målgruppen är det möjligt att inget mål hittas när du skickar meddelandet. Det här felet baseras på de angivna taggarna eller tagguttrycken i ditt sändningsanrop.

Granska dina registreringar för att se till att taggarna matchar när du skickar ett meddelande. Verifiera sedan meddelandekvittot från endast de klienter som har dessa registreringar.

Anta till exempel att alla dina registreringar med Notification Hubs använder taggen "Politik". Om du sedan skickar ett meddelande med taggen "Sport" skickas inte meddelandet till någon enhet. Ett komplext fall kan omfatta tagguttryck där du registrerade med hjälp av "TaggA" eller "Tagg B", men du har riktat in dig på "TaggA & tagg B". Avsnittet tips för självdiagnos senare i artikeln visar hur du granskar dina registreringar och deras taggar.

Mallproblem

Om du använder mallar kontrollerar du att du följer riktlinjerna som beskrivs i Mallar.

Ogiltiga registreringar

Om meddelandehubben har konfigurerats korrekt och taggar eller tagguttryck har använts korrekt, hittas giltiga mål. Meddelanden ska skickas till dessa mål. Notification Hubs utlöser sedan flera bearbetningsbatch parallellt. Varje batch skickar meddelanden till en uppsättning registreringar.

Notification Hubs är optimerad för en "högst en gång"-modell för meddelandeleverans. Vi försöker deduplicering, så att inga meddelanden levereras mer än en gång till en enhet. Registreringar kontrolleras för att säkerställa att endast ett meddelande skickas per enhetsidentifierare innan det skickas till push-meddelandetjänsten.

Varje batch skickas till push-meddelandetjänsten, som i sin tur accepterar och validerar registreringarna. Under den här processen är det möjligt att push-meddelandetjänsten identifierar ett fel med en eller flera registreringar i en batch. Push-meddelandetjänsten returnerar sedan ett fel till Notification Hubs och processen stoppas. Push-meddelandetjänsten släpper batchen helt. Detta gäller särskilt för APN:er, som använder ett TCP-dataströmprotokoll.

I det här fallet tas den felaktiga registreringen bort från databasen. Sedan försöker vi skicka meddelanden igen för resten av enheterna i batchen.

Om du vill få mer felinformation om det misslyckade leveransförsöket mot en registrering kan du använda REST-API: erna för Notification Hubs per meddelandetelemetri: Hämta telemetri för meddelandemeddelanden och PNS-feedback. Exempelkod finns i exemplet Skicka REST.

Problem med push-meddelandetjänsten

När push-meddelandetjänsten har fått meddelandet levererar den meddelandet till enheten. Nu har Notification Hubs ingen kontroll över leveransen av meddelandet till enheten.

Eftersom plattformsmeddelandetjänsterna är robusta tenderar meddelanden att nå enheter på några sekunder. Om push-meddelandetjänsten begränsas tillämpar Notification Hubs en exponentiell back-off-strategi. Om push-meddelandetjänsten inte kan nås i 30 minuter finns det en princip för att upphöra att gälla och ta bort meddelandena permanent.

Om en push-meddelandetjänst försöker leverera ett meddelande men enheten är offline lagras meddelandet av push-meddelandetjänsten. Den lagras endast under en begränsad tidsperiod. Meddelandet levereras till enheten när enheten blir tillgänglig.

Varje app lagrar bara ett nytt meddelande. Om flera meddelanden skickas medan en enhet är offline, gör varje nytt meddelande att den sista ignoreras. Att bara behålla det senaste meddelandet kallas sammankoppling i APN:er och kollapsar i FCM. (FCM använder en komprimerande nyckel.) När enheten är offline under en längre tid ignoreras meddelanden som har lagrats för enheten. Mer information finns i ÖVERSIKT över API:er och Om FCM-meddelanden.

Med Notification Hubs kan du skicka en sammanslagningsnyckel via ett HTTP-huvud med hjälp av det generiska SendNotification-API:et. För .NET SDK använder du SendNotificationAsynctill exempel . Api:et SendNotification tar även HTTP-huvuden som skickas som till respektive push-meddelandetjänst.

Tips för självdiagnos

Här är sökvägar för att diagnostisera rotorsaken till borttagna meddelanden i Notification Hubs.

Verifiera autentiseringsuppgifter

Utvecklarportal för push-meddelandetjänst

Verifiera autentiseringsuppgifterna i respektive push-meddelandetjänstutvecklarportal (APNs, FCM, Windows Notification Service och så vidare). Mer information finns i Självstudie: Skicka meddelanden till Universell Windows-plattform appar med hjälp av Azure Notification Hubs.

Azure Portal

Om du vill granska och matcha autentiseringsuppgifterna med dem som du fick från push-meddelandetjänstens utvecklarportal går du till fliken Åtkomstprinciper i Azure-portalen.

Verifiera registreringar

Visual Studio

I Visual Studio kan du ansluta till Azure via Server Explorer för att visa och hantera flera Azure-tjänster, inklusive Notification Hubs. Den här genvägen är främst användbar för din utvecklings-/testmiljö.

Du kan visa och hantera alla registreringar i din hubb. Registreringarna kan kategoriseras efter plattforms-, intern- eller mallregistrering, tagg, push-meddelandetjänstidentifierare, registrerings-ID och förfallodatum. Du kan också redigera en registrering på den här sidan. Det är särskilt användbart för att redigera taggar.

Högerklicka på meddelandehubben i Server Explorer och välj Diagnostisera.

Du ser följande sida:

Växla till sidan Enhetsregistreringar :

Du kan använda sidan Skicka test för att skicka ett testmeddelande:

Service Bus Explorer

Många kunder använder Service Bus Explorer för att visa och hantera sina meddelandehubbar. Service Bus Explorer är ett projekt med öppen källkod.

Verifiera meddelandemeddelanden

Azure Portal

Om du vill skicka ett testmeddelande till dina klienter utan att en tjänst körs igen går du till SUPPORT + FELSÖKNING och väljer Testa skicka.

Visual Studio

Du kan också skicka testmeddelanden från Visual Studio.

Felsöka misslyckade meddelanden och granska meddelanderesultatet

Egenskapen EnableTestSend

När du skickar ett meddelande via Notification Hubs placeras meddelandet först i kö. Notification Hubs fastställer rätt mål och skickar sedan meddelandet till push-meddelandetjänsten. Om du använder REST-API:et eller någon av klient-SDK:erna innebär returen av ditt sändningsanrop endast att meddelandet placeras i kö med Notification Hubs. Den ger ingen insikt i vad som hände när Notification Hubs så småningom skickade meddelandet till push-meddelandetjänsten.

Om meddelandet inte kommer till klientenheten kan ett fel ha uppstått när Notification Hubs försökte leverera det till push-meddelandetjänsten. Till exempel kan nyttolaststorleken överskrida det högsta tillåtna värdet för push-meddelandetjänsten, eller så kan autentiseringsuppgifterna som konfigurerats i Notification Hubs vara ogiltiga.

Om du vill få insikter om fel i push-meddelandetjänsten kan du använda egenskapen EnableTestSend . Den här egenskapen aktiveras automatiskt när du skickar testmeddelanden från portalen eller Visual Studio-klienten. Du kan använda den här egenskapen för att se detaljerad felsökningsinformation och även via API:er. För närvarande kan du använda den i .NET SDK. Den läggs till i alla klient-SDK:er så småningom.

Om du vill använda EnableTestSend egenskapen med REST-anropet lägger du till en frågesträngsparameter med namnet test i slutet av ditt sändningsanrop. Till exempel:

https://mynamespace.servicebus.windows.net/mynotificationhub/messages?api-version=2013-10&test

.NET SDK-exempel

Här är ett exempel på hur du använder .NET SDK för att skicka ett inbyggt popup-meddelande (popup-meddelande):

NotificationHubClient hub = NotificationHubClient.CreateClientFromConnectionString(connString, hubName);
var result = await hub.SendWindowsNativeNotificationAsync(toast);
Console.WriteLine(result.State);

I slutet av körningen result.State anger Enqueueddu helt enkelt . Resultatet ger ingen insikt i vad som hände med push-meddelandet.

Sedan kan du använda den EnableTestSend booleska egenskapen. Använd egenskapen EnableTestSend när du initierar NotificationHubClient för att få en detaljerad status om push-meddelandetjänstfel som uppstår när meddelandet skickas. Sändningsanropet tar ytterligare tid att returnera eftersom det först behöver Notification Hubs för att leverera meddelandet till push-meddelandetjänsten.

    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);
    }

Exempelutdata

DetailedStateAvailable
windows
7619785862101227384-7840974832647865618-3
The Token obtained from the Token Provider is wrong

Det här meddelandet anger antingen att de autentiseringsuppgifter som konfigurerats i Notification Hubs är ogiltiga eller att det finns ett problem med registreringarna i hubben. Ta bort den här registreringen och låt klienten återskapa registreringen innan meddelandet skickas.

Granska telemetri

Azure Portal

I portalen kan du få en snabb översikt över all aktivitet i meddelandehubben.

1. På fliken Översikt kan du se en aggregerad vy över registreringar, meddelanden och fel per plattform.

   

2. På fliken Aktivitetslogg kan du lägga till andra plattformsspecifika mått för en djupare titt. Du kan titta specifikt på fel som returneras när Notification Hubs försöker skicka meddelandet till push-meddelandetjänsten.

   

3. På fliken Översikt börjar du med att granska inkommande meddelanden, registreringsåtgärder och lyckade meddelanden. Gå sedan till fliken per plattform för att granska fel som är specifika för push-meddelandetjänsten.

4. Om autentiseringsinställningarna för meddelandehubben är felaktiga visas meddelandet PNS-autentiseringsfel . Det är en bra indikation för att kontrollera autentiseringsuppgifterna för push-meddelandetjänsten.

Programmatisk åtkomst

Mer information om programmatisk åtkomst finns i Programmatisk åtkomst.