Prise en main de l'architecture de Campaign :headding-anchor:gs-ac-archi
Environnements :headding-anchor:environments
Campaign est disponible sous forme d'instances individuelles, où chaque instance représente un environnement Campaign complet.
Deux types d’environnements sont disponibles :
-
Environnement de production : héberge les applications destinées aux professionnels.
-
Environnement de non-production : utilisé pour divers tests de performances et de qualité avant que les modifications apportées à l'application ne soient envoyées à l'environnement de production.
Vous pouvez exporter et importer des packages d’un environnement à l’autre.
En savoir plus sur les packages dans la documentation de Campaign Classic v7
Modèles de déploiement :headding-anchor:ac-deployment
Deux modèles de déploiement sont disponibles : Déploiement FDA de Campaign (P1-P3) et Déploiement Campaign Grands comptes (FFDA) (P4).
Déploiement FDA de Campaign :headding-anchor:ac-deployment-fda
Dans son déploiement FDA, Adobe Campaign v8 peut être connecté à Snowflake pour accéder aux données via la fonctionnalité Federated Data Access : vous pouvez accéder aux données et aux informations externes stockées dans votre base de données Snowflake sans modifier la structure des données Adobe Campaign. PostgreSQL est la base de données principale. Vous pouvez utiliser Snowflake comme base de données secondaire pour étendre ensuite votre modèle de données et stocker vos données dans Snowflake. Par la suite, vous pourrez exécuter ETL, la segmentation et les rapports sur un jeu de données volumineux avec des performances optimales.
Déploiement Campaign Grands comptes (FFDA) :headding-anchor:ac-deployment-ffda
Dans un déploiement Grands comptes (FFDA), Adobe Campaign v8 fonctionne avec deux bases de données : une base de données Campaign locale pour la messagerie en temps réel de l’interface utilisateur et les requêtes et écritures unitaires à travers les API, et une base de données Snowflake cloud pour l’exécution de campagnes, les requêtes par lots et l’exécution de workflows.
Campaign v8 Enterprise présente le concept de Full Federated Data Access (FFDA) : toutes les données sont désormais distantes sur la base de données cloud. Avec cette nouvelle architecture, le déploiement Campaign v8 Enterprise (FFDA) simplifie la gestion des données : aucun index n'est requis sur la base de données cloud. Il vous suffit de créer les tables et de copier les données pour démarrer. La technologie de base de données cloud ne nécessite pas de maintenance spécifique pour garantir le niveau de performances attendu.
Partager l’exécution d’une diffusion :headding-anchor:split
En fonction de votre package Campaign v8, vous disposez d’un nombre spécifique d’instances de midsourcing en charge de l’exécution des diffusions.
Par défaut, les comptes externes de tous les canaux utilisent un mode de routage alterné. Une diffusion est donc envoyée simultanément à partir de chaque instance mid-sourcing de manière alternée.
Afin d’optimiser les performances à la fois en termes de vitesse et d’échelle, vous pouvez permettre le partage automatique des diffusions entre vos instances mid-sourcing afin qu’elles soient diffusées plus rapidement aux destinataires. Cette opération est transparente lors de l’exécution de la diffusion à partir de l’instance marketing : une fois la diffusion envoyée, tous les logs sont consolidés ensemble avant d’être renvoyés à l’instance marketing dans un seul objet de diffusion.
Pour ce faire, des comptes externes supplémentaires avec le mode de routage Partagé sont créés lors de l’approvisionnement pour chaque canal :
- Partager la diffusion - E-mail (splitDeliveryEmail)
- Partager la diffusion - SMS (splitDeliverySMS)
- Partager la diffusion - iOS (splitDeliveryIOS)
- Partager la diffusion - Android (splitDeliveryAndroid)
Pour que les comptes externes partagés soient le compte par défaut pour l’envoi des diffusions, vous devez modifier le fournisseur de routage dans vos modèles de diffusion. Pour ce faire, procédez comme suit :
-
Accédez au dossier Ressources / Modèles / Modèles de diffusion et ouvrez le modèle de diffusion souhaité. Dans cet exemple, nous allons modifier le modèle de diffusion e-mail.
-
Cliquez sur le bouton Propriétés et remplacez le fournisseur de routage par le compte externe de diffusion partagée correspondant.
-
Enregistrez vos modifications. Toutes les diffusions envoyées à l’aide du modèle utilisent désormais le mode de routage partagé par défaut.
Architecture de Message Center :headding-anchor:transac-msg-archi
La messagerie transactionnelle (Message Center) est le module de Campaign conçu pour gérer les messages de déclenchement.
Découvrez comment envoyer des messages transactionnels dans cette section.
En réponse à l'action d'un client sur un site web, un événement est envoyé à Campaign par l'intermédiaire d'une API REST et le modèle de message est renseigné avec les informations ou les données fournies par le biais de l'appel API. En outre, un message transactionnel est envoyé en temps réel au client. Ces messages peuvent être envoyés individuellement ou par lots via e-mail, SMS ou notifications push.
Dans cette architecture spécifique, la cellule d'exécution est séparée de l'instance de pilotage, ce qui offre une grande disponibilité et une meilleure gestion de la charge.
-
L'instance de pilotage (ou instance marketing) est utilisée par les spécialistes marketing et les équipes informatiques pour créer, configurer et publier des modèles de messages. Cette instance centralise également la surveillance et l'historique des événements.
Découvrez comment créer et publier des modèles de messages dans cette section.
-
L'instance d'exécution renvoie les événements entrants (réinitialisation du mot de passe ou commandes à partir d'un site web, par exemple) et envoie des messages personnalisés. Il peut y avoir plusieurs instances d'exécution pour traiter les messages par l'intermédiaire de la répartition de charge et mettre à l'échelle le nombre d'événements à poursuivre pour une disponibilité maximale.
Authentification
Pour utiliser ces fonctionnalités, les utilisateurs d’Adobe Campaign se connectent à l’instance de pilotage afin de créer les modèles de messages transactionnels, générer la prévisualisation du message grâce à une adresse de contrôle, afficher des rapports et suivre les instances d’exécution.
-
Instance d'exécution unique
Lors de l'interaction avec une instance d'exécution Message Center hébergée par Adobe, un système externe peut d'abord récupérer un jeton de session (qui expire par défaut dans les 24 heures), en effectuant un appel API à la méthode de connexion à la session, et ce, à l'aide d'un nom d'utilisateur et d'un mot de passe fournis pour le compte.
Ensuite, avec le jeton de session fourni par l'instance d'exécution en réponse à l'appel ci-dessus, l'application externe peut lancer des appels API SOAP (rtEvents ou batchEvents) pour envoyer des communications, et ce, sans qu'il y ait besoin d'inclure le nom d'utilisateur et le mot de passe du compte dans chaque appel SOAP. -
Instances d'exécution multiples
Dans une architecture d'exécution multi-cellules avec des instances d'exécution multiples derrière une répartition de charge, la méthode de connexion invoquée par l'application externe passe par la répartition de charge. Pour cette raison, une authentification par jeton ne peut pas être utilisée. Une authentification par utilisateur/mot de passe est requise.
En savoir plus sur les événements de messagerie transactionnelle sur cette page.