Traitement des incidents liés aux notifications push

• Si la réponse de GCM est "internal server error" (erreur de serveur interne) ou "GCM service is unavailable" (le service GCM n'est pas disponible), une nouvelle tentative d'envoi de la notification est effectuée. La fréquence des tentatives est déterminée en fonction de la valeur de "Retry-After".
• GCM n'est pas accessible : une erreur est indiquée dans le fichier trace.log et le message envoyé n'est pas renvoyé.
• GCM est accessible mais des échecs sont reçus
  • Non enregistré / ID non valide / ID non concordant / enregistrement manquant : utilisation non valide probable de l'ID d'appareil ou enregistrement non valide de l'application dans GCM. L'ID d'appareil est supprimé de la base de données afin d'éviter la présence de données périmées dans la base de données. La notification n'est pas renvoyée.
  • Le message est trop volumineux : aucune nouvelle tentative de renvoi du message n'est effectuée et un journal est enregistré dans le fichier trace.log.
  • Code d'erreur 401 : probablement dû à une erreur d'authentification, aucune nouvelle tentative de renvoi du message n'est effectuée et un journal est enregistré dans le fichier trace.log.
  • Code d'erreur 400 ou 403 : aucune nouvelle tentative de renvoi du message n'est effectuée et un journal est enregistré dans le fichier trace.log.

Dans le cas d'APNS, une tentative de renvoi est effectuée si la connexion APNS est fermée. Trois tentatives d'établissement de connexion avec APNS sont effectuées. Dans les autres cas, aucune nouvelle tentative d'envoi n'est effectuée.

Vérifiez que la fonction Push est activée dans le profil de mise à disposition employé pour la connexion aux applications. Vous pouvez vérifier ce paramètre dans la page des paramètres de l'ID d'appli dans le portail Apple Developer.

APNS requiert des connexions socket permanentes entre MobileFirst Server et le service APNS. Le service Push suppose qu'il existe un socket ouvert et essaie d'envoyer la notification. Il arrive cependant fréquemment qu'un pare-feu client soit configuré pour fermer les sockets non utilisés (le service n'est peut-être pas souvent utilisé). De telles fermetures brutales de socket sont introuvables par les points de terminaison car les sockets se ferment normalement lorsqu'un point de terminaison envoie le signal et que l'autre en accuse réception. Lorsque la tentative de répartition du service Push est effectuée sur un socket fermé, les journaux affichent les exceptions de socket.

Afin d'éviter ce problème, vérifiez qu'aucune règle de pare-feu ne ferme les sockets APNS ou utilisez la propriété JNDI push.apns.connectionIdleTimeout du service Push. Si vous configurez cette propriété, le serveur ferme normalement le socket utilisé pour les notifications push APNS dans un délai imparti (inférieur au délai d'attente du pare-feu pour les sockets). Un client peut ainsi fermer les sockets avant leur arrêt brutal par le pare-feu.

Exemple :

java.net.SocketException: Malformed reply from SOCKS serverat java.net.SocksSocketImpl.readSocksReply(SocksSocketImpl.java

Les notifications peuvent être instantanées, mais il arrive qu'elles soient retardées. Le retard peut varier de quelques secondes à plusieurs minutes. Il existe plusieurs raisons à cela :

• MobileFirst Server ne contrôle pas la notification une fois qu'elle atteint le service du médiateur.
• Les besoins liés au statut réseau ou de connexion de l'appareil (démarré/arrêté) doivent être pris en compte.
• Vérifiez si des pare-feux ou des proxys sont utilisés et, si tel est le cas, qu'ils ne sont pas configurés pour bloquer la communication vers le médiateur (et inversement).
• Ne créez pas de liste blanche d'adresses IP de manière sélective dans votre pare-feu pour les médiateurs GCM/APNS/WNS au lieu d'utiliser les adresses URL réelles des médiateurs. Cela peut générer des problèmes car l'URL d'un médiateur peut être résolue en n'importe quelle adresse IP. Les clients doivent autoriser l'accès à l'URL et non à l'adresse IP. Notez que le fait de vérifier la connectivité du médiateur via la commande telnet auprès de l'URL du médiateur ne permet pas forcément de se prémunir contre tous les problèmes. En particulier pour iOS, cela ne prouve que la connectivité sortante. L'envoi réel est effectué via des sockets TCP non vérifiés par telnet. Si vous n'autorisez que des adresses IP spécifiques, le comportement suivant est susceptible de se produire, par exemple, pour GCM :

  Caused by: java.net.UnknownHostException:android.googleapis.com:android.googleapis.com: Name or service not known.

La qualité de service d'Apple définit ce qu'on appelle la coalescence des notifications. Cela signifie que le serveur APNS ne conserve qu'une seule notification en cas de non distribution immédiate à un appareil (identifié via un jeton). Prenons l'exemple de cinq notifications réparties l'une après l'autre. Si l'appareil se trouve sur un réseau instable et que la première notification est distribuée, la deuxième est stockée temporairement par le serveur APNS. La troisième notification est alors envoyée et atteint le serveur APNS. La deuxième notification antérieure et non distribuée est alors supprimée et la troisième notification (ultérieure) est stockée. Aux yeux d'un utilisateur final, cela se manifeste par des notifications manquantes.

Si l'application n'est pas en cours d'exécution ou si elle est à l'arrière-plan, le fait de taper sur la notification dans son ombre ne lance par l'application. Cela peut être dû à la modification de la zone app_name dans le fichier strings.xml en un nom personnalisé. Cela entraîne une non-concordance entre le nom de l'application et l'action d'intention définie dans le fichier AndroidManifest.xml. Si vous devez indiquer un autre nom pour l'application, utilisez à la place la zone app_label ou employez des définitions personnalisées dans le fichier strings.xml.

Exemple :

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

Ce problème a été signalé uniquement lors de l'utilisation de machines virtuelles IBM JDK 1.8. La solution consiste à mettre à niveau IBM JDK 1.8 vers la version 8.0.3.11 ou ultérieure.

Le service Push est indiqué comme inactif malgré le déploiement du fichier .war et la configuration appropriée des propriétés mfp.admin.push.url, mfp.push.authorization.server.url et secret dans le fichier server.xml.

Vérifiez que les propriétés JNDI du serveur sont correctement définies pour le service MFP Admin. Voici un exemple de configuration correcte :

<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"'/>