Introducción a la arquitectura de Campaign gs-ac-archi
Entornos environments
Campaign está disponible como instancias individuales y cada instancia representa un entorno de Campaign completo.
Hay dos tipos de entornos disponibles:
-
Entorno de producción: aloja las aplicaciones para profesionales de la empresa.
-
Entorno que no es de producción: se usa para varias pruebas de rendimiento y calidad antes de que se inserten cambios en la aplicación en el entorno de producción.
Puede exportar e importar paquetes de un entorno a otro.
Obtenga más información sobre paquetes en Documentación de Campaign Classic v7
Modelos de implementación ac-deployment
Hay dos modelos de implementación disponibles: Implementación de FDA de Campaign (P1-P3) e implementación de Campaign Enterprise (FDAC) (P4).
Implementación de FDA de Campaign ac-deployment-fda
En su implementación de FDA, Adobe Campaign v8 se puede conectar a Snowflake para acceder a los datos a través de la capacidad de acceso de datos federado: puede acceder y procesar la información y los datos externos almacenados en la base de datos Snowflake sin cambiar la estructura de los datos de Adobe Campaign. PostgreSQL es la base de datos principal y puede utilizar Snowflake como base de datos secundaria para ampliar el modelo de datos y almacenar los datos en Snowflake. Posteriormente, puede ejecutar ETL, segmentación e informes en un conjunto de datos grande con un rendimiento sobresaliente.
Implementación de Campaign Enterprise (FDAC) ac-deployment-ffda
En el contexto de una implementación Enterprise (FDAC) Deployment, Adobe Campaign v8 funciona con dos bases de datos: una base de datos Campaign local para la mensajería en tiempo real y consultas unitarias y escritura a través de API de la interfaz de usuario, y una base de datos Snowflake de la nube para la ejecución de campañas, consultas por lotes y flujos de trabajo.
La versión 8 de Campaign Enterprise incorpora el concepto de Acceso de datos federado completo (FDAC): todos los datos ahora son remotos en la base de datos en la nube. Con esta nueva arquitectura, la implementación de Campaign v8 Enterprise (FDAC) simplifica la administración de datos: no se requiere ningún índice en la base de datos en la nube. Basta con crear las tablas, copiar los datos y empezar. La tecnología de la base de datos en la nube no requiere ningún mantenimiento específico para garantizar el nivel de rendimiento.
Ejecución de envío dividido split
Según el paquete de Campaign v8, se le proporciona un número específico de instancias intermediarias encargadas de ejecutar los envíos.
De manera predeterminada, las cuentas externas de todos los canales utilizan un modo de enrutamiento Alternate, lo que significa que se envía una entrega de cada instancia intermedia a la vez de forma alternativa.
Para garantizar un mejor rendimiento tanto en términos de velocidad como de escala, puede permitir que los envíos se dividan automáticamente en varias instancias intermediarias para que se entreguen más rápido a los destinatarios. Esta operación es transparente al ejecutar el envío desde la instancia de marketing: una vez realizado el envío, todos los registros se consolidan juntos, antes de enviarse de nuevo a la instancia de marketing en un solo objeto de envío.
Para ello, se crean cuentas externas adicionales con el modo de enrutamiento Split en el aprovisionamiento de cada canal:
- Envío dividido: correo electrónico (splitDeliveryEmail)
- Envío dividido: SMS (splitDeliverySMS)
- Envío dividido: iOS (splitDeliveryIOS)
- Envío dividido: Android (splitDeliveryAndroid)
Para que las cuentas externas divididas sean la cuenta predeterminada para realizar envíos, debe cambiar el proveedor de enrutamiento en las plantillas de envío. Para ello, siga estos pasos:
-
Vaya a la carpeta Resources / Templates / Delivery templates y abra la plantilla de envío deseada. En este ejemplo, deseamos editar la plantilla de envíos de correo electrónico.
-
Haga clic en el botón Properties y cambie el proveedor de enrutamiento a la cuenta externa de entrega dividida correspondiente.
-
Guarde los cambios. Todos los envíos realizados con la plantilla utilizan el modo de enrutamiento dividido de forma predeterminada.
Arquitectura del centro de mensajes transac-msg-archi
La mensajería transaccional (Centro de mensajes) es el módulo de Campaign diseñado para gestionar mensajes de activación.
Aprenda a enviar mensajes transaccionales en esta sección.
En respuesta a una acción de un cliente en un sitio web, se envía un evento de Campaign a través de una API de REST, y la plantilla de mensaje se rellena con la información o los datos proporcionados a través de la llamada de API, y se envía un mensaje transaccional en tiempo real al cliente. Estos mensajes se pueden enviar por separado o en serie por correo electrónico, SMS o notificaciones push.
En esta arquitectura específica, la celda de ejecución se separa de la instancia de control para garantizar una alta disponibilidad y administración de la carga.
-
Los especialistas en marketing y los equipos de TI utilizan la instancia de control (o instancia de marketing) para crear, configurar y publicar plantillas de mensajes. Esta instancia también centraliza la monitorización y el historial de eventos.
Aprenda a crear y publicar plantillas de mensajes en esta sección.
-
La instancia de ejecución recupera los eventos entrantes (restablecimiento de contraseña o pedidos de un sitio web, por ejemplo) y envía mensajes personalizados. Puede haber más de una instancia de ejecución para procesar mensajes a través del equilibrador de carga y escalar el número de eventos que se van a procesar para obtener la máxima disponibilidad.
Autenticación
Para utilizar estas funcionalidades, los usuarios de Adobe Campaign inician sesión en la instancia de control para crear plantillas de mensajes transaccionales, generar la vista previa del mensaje utilizando una lista de semilla, mostrar informes y supervisar las instancias de ejecución.
-
Instancia de ejecución única
Al interactuar con una instancia de ejecución del Centro de mensajes alojada en el Adobe, un sistema externo puede recuperar primero un token de sesión (que de forma predeterminada caduca en 24 horas), realizando una llamada de API al método de inicio de sesión, utilizando para ello un inicio de sesión de cuenta y una contraseña proporcionados.
SOAP SOAP A continuación, con el sessionToken proporcionado por la instancia de ejecución en respuesta a la llamada anterior, la aplicación externa puede realizar invocaciones de la API (rtEvents o batchEvents) para enviar comunicaciones, sin necesidad de incluir en cada llamada el inicio de sesión y la contraseña de la cuenta. -
Varias instancias de ejecución
En una arquitectura de ejecución de varias celdas con varias instancias de ejecución detrás de un equilibrador de carga, el método de inicio de sesión invocado por la aplicación externa pasa a través del equilibrador de carga: por ese motivo, no se puede utilizar una autenticación basada en token. Se requiere una autenticación basada en usuario/contraseña.
Obtenga más información acerca de los eventos de mensajería transaccional en esta página.