Consideraciones de diseño para la captura de datos modificados y eventos de plataforma ☁️

La integración es un tema esencial para los desarrolladores y arquitectos de Salesforce. Un tipo de integración ha cobrado impulso en los últimos años: la integración de procesos, quizás más conocida como integración impulsada por eventos. La plataforma principal de Salesforce admite la integración basada en eventos (o arquitectura basada en eventos) a través de la publicación y suscripción de eventos de la plataforma a otros sistemas. También puede ser una excelente manera de crear procesos acoplados libremente en la plataforma, que se describe con gran detalle en el artículo de Frank Caron y Pete O'Connell sobre arquitectura de aplicaciones impulsada por eventos en la plataforma Customer 360 .

Los eventos de plataforma en Salesforce se introdujeron en 2017 y permitieron a los clientes definir estructuras de eventos personalizadas y publicar y suscribirse a esos eventos. Desde entonces, han evolucionado hasta convertirse en lo que ahora se conoce como eventos de plataforma de gran volumen (o HVPE, por sus siglas en inglés), que amplían en gran medida las asignaciones de publicación/suscripción en comparación con la oferta original (consulte Asignaciones de eventos de plataforma ). La próxima generación de eventos de plataforma, la API Pub/Sub , se ha rediseñado y optimizado para el rendimiento y la escala, incluso permitiendo un nuevo protocolo de suscriptor, el gRPC .

Hay varias formas de publicar y consumir eventos desde Salesforce Event Bus, tanto en la plataforma como externamente. Este artículo comparará tres formas específicas de publicar eventos: Change Data Capture (o CDC), Record-Triggered Flows y, por supuesto, Apex.

Cambiar la captura de datos

Change Data Capture, en lo sucesivo denominado CDC, es la forma más rápida y sencilla de comenzar a publicar eventos. CDC envía notificaciones para registros creados, actualizados, eliminados y no eliminados a un subconjunto de eventos de plataforma del objeto estándar o personalizado compatible. CDC se puede configurar a través del menú Configuración seleccionando el objeto y agregándolo a la sección Entidades seleccionadas de CDC.

Cuando se selecciona un objeto para CDC, se crea un objeto de evento de plataforma adjunto, fácilmente identificable por su nombre. Para objetos estándar como Account , puede esperar ver AccountChangeEvent , y para un objeto personalizado como Shipment__c , verá Shipment__ChangeEvent . La configuración de objetos para CDC es simple y directa, y la ampliación de las asignaciones predeterminadas con licencias complementarias es sencilla y asequible (consulte Cambiar las asignaciones de captura de datos ).

Recuerde que CDC publica eventos de plataforma para cada registro creado, actualizado, eliminado y recuperado. Esta es una forma increíblemente poderosa de habilitar la integración de procesos. Esto funciona muy bien cuando puede predecir que la cantidad de cambios en los objetos configurados de CDC estará dentro de sus límites diarios de publicación y suscripción. Sin embargo, esto puede causar preocupación si hay actualizaciones no basadas en el usuario para sus objetos en forma de actualizaciones de Apex por lotes, trabajos de ETL y cargas de datos. Esto puede sobrecargar potencialmente sus asignaciones y provocar entregas de eventos fallidas.

“Actualizaciones no basadas en el usuario de sus objetos en forma de actualizaciones de Apex por lotes, trabajos de ETL y cargas de datos…

potencialmente puede sobrecargar sus asignaciones y conducir a entregas de eventos fallidas”.

Debería preguntarse ahora si hay una manera de evitar inundar los sistemas de suscripción con demasiados mensajes que no son bienvenidos ni relevantes. Hay varias formas, y ese es el tema del resto de este artículo.

Presentamos flujos filtrados

¿Qué pasaría si hubiera una manera de evitar la sobrecarga de los sistemas de suscripción cuando los trabajos por lotes y los ETL actualizan una gran cantidad de registros? Generalmente disponible en Winter '23 , Filtered Streams le permite crear un canal y configurarlo con un filtro complejo al que pueden suscribirse los clientes de CometD. Con menos eventos entregados a los suscriptores, pueden hacer un uso más eficiente de la asignación de entrega de eventos (consulte Filtre su flujo de eventos de plataforma con canales personalizados ).

Los filtros le permiten evitar sobrecargar los sistemas externos con notificaciones de eventos excesivas e innecesarias para CDC, pero ¿qué sucede si desea evitar la publicación de los mensajes en primer lugar? Hay dos recomendaciones para colocar el filtro antes de la publicación: flujos activados por registro con filtro y activadores de Apex para filtrar la publicación de eventos.

Flujos activados por registros con filtros

Un método alternativo para publicar eventos modificados que ofrece más control sobre los registros publicados es utilizar un flujo desencadenado por registros. Este método requiere que defina un evento de plataforma, un paso que se realiza automáticamente con CDC. Definir nuevos eventos de plataforma es similar a crear nuevos objetos personalizados, lo que incluye proporcionar un nombre y una etiqueta, y definir campos personalizados. Los campos personalizados definidos en el evento de la plataforma consistirán en los campos importantes que desea proporcionar al consumidor del evento. Una vez que haya definido un evento de plataforma, estará disponible en Flow Builder para escribirlo.

La creación de un flujo desencadenado por registro para publicar eventos de la plataforma es una tarea de bajo código; sin embargo, es una actividad de desarrollo y debe ejecutarse a través del proceso de administración del ciclo de vida de la aplicación . Baste decir que los pasos que siguen deben realizarse en un espacio aislado, rastrearse en el control de versiones y promoverse a través de procesos estándar.

Cree un nuevo flujo, seleccione Flujo desencadenado por registros en la primera pantalla, luego proporcione los criterios de entrada para determinar si el flujo se ejecutará cuando se actualicen los registros de los objetos especificados.

En este ejemplo (1) Shipment__c está configurado como el objeto para observar los cambios. El evento que desencadenará este flujo es cuando (2) se crea o actualiza un registro. Los requisitos condicionales se establecen en (3) (OR) , por lo que cuando se cumple alguna de las siguientes condiciones (4), la ejecución del flujo continúa. En resumen, cuando se modifican los registros de Shipment y el campo Estado es "Enviado" o "Entregado", las acciones que siguen al elemento Inicio se ejecutarán de inmediato. En este caso, vamos a publicar un evento de plataforma.

En términos de flujo, crearemos un registro (pero en realidad estamos publicando un evento), por lo que necesitaremos una variable de registro. A continuación, se muestra una variable denominada shipmentEventRecord para contener los valores de publicación.

A continuación, debemos asignar los valores del registro de cambio que activó el flujo a shipmentEventRecord . Esto se muestra en el elemento de asignación a continuación.

El registro de eventos de la plataforma está listo para ser publicado. Los flujos publican eventos de plataforma mediante un elemento Crear registro.

¡Eso es todo! Definimos los criterios de inicio, luego usamos una asignación para asignar los valores de Shipment__c entrantes al registro ShipmentEvent__e y, finalmente, usamos Create Records para publicar el evento. Aunque no es tan fácil como configurar objetos para CDC, sigue siendo una opción baja en calorías que ofrece mucho más control sobre el volumen de eventos publicados.

Desencadenadores de Apex para filtrar la publicación de eventos

Los flujos ofrecen una gran cantidad de funciones que antes solo estaban disponibles al escribir disparadores de Apex, entonces, ¿cuándo sería apropiado filtrar publicaciones de eventos usando Apex? Siempre habrá escenarios en los que podría ser mejor usar Apex que Flows. Aquí hay algunos que vienen a la mente:

• Su organización ha adoptado un enfoque de disparador único como principio de diseño. El uso de un enfoque/arquitectura de activación única ayuda con la trazabilidad del código y hace cumplir el orden de ejecución. Consulte con sus arquitectos de Salesforce y líderes de desarrollo para ver si esto se aplica.
• Tiene manipulaciones de cadenas muy específicas para publicar eventos que no se pueden lograr fácilmente con Flows. Los flujos son muy potentes, pero no tienen la funcionalidad completa de Apex String Class .
• El enfoque estándar de su equipo de desarrollo es escribir Apex. El lema de Salesforce es "Clics antes del código", pero muchos clientes tienen requisitos de desarrollo sofisticados en los que se prefiere escribir código en lugar de mezclar Apex con Process Builders, Workflows y Flows.

Inconvenientes de los disparadores de Apex para eventos

Considere detenidamente si publicar eventos mediante flujos o disparadores de Apex, ya que Apex tiene consideraciones.

• Escribir disparadores de Apex significa que también debe escribir pruebas unitarias de Apex, y que cuando cambia el código del disparador, también debe hacerlo la prueba unitaria.

• Los cambios en los activadores en producción requieren una implementación, por lo que alternar la publicación de eventos involucrará a su equipo de lanzamiento.
• Apex bien escrito verifica los SaveResults de la publicación, que debe cumplir con su estrategia de registro

El siguiente fragmento es el disparador de Apex equivalente al flujo de arriba:

<dx-code-block title language code-block="trigger ShipmentStatusHandler on Shipment__c ( after insert, after update, after delete, after undelete) { List shipmentEvents = new List(); for ( Shipment__c shipment : Trigger.new ) { if ( shipment.Status__c == ‘Shipped’ || shipment.Status__c == ‘Delivered’) { shipmentEvents.add( new ShipmentEvent__e( Shipment_Id__c = shipment.Name, Shipment_Status__c = shipment.Status__c ) ); } } for ( Database.SaveResult saveResult : EventBus.publish( shipmentEvents)) { if ( !saveResult.isSuccess()) { // Handle failure with logging framework } }
}»>

Conclusión

Los eventos de plataforma son una forma poderosa de habilitar la comunicación casi en tiempo real entre sistemas. Hay varias opciones para publicar eventos, que van desde sin código con Change Data Capture, low-code (más o menos) con flujos activados por registro y pro-code usando activadores de Apex. Elija cuidadosamente su solución de publicación de eventos.

Cuadro resumen

Sobre el Autor

Michael Norton es Arquitecto Técnico Distinguido en Salesforce y es Arquitecto Certificado de Implementación y Ciclo de Vida de Desarrollo, Arquitecto de Integración, Creador de Aplicaciones, Desarrollador de Plataforma I y II y Administrador. Tiene más de 30 años de experiencia en desarrollo de software y 14 años de implementación y experiencia en la plataforma Salesforce. Michael se unió a Salesforce en 2018 y le apasiona ayudar a los clientes a crear aplicaciones escalables y mantenibles.