Prise en main de l'architecture de Campaign

Environnements

Campaign est disponible sous forme d'instances individuelles, où chaque instance représente un environnement Campaign complet.

Trois types d'environnements sont disponibles avec le Cloud Service de Campaign :

  • Environnement de production : héberge les applications destinées aux professionnels.

  • Environnement d'évaluation : 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.

  • Environnement de développement : permet aux développeurs d'implémenter Campaign dans les mêmes conditions d'exécution que les environnements d'évaluation et de production.

Vous pouvez exporter et importer des packages d'un environnement à l'autre.

Apprenez-en davantage sur les packages en consultant la documentation de Campaign Classic v7

Déploiement Mid-sourcing

La communication générale entre les serveurs et les processus est réalisée conformément au schéma suivant :

  • Les modules de diffusion et de gestion des mails rebonds sont désactivés sur l'instance.

  • L'application est configurée pour déléguer les envois des messages à un serveur de mid-sourcing distant via des appels SOAP (sur HTTP ou HTTPS).

REMARQUE

Campaign v8 repose sur une architecture hybride. Si vous effectuez une transition à partir de Campaign Classic v7, veuillez noter que toutes les diffusions passent par le serveur de midsourcing.
Par conséquent, le routage interne est impossible dans Campaign v8 et le compte externe a été désactivé en conséquence.

Architecture de Message Center

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.

ATTENTION

L'instance de pilotage et la ou les instance(s) d'exécution doivent être installées sur des machines différentes. Elles ne peuvent pas partager la même instance Campaign.

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.

Apprenez-en davantage sur les événements de messagerie transactionnelle en consultant la documentation de Campaign Classic v7

Sur cette page