Uso de las herramientas y los patrones correctos para arquitecturas dirigidas por eventos

Las arquitecturas dirigidas por eventos admiten la producción y el consumo eficientes de eventos, que comunican cambios de estado del sistema o la aplicación. Estas arquitecturas permiten conexiones flexibles entre sistemas y procesos de asistencia y actualizaciones casi en tiempo real que funcionan entre sistemas. Aunque las ventajas de las arquitecturas dirigidas por eventos son fáciles de ver, los detalles de implementación no siempre son tan claros. ¿Qué funciones necesita tener en cuenta en patrones arquitectónicos dirigidos por eventos? ¿Qué problemas específicos resuelven estos patrones? ¿Qué consideraciones especiales se aplican a sus soluciones y cuáles son los patrones óptimos para abordarlas?

Esta guía presenta patrones utilizados para crear arquitecturas dirigidas por eventos óptimas cuando se trabaja con tecnologías de Salesforce. También analiza herramientas de eventos disponibles en Salesforce y proporciona recomendaciones de herramientas para una selección de casos de uso. Para obtener información acerca de integraciones a nivel de datos que implican Salesforce, consulte nuestra Guía de decisiones de integración de datos.

• Utilice arquitecturas dirigidas por eventos para procesos que no requieren respuestas síncronas a solicitudes. Los patrones descritos en esta guía están diseñados para la coherencia, la capacidad de ampliación y la reutilización de datos, lo que ayuda a mantener la deuda técnica al mínimo a medida que evoluciona el panorama de aplicaciones de su organización. (Consulte Bien arquitectado - Rendimiento para obtener más información.)

• Si MuleSoft u otra solución de Enterprise Service Bus (ESB) forma parte de su entorno existente, utilícela donde sea posible. Estas soluciones están diseñadas específicamente para admitir patrones de arquitectura dirigidos por eventos y tienen potentes funciones que le permiten reutilizar integraciones en su empresa.

• Utilice la API Pub/Sub para cualquier patrón de publicación/suscripción futuro en vez de crear sus propios controladores de eventos utilizando otras API, incluyendo la API de transmisión. Ahora que la API Pub/Sub está disponible de forma general, utilícela para cualquier patrón de publicación/suscripción nuevo. Planifique migrar comunicaciones de eventos existentes utilizando otras API de plataforma, como la API de transmisión o servicios Apex personalizados, a la API Pub/Sub cuando sea factible hacerlo.

• Los eventos de plataforma y Captura de datos de cambios (CDC) son los mecanismos preferidos para publicar cambios de registro y campo que necesitan ser consumidos por otros sistemas. No recomendamos utilizar PushTopic y eventos genéricos para nuevas implementaciones. Salesforce seguirá admitiendo PushTopic y eventos genéricos dentro de las funciones actuales, pero no tiene intención de realizar más inversiones en esta tecnología.

Salesforce Platform es una plataforma integral dirigida por IA que unifica empleados, agentes de IA autónomos, datos de la empresa y aplicaciones en un único sistema de confianza para mejorar la productividad y la experiencia del cliente. Permite la creación de una "empresa agencia" conectando aplicaciones Customer 360, Data Cloud y Slack para la automatización de extremo a extremo.

MuleSoft es la plataforma de integración líder de Salesforce que permite a las organizaciones conectar aplicaciones, datos y dispositivos en entornos locales y en la nube. MuleSoft es una plataforma que proporciona a TI las plataformas para desbloquear datos entre sistemas, desarrollar marcos de trabajo de automatización e integración ampliables y crear experiencias conectadas y diferenciadas rápidamente.

Las arquitecturas dirigidas por eventos (EDA) se recomiendan para escenarios que requieren notificaciones casi en tiempo real, distribuyendo la carga de procesamiento para mensajes complejos o de gran volumen e integrando sistemas como IoT y dispositivos móviles que requieren resiliencia de conectividad a través de colas. Sin embargo, los EDA no deben implementarse para procesos que exigen respuestas humanas inmediatas y síncronas, ya que están diseñados para la ejecución asíncrona. Tampoco se ajustan bien si los datos de origen cambian con tan poca frecuencia que un patrón más sencillo como el procesamiento por lotes sería suficiente.

Estos son varios escenarios comunes que a menudo se ajustan bien a una arquitectura dirigida por eventos:

La mayoría de las grandes organizaciones tienen entornos de TI complejos que tienen una combinación de sistemas con diferentes funciones. Es posible, o quizás probable, que su organización tenga sistemas heredados que no admitan integraciones dirigidas por eventos. También puede tener casos de uso donde las integraciones dirigidas por eventos no tienen sentido, incluso si los sistemas las admitirán (por ejemplo, transferencias de archivos SFTP desde terceros). Si da un paso atrás y observa el panorama de TI de su organización en su conjunto, lo más probable es que, al igual que con otras soluciones arquitectónicas, emplee una mezcla de patrones para dar cobertura a diferentes escenarios. Cuando decida hacer que el enfoque dirigido por eventos sea su enfoque preferido para integraciones, piense en ello como otra herramienta en su caja de herramientas. Puede y debe utilizarse en los escenarios correctos, pero no es un enfoque a imponer en cada sistema. El desarrollo de una estrategia de integración integral le ayudará a determinar cuándo los patrones descritos en esta guía pueden o no ser apropiados.

Muchos escenarios requieren arquitecturas dirigidas por eventos, y en algunos escenarios, las arquitecturas dirigidas por eventos funcionarán incluso si no son las más adecuadas. Pero en algunos escenarios, las arquitecturas dirigidas por eventos simplemente no se deben utilizar. Estas son algunas preguntas de punto de decisión para ayudarle a identificar estos escenarios:

Hay una variedad de patrones de arquitectura dirigidos por eventos. Algunos son patrones de propósito general que se pueden aplicar en casos de uso que no tienen ningún requisito especial fuera de estar dirigidos por eventos; por ejemplo, consulte Bien arquitectado - Interoperabilidad. Otros patrones son aplicables a los casos de uso específicos analizados aquí, como integraciones que implican grandes volúmenes de datos o escenarios que requieren una retención de mensajes más larga.

La tabla siguiente compara atributos de los patrones descritos en este documento. Utilícelo como una referencia rápida cuando necesite identificar patrones potenciales para un caso de uso concreto.

Salesforce ofrece múltiples herramientas para ayudarle a solucionar sus casos de uso dirigidos por eventos. Esta tabla contiene una descripción general de alto nivel de las herramientas disponibles.

Cuando un registro crítico cambia de estado en una aplicación principal (por ejemplo, el estado de un pedido pasa de "Procesando" a "Enviado"), es probable que varios otros sistemas requieran una notificación casi en tiempo real para realizar sus tareas respectivas. Una necesidad comercial específica surge cuando el volumen de estos cambios es alto y los mensajes son complejos, lo que hace que las integraciones punto a punto tradicionales sean onerosas y difíciles de mantener. El establecimiento de conexiones frágiles y personalizadas para cada aplicación dependiente individual lleva a deudas técnicas e inhibe la capacidad de la organización para ampliarse rápidamente. Se necesita un enfoque de integración sólido para gestionar estas sincronizaciones de datos frecuentes sin acoplar el sistema de origen directamente a cada sistema de consumo.

El siguiente diagrama representa un patrón típico de publicación/suscripción con múltiples publicadores y suscriptores compartiendo datos a través de un bus de eventos. Este patrón fundacional forma la base para los patrones más específicos que se pueden encontrar en el resto de esta guía. Algunas características clave de este patrón son:

• No hay conexión directa entre publicadores y suscriptores. Los publicadores simplemente envían mensajes a un bus de eventos, que los difunde a cualquier otro sistema que desee escucharlos.

• El mismo sistema puede ser un publicador y un suscriptor.

• Los sistemas pueden publicar o suscribirse a múltiples tipos de eventos.

• Al igual que con todos los patrones de esta guía, el patrón publicar / suscribir recae en una categoría de patrón de integración general conocida como invocación de procedimiento remoto (RPI) o simplemente "disparar y olvidar".

Cuando una organización necesita enviar actualizaciones instantáneas a un gran número de aplicaciones cliente, como notificaciones distribuidas o mensajes SMS a dispositivos móviles, el proceso tradicional de crear transmisiones exclusivas para cada destinatario se convierte rápidamente en un cuello de botella de escalabilidad. La necesidad comercial principal, en este caso, es la distribución rápida y de alto rendimiento de una única información (como una alerta de cuenta o un aviso de cambio de servicio crítico) a numerosas aplicaciones de extremo de forma simultánea. Un enfoque simplificado para cumplir este requisito implica el enrutamiento de todos los mensajes a través de una única cola, que actúa como el punto central de la información de eventos para todos los sistemas que consumen. Este enfoque mejora el rendimiento eliminando la necesidad de gestionar muchas copias de mensajes separadas.

Con el patrón fanout, los mensajes se entregan a uno o múltiples destinos (es decir, clientes o suscriptores que escuchan) a través de una única cola de mensajes. Los suscriptores recuperan el mismo mensaje de la cola, en vez de su propia copia exclusiva. (Tenga en cuenta que aunque esto mejora el rendimiento, también puede hacer más difícil verificar si un suscriptor en particular recibió o no el mensaje.)

Algunos escenarios de eventos se caracterizan por una afluencia significativa de volumen de mensajes que amenaza con desbordar la capacidad de los procesos de sincronización y transformación, o por la lógica compleja de múltiples pasos requerida para procesar y transformar datos de eventos.

Algunos ejemplos incluyen:

• Picos de volumen estacionales: Puede haber picos de volumen que los minoristas en línea experimentan cuando una selección de sus productos está "en temporada". Cuando un gran número de clientes están realizando compras al mismo tiempo, el número de eventos generados puede superar temporalmente la capacidad de los procesos de sincronización y transformación. Consulte Bien arquitectado: Gestión de datos para obtener más información.

• Gestión de casos o reclamaciones: Las empresas basadas en servicios pueden experimentar aumentos en el número de casos o reclamaciones durante cortes.

• Transformaciones de datos complejas: Las organizaciones que requieren lógica compleja para transformar mensajes a menudo están preocupadas por que los eventos se generen con mayor rapidez de la que se pueden transformar.

Este patrón aborda el reto de que los mensajes se generen con mayor rapidez de la que se pueden transformar. Garantiza que se puedan gestionar grandes volúmenes de mensajes y manipulaciones de datos requeridas de forma fiable, incorporando una plataforma de mensajes de transmisión y segmentando la lógica de gestión de mensajes en componentes exclusivos.

El patrón Mensajes pasados funciona segmentando la lógica de gestión de mensajes en múltiples componentes:

• Un componente gestiona el enrutamiento de mensajes, determinando las transformaciones requeridas y el destino final.

• Un conjunto separado de componentes gestiona diferentes capas de transformación de mensajes (por ejemplo, asignaciones de campos, relaciones de objetos, etc.).

• El último componente redacta el mensaje modificado final.

Algunos productores generan una transmisión continua de eventos. Un ejemplo común es la transmisión de medios, que implica interacciones de usuario que se producen de forma natural como eventos discretos. Múltiples sistemas deben reaccionar al mismo comportamiento de usuario de forma simultánea sin bloquear la experiencia de transmisión principal.

Considere los eventos para una plataforma de transmisión de música. Estos pueden incluir:

• Realizar un seguimiento de eventos iniciados/en pausa/omitidos

• Escuchar eventos de sesión con marcas de tiempo

• Eventos de creación/modificación de listas de reproducción

• Eventos de colaboración social

• Descargar para escuchar sin conexión

En el patrón Transmisión, los suscriptores acceden a cada transmisión de evento y procesan los eventos en el orden exacto en el que se reciben. Se envían copias exclusivas de cada transmisión de mensajes a cada suscriptor, lo que permite entregar contenido específico del suscriptor e identificar qué suscriptores reciben qué transmisiones.

Para que una transmisión tenga sentido, todos sus eventos y sus mensajes asociados deben estar en el orden correcto. Si origina los datos en una transmisión desde diferentes sistemas, tendrá que incorporar lógica de pedido adicional como parte del proceso de diseño.

Los casos de uso en cola son omnipresentes. Algunos ejemplos incluyen:

• Conexiones a Internet de baja calidad: Las organizaciones de servicio de campo u otras organizaciones donde los equipos con dispositivos móviles necesitan trabajar en áreas con acceso a Internet de baja calidad o intermitente se benefician de las colas porque las aplicaciones en estos dispositivos pueden conectarse a sus colas y recuperar cualquier mensaje relevante cuando se restaura la conectividad.

• Almacenamiento en caché de mensajes: Cuando el volumen de mensajes supera ocasionalmente la capacidad de procesamiento de un suscriptor y el aumento de la latencia no crea problemas adicionales, las colas pueden ser un colchón para almacenar mensajes excedentes y evitar la pérdida de datos.

• Gestión de transporte: Las organizaciones logísticas que necesitan supervisar sus flotas pueden utilizar este patrón para ver las rutas que está realizando cada vehículo casi en tiempo real y garantizar que los conductores están siendo lo más eficientes posible.

• Dispositivos IoT: Los fabricantes a menudo utilizan sistemas que generan transmisiones rápidas de datos, y estas transmisiones pueden tener efectos descendentes en sistemas adicionales. Este patrón se puede utilizar para identificar secuencias de eventos que requieren intervención humana antes de que se produzcan fallos catastróficos que abarquen múltiples sistemas.

En el patrón Colas, los productores envían mensajes a colas, que albergan los mensajes hasta que los suscriptores los recuperan. La mayoría de las colas de mensajes siguen el orden de entrada y salida (FIFO) y eliminan cada mensaje después de recuperarlo. Cada suscriptor tiene una cola exclusiva, que requiere pasos de configuración adicionales pero permite garantizar la entrega e identificar qué suscriptores recibieron qué mensajes.

Debido a la naturaleza asíncrona del patrón Cola, puede haber un largo retraso entre la incorporación de un mensaje a una cola y la recuperación de ese mensaje. Las colas requieren memoria o espacio de almacenamiento para albergar sus mensajes, de modo que no pueden crecer indefinidamente, lo que significa que un suscriptor que está sin conexión indefinidamente puede provocar un fallo si se acumulan suficientes mensajes en la cola. El almacenamiento en memoria intermedia de mensajes puede tener el mismo efecto si los tiempos de procesamiento de los suscriptores son demasiado largos, lo que provoca que se acumulen grandes volúmenes de mensajes en sus colas. Para mitigar estos riesgos, realice un análisis exhaustivo de los requisitos de almacenamiento para todas las colas de mensajes y, si es necesario, diseñe procesos que purgarán y desactivarán colas si los mensajes no se recuperan en un tiempo establecido o cuando alcanzan un volumen predeterminado.

Incluso si está completamente convencido de que una arquitectura dirigida por eventos es correcta para su organización, es posible que esté empezando con un panorama que ya tiene un gran número de integraciones de punto a punto. Obtener financiación para un proyecto que sustituya todas sus integraciones a la vez puede ser difícil, e incluso podría no ser posible utilizar una arquitectura dirigida por eventos directamente con algunos sistemas heredados. En estos escenarios, puede adoptar un enfoque incremental para migrar a una arquitectura acoplada de forma más flexible convirtiendo las aplicaciones más críticas para el negocio primero, luego convirtiendo otros sistemas a medida que se actualizan o se sustituyen en proyectos futuros. Este enfoque facilita la incorporación de nuevas aplicaciones al bus de eventos y permite que su panorama de TI general se mantenga ampliable y resistente a medida que se agregan sistemas con el tiempo.

Como arquitectos, sabemos que cada arquitectura tiene ventajas. Una arquitectura dirigida por eventos no es una excepción. Aunque un paisaje lleno de sistemas acoplados de forma flexible es altamente ampliable y resistente, también hay algunas ventajas a tener en cuenta:

• Estrategia general de integración: Independientemente de las herramientas y los patrones que decida utilizar, es importante empezar por crear una estrategia para el modo en que se compartirán los datos entre los diversos sistemas del panorama de su organización. Esta estrategia debe incluir los objetivos de su organización para sus datos, cómo se pueden compartir los datos y los patrones utilizados, así como orígenes de datos, objetivos, estructuras y requisitos de propiedad y acceso.

• Soporte para sistemas heredados: Su organización puede tener sistemas heredados que simplemente no admiten patrones de arquitectura dirigidos por eventos. Aunque es posible crear soluciones (por ejemplo, con un proceso que actúa como una transferencia suscribiéndose a eventos y luego enviando el resultado al sistema de destino a través de un medio diferente de transferencia de datos), es posible que desee considerar otros métodos de integración en este caso.

• Cambios estructurales en los mensajes: Una vez definida y acordada la estructura de mensajes inicial entre publicadores y suscriptores, puede ser difícil cambiar, especialmente si los suscriptores son externos. Existen varias formas de solucionar este problema. Puede utilizar extremos versionados, pero asegúrese de definir y comunicar un ciclo de vida claro para cada versión de modo que sus desarrolladores no tengan que mantener demasiadas versiones simultáneamente. Si Apache Kafka en Heroku forma parte de su paisaje, también puede considerar un registro de esquemas o una herramienta similar, pero asegúrese de que los otros sistemas en su paisaje lo admiten (y lo utilizan) también.

• Falta de visibilidad entre publicadores y suscriptores: En la mayoría de los patrones de arquitectura dirigidos por eventos, los publicadores no son conscientes del estado de sus suscriptores. Por lo tanto, si un publicador envía un mensaje crítico mientras todos los suscriptores están sin conexión, es posible que el mensaje nunca se entregue. Puede solucionar este problema haciendo uso de funciones de reproducción o agregando suscriptores redundantes que se ejecutan en servidores separados para todos los mensajes críticos.

• Cuellos de botella de rendimiento: A medida que se amplía una arquitectura dirigida por eventos, el bus de eventos puede convertirse en un cuello de botella para la entrega de mensajes si se desborda con demasiados publicadores intentando enviar mensajes a demasiados suscriptores de forma simultánea. Puede solucionar esto aumentando los recursos de memoria y procesamiento asignados al bus de eventos o utilizando múltiples buses de eventos para procesar diferentes tipos de mensajes en paralelo.

Antes de implementar una arquitectura dirigida por eventos, considere si realmente necesita utilizar una en primer lugar. La sección anterior describe escenarios comerciales comunes que se ajustan bien a cada patrón de arquitectura dirigido por eventos. También puede leer más en Bien arquitectado - Interoperabilidad. Revise Retos a tener en cuenta al implementar arquitecturas dirigidas por eventos para determinar si los patrones que tiene en mente son los más adecuados para sus casos de uso específicos.

Tenga en cuenta que aunque la mayoría de los escenarios cubiertos en esta guía implican integraciones, las arquitecturas dirigidas por eventos también se pueden utilizar para enviar mensajes dentro de una única organización de Salesforce a través del uso de eventos de plataforma, por ejemplo. Asegúrese de tener en cuenta cualquier límite de asignación de eventos aplicable cuando diseñe procesos que utilizan eventos de plataforma como un sistema de mensajería interno.

Con frecuencia, los antipatrones en arquitecturas dirigidas por eventos provienen del uso de eventos como una solución para comunicaciones internas en una organización de Salesforce. Los antipatrones comunes incluyen:

• Publicación de eventos desde desencadenadores Apex asociados con el mismo objeto de evento: Esto dará como resultado un bucle de desencadenador infinito.

• Publicación de eventos desde Apex antes de que se complete una transacción DML: Si una transacción falla y se revierte, cualquier evento publicado que tenga el comportamiento Publicar inmediatamente no se incluirá en el comportamiento de reversión.

• Publicación de eventos en Flujo para orquestar la automatización posterior: La mejor forma de coordinar la lógica entre múltiples automatizaciones es utilizar subflujos o Flow Orchestrator.

• Creación de dependencias de tiempo de ejecución: No publique eventos para facilitar la comunicación entre paquetes sin realizar los pasos apropiados para eliminar dependencias de tiempo de ejecución.

• Cargas innecesariamente grandes: Al realizar solicitudes, es mejor enviar y recibir la menor cantidad de datos posible en la carga. Cada acción de un usuario podría generar múltiples solicitudes, y es importante que se procesen de forma eficiente. El envío de más datos de los necesarios puede contribuir a ralentizar el transporte y aumentar el tiempo de procesamiento.

• Gestión no selectiva de eventos de aplicación: Cuando hay múltiples componentes escuchando un evento de aplicación, los desarrolladores deben asegurarse de que el controlador de eventos solo se ejecutará cuando sea realmente deseado y útil. Por ejemplo, en Lightning Console, los componentes contenidos en fichas que no están enfocadas pueden seguir escuchando aunque no sean visibles. Un desarrollador puede utilizar varias técnicas como el uso de un elemento de utilidad en segundo plano como el único oyente, o llamar a getEnclosingTabId() para determinar si esta instancia del componente está incluida dentro de la ficha enfocada para garantizar que cada evento se gestiona solo cuando está pensado.

• El uso de Eventos de plataforma publica un comportamiento incorrecto: Los eventos de plataforma tienen dos comportamientos de publicación: Publicar inmediatamente y Publicar después de confirmar. Puede ser útil utilizar eventos de plataforma en tiempo real para casos de uso como Registro, donde desea publicar el evento de registro independientemente de si la transacción se realiza con éxito y se confirma. Sin embargo, utilice Publicar inmediatamente con mucho cuidado con eventos de plataforma en tiempo real. Los suscriptores pueden consumir eventos en la misma transacción y provocar bloqueos de filas u otras condiciones de carrera.

Al implementar una arquitectura dirigida por eventos, una de las claves del éxito es establecer estándares para cómo se diseñan los eventos en sí. Las especificaciones variarán dependiendo de los casos de uso de su organización, pero estas son algunas directrices generales:

• Determine la estructura óptima para sus cargas de eventos. Aunque los tamaños de mensaje más pequeños reducen los tiempos de procesamiento, bombardear suscriptores con volúmenes masivos de mensajes puede causar cuellos de botella de rendimiento. Es posible que tenga que iterar en sus tamaños y estructuras de carga para encontrar el equilibrio correcto. MuleSoft y herramientas ESB similares proporcionan la capacidad de diseñar cargas personalizadas en los mensajes asociados con sus eventos, lo que puede ayudarle a visualizar estructuras de datos para mejorar el rendimiento en el lado del suscriptor. (Consulte Bien arquitectado - Gestión de API para obtener más información.)

• Piense en sus procesos de extremo a extremo. Asegúrese de no crear ningún escenario de "bucle infinito", que puede ser difícil de localizar una vez que se implementen las integraciones. Un ejemplo de esto sería dos sistemas que publican eventos cuando se actualizan registros, mientras también escuchan los eventos del otro, que desencadenan eventos publicados adicionales cuando se procesan.

  Puede solucionar este tipo de antipatrón agregando lógica a ambos sistemas que garantiza que los cambios realizados como resultado de un evento que se está consumiendo no den como resultado la publicación de un nuevo evento. También debe asegurarse de documentar todos sus eventos, sus desencadenadores asociados y los sistemas descendentes que pueden verse afectados. Utilice esta documentación como referencia durante sesiones de diseño para ayudar a capturar bucles interminables y escenarios similares lo antes posible. (Consulte Bien arquitectado - Diseño de procesos para obtener más información.)

• Utilice convenciones de nomenclatura comunes entre sistemas. Las convenciones de nomenclatura coherentes son una práctica recomendada para todo el desarrollo de software, incluyendo arquitecturas dirigidas por eventos. Tómese su tiempo para documentar un conjunto de estándares para nombres de eventos, estructuras, objetos asociados y procesos de gestión de errores para garantizar la coherencia entre sistemas. (Consulte Normas de diseño bien arquitectadas para obtener más información.)