Fehlerbehebung bei Push-Benachrichtigungen

improve this page | report issue

Übersicht

Hier finden Sie Informationen, die Ihnen bei der Lösung von Problemen helfen, die bei Verwendung des Push-Service der Mobile Foundation auftreten können.

Wie verhält sich der Push-Service in verschiedenen Situationen mit fehlgeschlagener Zustellung von Benachrichtigungen?

GCM
  • Wenn die Antwort von GCM "Internal Server Error" oder "GCM Service is unavialable" lautet, wird versucht, die Benachrichtigung erneut zu senden. Die Häufigkeit der Sendungswiederholungen richtet sich nach dem Wert von "Retry-After".
  • Wenn GCM nicht erreichbar ist, wird ein Fehler in der Datei trace.log ausgegeben und das Senden der Nachricht nicht wiederholt.
  • Wenn GCM erreichbar ist, aber Fehler festgestellt wurden:
    • Not registered / Invalid ID / Mismatch ID / Registration missing: Diese Fehler gehen wahrscheinlich auf eine ungültige Nutzung der Geräte-ID oder eine ungültige Registrierung der App in GCM zurück. Die Geräte-ID wird aus der Datenbank gelöscht, um veraltete Daten in der Datenbank zu vermeiden. Die Benachrichtigung wird nicht erneut gesendet.
    • The message is too big: Das Senden der Nachricht wird nicht erneut versucht und in der Datei trace.log wird ein Protokoll erfasst.
    • Error Code 401: Dieser Fehler ist wahrscheinlich auf einen Authentifizierungsfehler zurückzuführen. Das Senden der Nachricht wird nicht erneut versucht. In der Datei trace.log wird ein Protokoll erfasst.
    • Error Code 400 / Error Code 403: Das Senden der Nachricht wird nicht erneut versucht und in der Datei trace.log wird ein Protokoll erfasst.
APNS

Wenn die APNS-Verbindung geschlossen ist, wird ein Wiederholungsversuch unternommen. Es wird dreimal versucht, eine Verbindung zum APNS herzustellen. In anderen Fällen wird kein Wiederholungsversuch unternommen.

Fehler mit Bezug zu "apns-environment" in Xcode werden gemeldet

Vergewissern Sie sich, dass im Bereitstellungsprofil, das zum Signieren der Anwendung verwendet wird, die Push-Funktionalität aktiviert ist. Sie können dies im Apple Developer Portal auf der Seite mit den Einstellungen für die App-ID überprüfen.

Java-Socket-Ausnahmen in den Protokollen, wenn APNS-Benachrichtigungen gesendet werden und das Gerät nie erreichen

Der APNS erfordert persistente Socket-Verbindungen zwischen dem MobileFirst Server und dem APNS. Der Push-Service setzt voraus, dass es ein offenes Socket gibt, und versucht, die Benachrichtigung zu senden. In vielen Fällen kann die Firewall eines Kunden jedoch so konfiguriert werden, dass nicht verwendete Sockets geschlossen werden (weil der Push-Service möglicherweise nicht häufig genutzt wird). Solche abrupten Socket-Schließungen können von keinem der Endpunkte gefunden werden, da bei normalen Socket-Schließungen der eine Endpunkt das Signal sendet und der andere Endpunkt das Signal bestätigt. Wenn das Senden mittels Push-Service über ein geschlossenes Socket versucht wird, sehen Sie Socket-Ausnahmen in den Protokollen.

Sie können dieses Problem vermeiden, indem Sie sicherstellen, dass keine APNS-Sockets von Firewallregeln geschlossen werden, oder indem Sie die JNDI-Eigenschaft push.apns.connectionIdleTimeout des Push-Service verwenden. Wenn Sie diese Eigenschaft konfigurieren, schließt der Server das für APNS-Push-Benachrichtigungen verwendete Socket ordnungsgemäß innerhalb eines bestimmten Zeitlimits (das kürzer als das Firewallzeitlimit für Sockets ist). Auf diese Weise kann ein Kunde Sockets schließen, bevor sie von der Firewall abrupt abgeschaltet werden.

SOCKS-bezogene Fehler beim Senden einer Push-Benachrichtigung an iOS-Geräte

Beispiel:

java.net.SocketException: Malformed reply from SOCKS server at java.net.SocksSocketImpl.readSocksReply(SocksSocketImpl.java
APNS-Benachrichtigungen werden über TCP-Sockets gesendet. Dies führt zu der Einschränkung, dass der für APNS-Benachrichtigungen verwendete Proxy TCP-Sockets unterstützen muss. Ein normaler HTTP-Proxy (der für GCM funktioniert) reicht hier nicht aus. Aus diesem Grund ist der einzige für APNS-Benachrichtigungen unterstützte Proxy ein SOCKS-Proxy. Version 4 oder 5 des SOCKS-Protokolls wird unterstützt. Die Ausnahme wird ausgelöst, wenn JNDI-Eigenschaften für die Übertragung von APNS-Benachrichtigungen über einen SOCKS-Proxy konfiguriert sind, der Proxy selbst jedoch nicht konfiguriert oder offline bzw. nicht verfügbar ist oder den Datenverkehr blockiert. Ein Kunde muss prüfen, ob sein SOCKS-Proxy verfügbar ist und funktioniert.

Eine gesendete Benachrichtigung erreicht nie das Gerät

Benachrichtigungen können sofort oder verzögert gesendet werden. Die Verzögerung kann einige Sekunden bis ein paar Minuten betragen. Es gibt verschiedene Aspekte, die zu berücksichtigen sind:

  • MobileFirst Server hat keine Kontrolle über die Benachrichtigung, sobald diese den Mediatorservice erreicht hat.
  • Der Netz- oder Onlinestatus des Geräts (Gerät ein- oder ausgeschaltet) muss berücksichtigt werden.
  • Es muss geprüft werden, ob Firewalls oder Proxys verwendet werden. Ist das der Fall, dürfen diese nicht so konfiguriert sein, dass sie die Kommunikation mit dem Mediator blockieren.
  • In der Firewall dürfen für die GCM/APNS/WNS-Mediatoren keine ausgewählten IP-Adressen in Whitelists aufgenommen werden, anstatt die tatsächlichen Mediatoren-URLs zu verwenden. Dies kann zu Problemen führen, weil eine Mediator-URL in eine beliebige IP-Adresse aufgelöst werden kann. Kunden sollten den Zugriff auf die URL und nicht auf die IP-Adresse zulassen. Es ist zu beachten, dass bei Sicherstellung der Konnektivität mittels telnet-Übertragung an die Mediator-URL nicht alle Aspekte abgedeckt sind. Insbesondere unter iOS ist dies nur ein Beweis für eine funktionierende abgehende Verbindung. Der eigentliche Sendevorgang erfolgt über TCP-Sockets, die telnet nicht garantieren kann. Wenn nur bestimmte IP-Adressen zugelassen werden, kann bei Verwendung von GCM beispielsweise folgender Fehler auftreten:
    Caused by: java.net.UnknownHostException:android.googleapis.com:android.googleapis.com: Name or service not known.

Unter iOS erreichen nicht alle Benachrichtigungen das Gerät

Apple definiert in seinen Richtlinien für Servicequalität so genannte kombinierte Benachrichtigungen (coalescing notifications). Dies bedeutet, dass der APNS-Server nur eine Benachrichtigung aufbewahrt, wenn eine sofortige Zustellung an ein (über ein Token identifiziertes) Gerät nicht möglich ist. Beispiel: Es gibt fünf Benachrichtigungen, die nacheinander gesendet werden. Wenn sich das Gerät in einem unzuverlässigen Netz befindet, sodass nur die erste Benachrichtigung zugestellt werden kann, wird die zweite vom APNS-Server vorübergehend gespeichert. In der Zwischenzeit wurde die dritte Benachrichtigung gesendet und hat den APNS-Server erreicht. Jetzt wird die frühere (noch nicht versendete) zweite Benachrichtigung gelöscht und die dritte (zuletzt eingegangene) Benachrichtigung gespeichert. Für den Endbenutzer bedeutet dies, das Benachrichtigungen fehlen.

Unter Android sind Benachrichtigungen nur verfügbar, wenn die App aktiv ist und im Vordergrund angezeigt wird

... Wenn die Anwendung nicht oder im Hintergrund ausgeführt wird, wird die Anwendung nicht durch das Antippen der Benachrichtigung im Benachrichtigungsbereich gestartet. Dies kann daran liegen, dass der Wert des Feldes app_name in der Datei strings.xml in einen angepassten Namen geändert wurde. Dies hat eine Diskrepanz beim Anwendungsnamen und bei der in der Datei AndroidManifest.xml definierten beabsichtigten Aktion zur Folge. Falls ein anderer Name für die Anwendung erforderlich ist, sollte stattdessen das Feld app_label verwendet werden. Sie können auch angepasste Definitionen in der Datei strings.xml verwenden.

SSLHandshakeExceptions beim Senden von Push-Benachrichtigungen an den APNS

Beispiel:

ApnsConnection | com.ibm.mfp.push.server.notification.apns.Apns.Connectionlmpl sendMessage Failed to send message Message (Id=1; Token=xxxx; Payload={"payload":{"\nid\":\"44b7f47\",\"tag\":\"Push.ALL\"}", "aps":{"alert":{"action-loc-key":null,"body":"TEST"}}})... trying again after delay javax.net.ssl.SSLHandshakeException:Received fatal alert: handshake_failure

Das Problem zeigt sich nur, wenn JVMs mit IBM JDK 1.8 verwendet werden. Die Lösung besteht in einem Upgrade von IBM JDK 1.8 auf Version 8.0.3.11 oder eine aktuellere Version.

Push-Service wird in der MobileFirst Operations Console als inaktiv angezeigt

Der Push-Service wird als inaktiv angezeigt, obwohl sie zugehörige WAR-Datei implementiert ist und die Eigenschaften mfp.admin.push.url, mfp.push.authorization.server.url und secret ordnungsgemäß in der Datei server.xml konfiguriert sind.

Stellen Sie sicher, dass die JNDI-Eigenschaften des Servers für den MFP-Verwaltungsservice ordnungsgemäß festgelegt sind. Es sollte beispielsweise Folgendes definiert sein:

<jndiEntry jndiName="mfpadmin/mfp.admin.push.url" value='"http://localhost:9080/imfpush"'/>
<jndiEntry jndiName="mfpadmin/mfp.admin.authorization.server.url" value='"http://localhost:9080/mfp"'/>
<jndiEntry jndiName="mfpadmin/mfp.push.authorization.client.id" value='"push-client-id"'/>
<jndiEntry jndiName="mfpadmin/mfp.push.authorization.client.secret" value='"pushSecret"'/>
<jndiEntry jndiName="mfpadmin/mfp.admin.authorization.client.id" value='"admin-client-id"'/>
<jndiEntry jndiName="mfpadmin/mfp.admin.authorization.client.secret" value='"adminSecret"'/>
<jndiEntry jndiName="mfpadmin/mfp.config.service.password" value='"{xor}DCs+LStubWw="'/>
<jndiEntry jndiName="mfpadmin/mfp.config.service.user" value='"configUser"'/>
Last modified on April 09, 2018