[v7]{class="badge informative" title="S’applique également à Campaign Classic v7"} [v8]{class="badge positive" title="S’applique à Campaign v8"}
Modifications du canal de notification push push-upgrade
Vous pouvez utiliser Campaign pour envoyer des notifications push sur les appareils iOs et Android. Pour ce faire, Campaign repose sur des services d’abonnement à des application spécifiques.
Certaines modifications importantes apportées au service Android FCM (Firebase Cloud Messaging), publiées en 2024, pourront avoir une incidence sur votre mise en œuvre d’Adobe Campaign. Il se peut que la configuration de vos services d’abonnement pour les notifications push Android doive être mise à jour pour prendre en charge cette modification.
En outre, Adobe recommande vivement de passer à une connexion au service APN basée sur des jetons plutôt que sur des certificats, pour une solution davantage sécurisée et évolutive.
Service Google Android Firebase Cloud Messaging (FCM) fcm-push-upgrade
Qu’est-ce qui a changé ? fcm-changes
Dans le cadre des efforts constants de Google pour améliorer ses services, les API FCM héritées seront abandonnées le 22 juillet 2024. Pour en savoir plus sur le protocole HTTP Firebase Cloud Messaging, consultez la documentation de Google Firebase.
Adobe Campaign Classic v7 et Adobe Campaign v8 prennent déjà en charge les dernières API pour envoyer des notifications push. Cependant, certaines anciennes implémentations dépendent toujours des API héritées. Ces implémentations doivent être mises à jour.
Cela vous concerne-t-il ? fcm-impact
Si votre implémentation actuelle prend en charge les services d’abonnement se connectant à FCM à l’aide des API héritées, cela vous concerne. La transition vers les dernières API est obligatoire pour éviter toute interruption de service. Dans ce cas, les équipes Adobe vous contacteront.
Pour vérifier si cela vous concerne, vous pouvez filtrer vos services et abonnements selon le filtre ci-dessous :
-
Si l’un de vos services de notification push actifs utilise l’API HTTP (héritée), votre configuration sera directement affectée par cette modification. Vous devez passer en revue vos configurations actuelles et les déplacer vers les API les plus récentes, comme décrit ci-dessous.
-
Si votre configuration utilise exclusivement l’API HTTP v1 pour les notifications push Android, vous êtes déjà en conformité et aucune autre action ne sera requise de votre part.
Comment effectuer la mise à jour ? fcm-transition-procedure
Conditions préalables fcm-transition-prerequisites
-
Pour Campaign Classic v7, la prise en charge de HTTP v1 a été ajoutée à la version 20.3.1. Si votre environnement s’exécute sur une ancienne version, une condition préalable à la transition vers HTTP v1 est de mettre à niveau votre environnement vers la dernière version de Campaign Classic. Pour Campaign v8, HTTP v1 est pris en charge par toutes les versions et aucune mise à niveau n’est nécessaire.
-
Le fichier JSON du compte du service SDK Firebase Admin Android est nécessaire pour que l’application mobile soit déplacée vers HTTP v1. Découvrez comment obtenir ce fichier dans la documentation de Google Firebase.
-
Pour les déploiements hybrides, hébergés et Managed Services, en plus de la procédure de transition ci-dessous, contactez Adobe pour mettre à jour votre serveur d’exécution en temps réel (RT). Le serveur de midsourcing n’est pas affecté.
-
En tant qu’utilisateur ou utilisatrice On-Premise de Campaign Classic v7, vous devez mettre à niveau les serveurs d’exécution Marketing et en temps réel. Le serveur de midsourcing n’est pas affecté.
Procédure de transition fcm-transition-steps
Pour déplacer votre environnement vers HTTP v1, procédez comme suit :
-
Accédez à votre liste de services et abonnements.
-
Répertoriez toutes les applications mobiles à l’aide de la version d’API HTTP (héritée).
-
Pour chacune de ces applications mobiles, définissez la version d’API sur HTTP v1.
-
Cliquez sur le lien Charger le fichier JSON du projet pour extraire les détails du projet… pour charger directement votre fichier clé JSON.
Vous pouvez également saisir manuellement les informations suivantes :
- Identifiant du projet
- Clé privée
- Email client
-
Cliquez sur Tester la connexion pour vérifier que votre configuration est correcte et que le serveur marketing a accès au FCM. Pour les déploiements de midsourcing, le bouton Tester la connexion ne peut pas vérifier si le serveur a accès au service Android FCM (Firebase Cloud Messaging).
-
Vous pouvez, si nécessaire, enrichir un contenu de message push avec certaines variables d'application. Elles sont entièrement personnalisables et font partie de la payload du message envoyé à l'appareil mobile.
-
Cliquez sur Terminer, puis sur Enregistrer.
Vous trouverez ci-dessous les noms de payload FCM pour personnaliser davantage votre notification push. Ces options sont décrites ici.
table 0-row-3 1-row-3 2-row-3 1-align-center 2-align-center 3-align-center 5-align-center 6-align-center 7-align-center 9-align-center 10-align-center 11-align-center Type de message Élément de message configurable (nom de payload FCM) Options configurables (nom de payload FCM) Message de données N/A validate_only Message de notification title, body, android_channel_id, icon, sound, tag, color, click_action, image, ticker, sticky, visibility, notification_priority, notification_count validate_only -
Une fois la transition HTTP v1 terminée, vous devez mettre à jour vos modèles de diffusion pour les notifications push Android afin d’augmenter le nombre de messages par lot. Pour ce faire, accédez aux propriétés de votre modèle de diffusion Android puis, dans l’onglet Diffusion, définissez Nombre de lots de messages sur 256. Appliquez cette modification à tous les modèles de diffusion utilisés pour vos diffusions Android, ainsi qu’à toutes vos diffusions Android existantes.
Quel est l’impact pour mes applications Android ? fcm-apps
Aucune modification spécifique du code des applications mobiles Android n’est requise et le comportement de notification ne doit pas changer.
Cependant, avec HTTP v1, vous pouvez personnaliser davantage votre notification push avec des options supplémentaires HTTPV1.
Vous pouvez ainsi :
- utiliser le champ Bandeau déroulant pour définir le texte du bandeau déroulant de votre notification ;
- utiliser le champ Image pour définir l’URL de l’image à afficher dans votre notification ;
- utiliser le champ Nombre de notifications pour définir le nombre de nouvelles informations non lues à afficher directement sur l’icône de l’application ;
- définir l’option Permanent sur false afin que la notification soit automatiquement ignorée lorsque l’utilisateur ou l’utilisatrice clique dessus. Si elle est définie sur true, la notification reste affichée même lorsque l’utilisateur ou l’utilisatrice clique dessus ;
- définir le niveau de priorité de notification de votre notification : par défaut, minimum, faible ou élevé ;
- définir le niveau de visibilité de votre notification sur public, privé ou secret.
Pour plus d’informations sur les options supplémentaires HTTP v1 et sur la façon de remplir ces champs, consultez la documentation FCM.
Service de notification Push Apple iOS (APN) apns-push-upgrade
Qu’est-ce qui a changé ? ios-changes
Comme recommandé par Apple, vous devez sécuriser vos communications avec le service de notifications Push Apple (APN) en utilisant des jetons d’authentification sans état.
L’authentification par jeton offre un moyen sans état de communiquer avec le service APN. La communication sans état est plus rapide que la communication basée sur un certificat, car elle ne nécessite pas de service APN pour rechercher le certificat, ni d’autres informations en lien avec votre serveur de fournisseur. L’utilisation de l’authentification par jeton présente d’autres avantages :
-
Vous pouvez utiliser le même jeton depuis plusieurs serveurs de fournisseurs.
-
Vous pouvez utiliser un jeton pour distribuer des notifications pour toutes les applications de votre entreprise.
En savoir plus sur les connexions au service APN basées sur les jetons dans la Documentation destinée aux équipes de développement Apple.
Adobe Campaign Classic v7 et Adobe Campaign v8 prennent en charge les connexions basées sur des jetons et sur des certificats. Si votre mise en œuvre repose sur une connexion basée sur un certificat, Adobe vous recommande vivement de la mettre à jour vers une connexion basée sur un jeton.
Cela vous concerne-t-il ? ios-impact
Si votre mise en œuvre actuelle repose sur des demandes basées sur des certificats pour vous connecter au service APN, cela vous concerne. Il est recommandé d’effectuer une transition basée sur un jeton.
Pour vérifier si cela vous concerne, vous pouvez filtrer vos services et abonnements selon le filtre ci-dessous :
-
Si l’un de vos services de notifications push actifs utilise le mode Authentification basée sur les certificats (.p12), vos mises en œuvre actuelles doivent être examinées et déplacées vers un mode Authentification basée sur les jetons (.p8) comme décrit ci-dessous.
-
Si votre configuration utilise exclusivement le mode Authentification basée sur les jetons pour les notifications push iOS, vous êtes déjà en conformité et aucune autre action de votre part ne sera requise.
Comment effectuer la mise à jour ? ios-transition-procedure
Conditions préalables ios-transition-prerequisites
-
Pour Campaign Classic v7, la prise en charge du mode Authentification basée sur les jetons a été ajoutée à la version 20.2. Si votre environnement s’exécute sur une ancienne version, une condition préalable à ce changement est de mettre à niveau votre environnement vers la dernière version de Campaign Classic. Pour Campaign v8, le mode Authentification basée sur les jetons est pris en charge par toutes les versions et aucune mise à niveau n’est nécessaire.
-
Vous avez besoin d’une clé de signature de jeton d’authentification APN pour générer les jetons utilisés par votre serveur. Vous pouvez demander cette clé à votre compte de développement Apple, en suivant la procédure décrite à la section Documentation destinée aux équipes de développement Apple.
-
Pour les déploiements hybrides, hébergés et Managed Services, en plus de la procédure de transition ci-dessous, contactez Adobe pour mettre à jour votre serveur d’exécution en temps réel (RT). Le serveur de midsourcing n’est pas affecté.
-
En tant qu’utilisateur ou utilisatrice On-Premise de Campaign Classic v7, vous devez mettre à niveau les serveurs d’exécution Marketing et en temps réel. Le serveur de midsourcing n’est pas affecté.
Procédure de transition ios-transition-steps
Pour déplacer vos applications mobiles iOS vers le mode d’authentification basé sur les jetons, procédez comme suit :
-
Accédez à votre liste de services et abonnements.
-
Répertoriez toutes les applications mobiles utilisant le mode Authentification basée sur les certificats (.p12).
-
Modifiez chacune de ces applications mobiles et accédez à l’onglet Certificat/clé privée.
-
Dans la liste déroulante Mode d’authentification, sélectionnez le mode Authentification basée sur les jetons (.p8).
-
Renseignez les paramètres de connexion APN Identifiant de la clé, Identifiant de l’équipe et Identifiant de version, puis sélectionnez votre certificat p8 en cliquant sur Renseigner la clé privée…
-
Cliquez sur Tester la connexion pour vérifier que votre configuration est correcte et que le serveur a accès au service APN. Pour les déploiements de midsourcing, le bouton Tester la connexion ne peut pas vérifier si le serveur a accès au service APN.
-
Cliquez sur Suivant pour passer à la configuration de l’application de production et procédez comme décrit ci-dessus.
-
Cliquez sur Terminer, puis sur Enregistrer.
Votre application iOS est maintenant déplacée vers le mode d’authentification basé sur les jetons.