Introducción a la Arquitectura de Eventos en Salesforce

«Four years from now, ‘mere mortals’ Will begin to adopt an event-driven architecture (EDA) for the sort of complex event processing that has been attempted only by software gurus [until now]’
—Roy Schulte (Gartner), 2003

(Entrada actualizada en Enero 2019, al liberarse como GA el mecanismo de Change Data Capture en Winter 19).

En esta primera entrada de una serie, intento situar, cuales son los mecanismos existentes en Salesforce, cuyo core es el uso de Eventos, e intento compararlos y ubicarlos en sus casos de uso.

Podría decirse que esta es una entrada 101 en Eventos de Salesforce.

En mi experiencia, no es trivial entender los «productos/mecanismos» que ofrece y ofrecerá Salesforce sobre eventos (Streaming API, Platform Events, etc.), y las tecnologías (Kafka, Bayeaux, Long Polling, etc.)  asociadas y los casos de uso a que dan respuesta.

Por ejemplo, el título de esta entrada es incorrecto, ya que debería ser algo así como: Introducción a los mecanismos de la Salesforce Enterprise Messaging Platform (pero con ese nombre …), espero pues, que el resto del artículo no sea como el título ;-).

Introducción a la Arquitectura de Eventos

No voy a extenderme mucho en las ventajas que puede suponer una arquitectura basada en eventos, frente a un patrón tradicional de integraciones.

Creo que la imagen de una «Arquitectura Spaguetti » lo describe bien:

Arquitectura Spaghetti tradicional en un entorno empresarial – Fuente: Gartner

En una Event Driven Architecture (EDA en adelante), idealmente la imagen se simplifica tal que:

Event Bus Architecture – Fuente: Dzone

En muchos casos, cada vez más (especialmente cuando aparecen numerosos receptores de un mismo mensaje – IoT por ejemplo), este tipo de Arquitectura simplifica el diseño y da respuesta a casos de uso, a los que una arquitectura tradicional no daba una solución escalable.

Las ventajas de una EDA son:

1. Publicación Real-Time de los eventos en el Producer (emisor)
   1. Implica que deja de producirse pooling por parte de los Consumers
2. Desacople entre sistemas: el emisor y el receptor no se conocen
   1. Incluso la cadencia de emisión y consumo son distintos (pacing)
   2. Se enriquece si el BUS implementa Durabilidad de los mensajes (Retención de histórico recuperable a partir de último mensaje recibido)
3. Simplificación del Patrón, usando Fire&Forget
4. Arquitectura altamente escalable cuando el volumen de Consumers aumenta considerablemente

Pero también tiene desventajas:

1. Requiere de tecnologías no disponibles en todos los sistemas existentes
2. Requiere de un mediador que permita la recepción y mediación de los eventos (y si se requieren funcionalidades avanzadas, es necesario un Event Bus cualificado)
3. El número de comunicaciones entre los sistemas tiende a aumentar, especialmente si se implementa el patrón CallBack (el evento no contiene datos, solo los identificadores de los objetos de los que recuperar datos – por tanto para la recuperación se requieren invocaciones adicionales)
4. El emisor no tiene garantía, ni pretende saber, que los destinatarios hayan tratado los eventos, ya que el patrón usado es Fire&Forget (no hay garantía de que todos los clientes consuman sus eventos)
5. La gestión de errores se complica o no existe
6. Los receptores mantienen la conexión abierta con el servidor, lo que se denomina Long Polling

El modelo de integración cambia entre ambos modelos de arquitectura, en la siguiente imagen se comparan:

Comparación Arquitecturas Request-Response (enfoque tradicional) y EDA (basada en eventos) – Fuente: Hackernoon

Y el flujo de comunicación también, como por ejemplo mediante una conversación entre 2 sistemas con API y Streaming API:

Integración Tradicional vía API

Integración vía Eventos, por ejemplo con la Streaming API

Veamos a continuación los diferentes productos que Salesforce ha ido proporcionando.

Productos de Salesforce basados en Eventos

Los productos que actualmente podemos usar los clientes de Salesforce son:

1. Streaming API
2. Streaming API con Generic Streaming (diós que nombre :-))
3. Platform Events
4. Change Data Capture (liberado en GA en Winter 19)

Y otros como  Event Monitoring, External Services Async, etc., que a corto/medio plazo incorporarán nuevas funcionalidades utilizando Eventos.

Los Productos de Salesforce orientados a Eventos han ido apareciendo paulatinamente

Como veremos estos productos han ido creciendo en el tiempo.

Descripción y casos de uso de cada unos de los productos

Producto	DESCRIPCIÓN y casos de uso
Streaming API	Fue el primer producto orientado a Eventos para uso de clientes que ofreció Salesforce. Completamente orientado a cambios en los datos para que la interfaz del usuario, reaccionara a esos cambios proporcionando así una experiencia enriquecida. Es decir, al mostrarse una página VF, se suscribe a ciertos mensajes que permitían actualizar los datos o avisar al usuario de cambios en los datos visualizados.
Streaming API con Generic Streaming	Permite generar y enviar un evento en cualquier momento con un contenido de datos  personalizado  (Payload al uso limitado) sin necesidad de estar ligado a un cambio de datos. El Payload está limitado a un array de Strings y opcionalmente la lista de IDs de los receptores, lo que permite limitar a quien llegará el String de información. Orientado a casos de uso, para envío de una simple notificación ad-hoc, basada en un String y opcionalmente a un limitado número de receptores.
Platform Events	Basado en Streaming API (según comenta Jay Hurst – Responsable del equipo de Platform Events), aparece  este mecanismo mucho más versátil. Permite enviar una notificación para un evento en cualquier momento con un contenido de datos completamente personalizado (Payload al uso) sin necesidad de estar ligado a un cambio de datos. El Payload se define mediante campos, como si de un Custom Object se tratara, sin limitaciones y con las capacidades de gestión y utilización de campos de un objeto. Su orientación está claramente enfocada a la integración de sistemas, donde aparecen escenarios de IOT, integración de sistemas heterogéneos en tiempo real, y con Pacing distintos (velocidad de emisión y consumo pueden ser completamente diferentes).
Change Data Capture	Basado en Platform Events, ofrece un mecanismo que nativamente realiza el envío de una notificación para cualquier cambio, en cualquier objeto de Salesforce. No es necesaria su emisión explícita, sinó que su generación la realiza el sistema de forma automática. Los mensajes contienen la información del registro modificado, y en la cabecera del mensaje existe información adicional sobre la operación realizada, el usuario, etc. Es el mecanismo más simple ya que no requiere programación para su utilización, y es totalmente compatible con clientes externos mediante CometD.

En los siguientes apartados se analizan los productos actualmente disponibles (desafortunadamente en el momento de escribir esta entrada no tengo acceso a Change Data Capture).

Conceptos usados en cada uno de los productos

Cada producto usa conceptos, que aunque parecidos, varian entre productos.

Producto	DESCRIPCIÓN
Streaming API	Push Topic / Generic Topic: es la definición de cuándo se generará un evento y que información contendrá la notificación. Notification: es el mensaje que se genera al producirse el evento. Channel: la notificación es enviada a un canal, para que los clientes la puedan obtener y consumir. Client: son los que se suscribiéndose a N canales, reciben las notificaciones y consumen la información obtenida en el payload.
Streaming API con Generic Streaming	Streaming Channel:  lo que entendimos como el Channel, ahora se define mediante un objeto Standard. Streaming Channel Push: término utilizado para el envío de la notification.
Platform Events (y CDC)	Platform Event: es la definición del contenido que tendrá el payload, sus campos de datos. Event message: es el mensaje, lo que en Streaming API es la Notification, por eso también se denomina Event Notification. Channel: a notificación es enviada a un canal, para que los clientes la puedan obtener y consumir. Event Producer y Event Consumer: aunque cambian los nombres siguen siendo el Emisor del evento y el Cliente que lo recibirá y consumirá.

Creación del Canal y Generación del Evento

Veamos pues, como se realizan la creación del canal y la generación del evento en cada uno de los productos:

Producto	DESCRIPCIÓN
Streaming API	La creación del canal consiste en la creación del Topic, que consiste en la definición de una SOQL. Esta query indica qué campos de un objeto deben verse alterados (Insert, Update, Delete, Undelete) para que se lance el evento. La SOQL SELECT Id, Name, Phone FROM Account WHERE BillingCity=\'San Francisco\' provocará un evento cada vez que en Account se produzca una Creación, Actualización , Delete y/o Undelete (que afecte a estos campos) de un registro cuya BillingCity sea San Francisco. No todas las queries son posibles, no se permiten cláusulas AVG, MAX, MIN, SUM, COUNT, LIMIT, etc., ni agrupaciones, ordenaciones, etc y existen restricciones a cumplir (Id debe formar parte del Select, por ejemplo). El canal para la suscripción de los clientes, se crea automáticamente en el recurso /topics/nombre_Topic. El Payload de la notificación enviada está formado exclusivamente por los campos que  se indican en la definición de la Query, y no es ampliable. La SOQL de definición puede usar cualquier objeto Custom y  los siguientes estándar: Account, Campaign, Case, Contact, Lead, Opportunity, Task, y bajo petición ContractLineItem, Entitlement, LiveChatTranscript, Quote, QuoteLineItem, ServiceContract.
Streaming API con Generic Streaming	La creación del canal consiste en la creación de un registro en el objeto Streaming Channel, cuyo campo más importante es el Channel Name que debe tener el formato: /u/notifications/ExampleUserChannel. Es posible crear este Channel a través de APEX y APIs (REST y SOAP). La generación de un evento se realiza mediante un POST al recurso /services/data/v/sobjects/StreamingChannel/ID/push donde el cuerpo del mensaje contiene un array de parejas un String con el mensaje a enviar y un array de identificadores de receptores si es que se desea restringir a quien quiere enviarse el mensaje. Esta versión de la Streaming API, soporta Dynamic Streaming Channel Creation, es decir, la creación automática del canal durante la primera invocación de la primera suscripción de un cliente.
Platform Events (y CDC)	El primer paso requiere la definición de un Platform Event, que es casi idéntico a un Custom Object (tiene como campos estándar: Fecha Creación, Creador y Replay ID) y podemos añadir campos de los tipos: Checkbox, Date, Date/Time, Number, Text y Text Area (Long). La publicación de un Platform Event se puede realizar mediante: Visual Flow ó Process Builder de forma declarativa Codificación en APEX mediante la clase Database Invocación vía API (SOAP/REST). En el caso de REST el recurso es:  /services/data/v41.0/sobjects/ Event_Name __e/  proporcionado el Payload definido en la creación del Platform Event.

Suscripción al canal

Análogamente para la suscripción:

Producto	DESCRIPCIÓN
Streaming API (también Generic)	Subscripción: requiere de implementación de un cliente del protocolo Bayeaux, típicamente CometD en javascript, del cual hay muchos ejemplos en la documentación y en la comunidad (por supuesto disponible para otros lenguajes) No es posible hacerlo de forma declarativa, ni por otro mecanismo de configuración. Además es posible la Bulk Subscription: en lugar de indicar un solo Channel y Topic, se realiza la petición de un array de Channels y Topics. De-suscripción: es una de las 5 funcionalidades básicas del protocolo Bayeaux: Connect, Disconnect, Handshake, Subscribe y Unsubscribe. Desactivar temporalmente Push Topic: es posible desactivar un Push Topic temporalmente, sin necesidad de eliminar y re-crearlo.
Platform Events (y CDC)	La suscripción se realiza: Usando Visual Flow ó Process Builder de forma declarativa. Usando Triggers con la operación after insert. Adicionalmente es posible re-procesar un evento con la operación EventBus.RetryableException Y también podemos suscribirnos con un cliente CometD, donde el canal de suscripción es sobre /event/ Event_Name __e Destacar que los suscriptores APEX, se ejecutan en el proceso denominado «Automated Process«, lo que por ejemplo obliga a la creación de un Trace Log con ese usuario, para visualizarlos (existen otras implicaciones que deben comprobarse). La de-suscripción es equivalente.

Aquí vemos un esquema resumen de Platform Events donde observamos todos los mecanismos comentados:

Esquema de uso de Platform Events – Fuente: Salesforce

Características únicas de cada Producto

Cada uno de estos productos, posee ciertas características que vale la pena conocer, no se ahonda en cada una de ellas, solo trato de enumerarlas.

Versionado de Schema en Platform Events

El schema es un concepto que Salesforce introduce para identificar la versión de los metadatos del mensaje.

Así, en Platform Events, podemos modificar arbitrariamente el contenido del Objeto creado, que conformará el contenido de la estructura. Por tanto, si se modifica la definición del Platform Event, y el sistema consumidor no puede detectar que la estructura ha cambiado, puede aparecer un problema de inconsistencia de datos.

Para lidiar con esta problemática:

• El Schema está versionado y cada mensaje contiene un identificador de la versión del schema usado.
• El esquema está accesible para ser consultado vía API en los recursos siguientes:
  • /vXX.X/event/eventSchema/Schema_ID
  • /vXX.X/sobjects y /Platform_Event_Name__e/eventSchema

Topic Filtering

Si no deseamos recibir todos los mensajes, podemos filtrar la suscripción para recibir solo algunas de las notificaciones/mensajes en el canal establecido, filtrando la recepción durante la suscripción.

Para ello tan solo requiere la adaptación del String de suscripción: topic/ChannelName?<expression>, donde expression es fieldA=valueA&fieldB=valueB&…

Ver la lista de suscriptores en Platform Events

Platform Events permite mostrar la lista de suscriptores vía la interfaz de usuario como vía API (Triggers o Processos (sólo vía API) asociados a cada evento definido).

Ver los suscriptores se realiza mediante la interfaz de usuario, en la página de definición del evento (recuerda que en esta lista no verás los suscriptores CometD).

Message Durability

La conservación del histórico de mensajes para su Recuperación es la capacidad de un cliente para recuperar notificaciones aún disponibles en lo que se denomina la ventana de retención.

Esto permite un total desacople entre emisores y receptores, y un ritmo de generación y consumo que puede ser distinto, es decir, el emisor genera eventos y el receptor los va recibiendo y consumiendo a su ritmo.

Message Durability explicada por Salesforce – Fuente: Salesforce

Por cada producto de Salesforce tiene características de retención levemente distintas:

Producto	DESCRIPCIÓN
Streaming API (incluye Generic)	Soportado a partir de la v37 (consultar en la documentación la duración de la ventana de retención, ya que puede ser que Salesforce la vaya aumentando en cada release.
Platform Events	Soportado con una ventana de recepción de 24h como en Streaming API, pero sólo para los clientes CometD, no via Trigger.

Consideraciones de Seguridad

Streaming API

• FLS se aplica tanto a los campos del SELECT como del WHERE:
  • Si el nivel de acceso del cliente no permtie acceso a algunos de los campos del WHERE de la definición del Topic, el cliente no recibe esa notificación.
  • Análogamente, si el nivel de acceso del cliente no permite acceso a alguno de los campos del SELECT, el cliente SI recibe la notificación, pero no recibirá ese campo informado.
• Puede restringirse el acceso sobre el Objeto utilizado en la Query.
• Puede restringirse el acceso sobre el propio PushTopic.
• Puede restringiste el acceso sobre el Push Streaming Channel.

Platform Events (y CDC)

• FLS no aplica: Todos los campos son read-only por defecto, y no es posible restringir el acceso a los campos individualmente. Dado que los campos de un evento no son visibles en la interfaz de usuario, FLS no aplica.
• La utilización de Platform Encription no aplica.

Límites

A continuación se detallan los límites según la documentación en el momento de escribir la entrada.

Streaming API

De los siguientes límites, es importante notar las restricciones sobre:

• Número máximo de Topics por Org
• Número máximo de clientes sobre un Topic

Límites sobre la Streaming API – Fuente: Salesforce

Platform Events

Para este producto existen numerosas restricciones, que aplican tanto a la definición, como a la generación de eventos, el número de clientes que consumen, etc.

Para obtener la información más actual sobre estos límites consulta esta página: Platform Event Allocations.

Limitaciones adicionales existentes

Producto	DESCRIPCIÓN
Streaming API	La SOQL de definición puede contener hasta 1300 caracteres.
Platform Events	No son transaccionales y por tanto no existe Rollback.
Change Data Capture	Únicamente  soporte para algunos objetos.

Palabros que suenan alrededor de Eventos pero que despistan

Durante el aprendizaje de la arquitectura de Eventos, aparecen otros conceptos y palabrOs, que a menudo descolocan.

1. Kafka: es una plataforma distribuida de eventos, originalmente construida por Linkedin y actualmente mantenida por Apache. No es necesario conocer Kafka para entender y usar la arquitectura de Eventos Salesforce, pero se menciona porque es el mecanismo que ha inspirado el diseño de Salesforce.
2. Salesforce Connect: es un mecanismo basado en oData para el acceso a datos externos a Salesforce como si de objetos locales se tratara. Nada tiene que ver con la Arquitectura de Eventos de Salesforce.
3. Heroku Connect: es un mecanismo de replicación continua entre Salesforce y el servicio PaaS de Heroku. Aunque ambas se comunican por mensajes y eventos, nada tiene que ver tampoco con la Arquitectura de Eventos de Salesforce, sinó que es otro de los mecanismos de integración que tiene Salesforce.
4. External Services: la siguiente versión de este servicio, podría utilizar la tecnología de eventos, para proporcionar asincronía, por eso se menciona como otro de los productos que utilizará el mecanismo de eventos.
5. EMP Connector: es una librería Java que implementa un cliente CometD que ha liberado Salesforce para facilitar el desarrollo sobre la plataforma y simplificar nuestro código utilizando sus funciones (enlace en la parte final del artículo).

Conclusiones

Como hemos visto la plataforma de Eventos de Salesforce ha ido evolucionando y aportando nuevos productos, donde cada uno de ellos satisface ciertos casos de uso y necesidades.

Actualmente, Platform Events y CDC (liberado en GA Winter 19) parece el más flexible, el más potente, y un paso adelante para Salesforce (aunque, aún no soporta grandes volúmenes de Eventos).

Por otro lado, algunas entradas en blogs y comentarios, demonizan la arquitectura de interfaces tradicional, pero en mi opinión será la combinación de una Arquitectura SOA + Arquitectura de Eventos permitirá abordar proyectos más complejos que los actuales con garantías de éxito en entornos empresariales con heterogeneidad de sistemas.

Mi experiencia personal en varios proyectos utilizando este mecanismo y especialmente cuando era empleado de Salesforce, y por tanto tenía que ofrecer soporte al cliente sobre esta tecnología es:

• Habitualmente es un patrón de diseño que se entiende perfectamente, se pinta muy fácilmente en PowerPoint y en la PoC básica funciona de maravilla
• Aún así, su fiabilidad en ciertos altos volúmenes puede ser comprometida.
• Investigar por qué uno de los clientes no ha recibido un evento determinado, es muy difícilmente trazable y puede existir muchas razones por las qué hayan incidencias: seguridad aplicada en  la configuración de red del cliente,  insuficientes recursos de tratamiento del consumidor, etc.
• En casi todos los proyectos, no se plantea como se van a reconciliar los eventos generados y los consumidos, solo se detectan errores difícilmente investigables y  salta la alarma.
• El Event Bus puede tener incidencias puntuales, y por tanto los consumidores, deben explícitamente tener un mecanismo de retro-recepción de eventos (volver a recibir los eventos desde cierto instante del tiempo). A veces, este mecanismo puede no ser posible, ya que si volvemos a aplicar los mensajes (doble imputación de cargos bancarios, doble imputación de pedidos en almacenes, etc.) podemos generar inconsistencia de datos.
• Utilizar eventos para transmitir información crítica, sin mecanismos de reconciliación y sin mecanismos de retro-recepción, con volúmenes altos en mi opinión es una situación indeseable para el uso de Platform Events.

Enlaces interesantes

Para saber recomiendo estos artículos:

• 10 thoughts about Platform Events de Alba Rivas
• Introduction to Platfom Events de Pedro M. Molina
• First Impressions with Platform Events and the Salesforce Enterprise Messaging Platform de Christopher Marzilli
• Change Data Capture de mi mismo.

Guías oficiales:

• Streaming API Develper’s Guide
• Platform Events Developer’s Guide
• Salesforce EMP Connector
• CometD

Anuncio publicitario