Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Comprender la arquitectura de software basada en eventos

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

  • Especificar los componentes de una arquitectura de software basada en eventos.
  • Explicar las ventajas de una arquitectura de software basada en eventos.
  • Describir casos de uso de la función de eventos de plataforma.
  • Describir las características de un evento de plataforma.

Antes de empezar este módulo

¡Sabemos que está ansioso por empezar! Pero antes de ponerse manos a la obra en este módulo, debe estar familiarizado con algunos conceptos para completar este módulo. 

Este módulo le muestra cómo puede publicar eventos de plataforma empleando Apex, la API de REST, flujos y procesos. Además, este módulo le muestra cómo suscribirse a eventos de plataforma mediante desencadenadores de Apex, entre otros métodos. Para poder comprender este módulo, debe estar familiarizado con al menos una de estas tecnologías. Para poder realizar el reto práctico de este módulo, debe tener conocimientos de los desencadenadores de Apex. Esta es una lista de las rutas y módulos que puede realizar para aprender Apex.

Además, conocer los conceptos de publicación y suscripción de la API es útil para este módulo, pero no es obligatorio. Para obtener información sobre el modelo de publicación y suscripción de la API, consulte la Documentación del modelo de publicación y suscripción de la API.

Comprender la arquitectura de software basada en eventos

¿Ha enviado su sistema de pedidos un paquete? ¿Es necesario cambiar los cartuchos de la impresora? Con independencia del tipo de notificación que desee recibir, la plataforma de mensajería para compañías de Salesforce permite la entrega de notificaciones personalizadas de forma segura y ampliable en Salesforce y desde fuentes externas. Con los eventos de plataforma, puede monitorear sus sistemas y comunicar los cambios a otros sistemas.

El paradigma de la comunicación basada en eventos gira en torno a un modelo de publicador-suscriptor. Un remitente difunde un mensaje que uno o varios receptores capturan. El proceso es similar a la transmisión por radio, donde la torre del transmisor emite una señal de radio y los receptores reciben la señal si encuentran la frecuencia adecuada.

De un modo bastante parecido a la transmisión por radio, la comunicación basada en eventos fluye desde el remitente hasta el receptor. Los eventos se envían de forma asíncrona, más allá de que los receptores estén escuchando o no, y además los receptores no acusan recibo al recibir un evento. La comunicación basada en eventos ocurre en tiempo real o, para ser más exactos, prácticamente en tiempo real. Las ondas de radio viajan a la velocidad de la luz, pero en los sistemas de software y hardware basados en eventos se suele observar determinada latencia. 

En el módulo Platform API Basics Trailhead, utilizamos la analogía del radar en el barco de un pirata para representar la detección de eventos. Esta analogía funciona bien para la transmisión de eventos de captura de datos de cambios, que se basan en cambios en los registros de Salesforce. Este modelo de comunicación requiere tan solo un suscriptor. Sin embargo, en el caso de los eventos de plataforma, intervienen dos partes en la comunicación: un remitente y un receptor. Estos son dos de los componentes de una arquitectura basada en eventos.

Componentes de los sistemas basados en eventos

Antes de avanzar, vamos a definir algunos términos.

Evento

Es un cambio de estado significativo en un proceso de negocio. Por ejemplo, la generación de un pedido de compra es un evento significativo, ya que el centro de procesamiento de pedidos espera recibir una notificación antes de procesar el pedido.

Mensaje de evento

Es un mensaje que contiene datos sobre el evento. Se llama también notificación de evento. Por ejemplo, un mensaje de evento puede ser una notificación de la generación de un pedido que contiene información sobre el pedido.

Productor de eventos

Es el publicador de un mensaje de evento. Por ejemplo, puede ser una aplicación de generación de pedidos.

Canal de eventos

Es una transmisión de eventos en la que un productor de eventos envía mensajes de eventos y los consumidores de eventos leen estos mensajes. Para eventos de plataforma, el canal es para un evento de plataforma o un canal personalizado que agrupa mensajes de eventos para varios eventos de plataforma.

Consumidor de eventos

Es un suscriptor de un canal que recibe mensajes del canal. Por ejemplo, puede ser una aplicación de procesamiento de pedidos que recibe notificaciones de nuevos pedidos.

Bus de eventos

Un servicio de entrega y almacenamiento de eventos de múltiples nubes y arrendatarios que se basa en un modelo de publicación-suscripción. El bus de eventos activa la recuperación de mensajes de eventos almacenados en cualquier momento durante el plazo de retención. El bus de eventos se basa en un registro de eventos ordenado por hora, lo que garantiza el almacenamiento y la entrega de los mensajes de eventos en el orden en que los recibió Salesforce.

En el siguiente diagrama se muestra una arquitectura de software basada en eventos.

A diferencia de los modelos de comunicación de solicitud y respuesta, la arquitectura de software basada en un modelo controlado por eventos desvincula los productores de eventos de los consumidores de eventos, lo que simplifica el modelo de comunicación en los sistemas conectados. No es necesario realizar solicitudes en un servidor para obtener información sobre un estado concreto. En lugar de esto, un sistema se suscribe a un canal de eventos y recibe una notificación siempre que se genera un estado nuevo. Se admite cualquier número de consumidores, los cuales reciben y reaccionan a los mismos eventos. Cuando se genera un evento, los sistemas obtienen esta información y tienen capacidad para reaccionar prácticamente en tiempo real. Los sistemas que envían eventos y los sistemas que reciben eventos no tienen dependencias entre sí, a excepción de la semántica del contenido del mensaje.

La plataforma de mensajería de negocio de Salesforce ofrece las ventajas de la arquitectura de software basada en eventos. Los eventos de plataforma son los mensajes de eventos que sus aplicaciones envían y reciben. Simplifican el proceso de comunicación de cambios y la respuesta correspondiente sin necesidad de escribir ninguna lógica compleja. Los publicadores y suscriptores se comunican entre sí mediante eventos de plataforma. Uno o varios suscriptores pueden escuchar el mismo evento y realizar acciones.

Supongamos que una agencia de noticias llamada Cloud News envía eventos a los clientes suscritos con las últimas noticias sobre el tráfico y las condiciones de la carretera para llegar a un refugio en la montaña. Los contenidos de estos eventos no son solamente noticias, sino también detalles relacionados, como una noticia urgente o el lugar de un incidente. Los suscriptores pueden recibir estos eventos y determinar qué acciones realizar según la urgencia de las noticias.

Todo esto suena muy bien, ¿pero en qué casos reales se podrían usar los eventos de plataforma? Por supuesto, el uso de los eventos de plataforma no se limita a una agencia de noticias. A continuación, veremos algunas aplicaciones útiles.

Ejemplos de uso de eventos de plataforma

Veamos algunos escenarios de negocio en los que se usan los eventos de plataforma. En estos escenarios, Salesforce y los sistemas externos se comunican mediante mensajes de eventos de plataforma. En el primer escenario, una aplicación de Salesforce envía una notificación sobre un pedido de envío de productos a una serie de aplicaciones de procesamiento de pedidos externas. En el segundo escenario, una aplicación de productos externa envía una notificación a Salesforce sobre una devolución de mercancía. En el último escenario, se muestra cómo se usan los mensajes de eventos en Salesforce mediante desencadenadores.

Desde una plataforma a una aplicación externa: procesamiento de pedidos en la aplicación de un proveedor

Cuando se cierra una oportunidad como ganada en Salesforce, su compañía ha conseguido una negociación con un cliente. Supongamos que recurre a proveedores para el envío de los productos asociados a una oportunidad. Cada proveedor tiene una aplicación externa que procesa los pedidos de envío para productos específicos. La aplicación externa escucha los eventos de plataforma. Cuando se cierra una oportunidad, se activa un desencadenador, que forma parte de una aplicación de pedidos de productos de Salesforce, y se publica un mensaje de evento de plataforma. Cada aplicación de proveedor recibe una notificación del evento. El proveedor responsable de enviar el producto específico crea el envío.

Desde una aplicación externa a una aplicación de plataforma: procesamiento de devoluciones de mercancías en Salesforce

Supongamos que alguien desea devolver la mercancía adquirida a un proveedor. Un sistema externo envía solicitudes de devolución de mercancía a Salesforce para su procesamiento. El sistema externo publica un evento de plataforma para alertar a Salesforce de la devolución de la mercancía. Un proceso de escucha de eventos (desencadenador) de Salesforce recibe el evento y realiza algunas acciones. Por ejemplo, el desencadenador puede alertar al representante de ventas de la devolución y enviar un email de confirmación al cliente.

Desde una plataforma a otra plataforma: reasignación de registros de prospectos

Cuando se asigna un prospecto en Salesforce, se activa un desencadenador de prospecto y se comprueban las oportunidades abiertas y los casos relacionados con el propietario del prospecto. En función de los registros relacionados, el desencadenador publica un evento que es recibido por una aplicación de Salesforce. De acuerdo con la información del evento, la aplicación reasigna el prospecto y crea una publicación de Chatter.

En este caso, puede realizar las mismas acciones mediante Flow Builder. Sin embargo, si usa eventos de plataforma, puede aprovechar las ventajas de un modelo de programación basado en eventos y un método estándar de programación en sus aplicaciones.

Características de los eventos de plataforma

Ahora que ya tiene una idea sobre cuándo usar los eventos de plataforma, vamos a profundizar en sus componentes y características.

Puede definir los datos personalizados contenidos en los eventos de plataforma. Como en el caso de los objetos personalizados, puede definir eventos de plataforma en Salesforce. Para crear una definición de evento de plataforma, asígnele un nombre y agregue campos personalizados. La siguiente es una definición de ejemplo de los campos personalizados de un evento de noticias para la agencia Cloud News.

Etiqueta de campo/Nombre de campo

Nombre API del campo

Tipo de campo

Ubicación

Location__c

Texto

Longitud: 100

Urgente

Urgent__c

Casilla

Contenido de noticias

News_Content__c

Área de texto (largo)

Eventos de plataforma y objetos de Salesforce

Un evento de plataforma es un tipo de entidad especial de Salesforce, similar en muchos aspectos a un objeto de Salesforce. Un mensaje de evento es una instancia de un evento de plataforma, lo cual es similar a un registro que tiene como instancia un objeto de Salesforce. A diferencia de los registros, no puede actualizar o eliminar mensajes de evento y tampoco puede verlos en la interfaz de usuario de Salesforce.

Puede establecer permisos de lectura y creación para los eventos de plataforma. Además, puede conceder permisos a los usuarios en perfiles o en conjuntos de permisos.

Uso de eventos de plataforma en aplicaciones nativas y externas

Los eventos de plataforma permiten el flujo de mensajes de eventos en Salesforce o hacia y desde aplicaciones externas. Las aplicaciones de Salesforce Platform usan un método Apex para publicar eventos y un desencadenador de Apex o el componente Lightning de Emp API para consumir eventos. Como alternativa al código, puede publicar eventos con la herramienta declarativa Flow Builder. Las aplicaciones externas publican eventos usando el modelo de publicación y suscripción de la API o las API de datos, y consumen eventos mediante el modelo de publicación y suscripción de la API. Como puede ver, el grado de flexibilidad es considerable a la hora de elegir cómo usar los eventos de plataforma.

Utilice eventos de plataforma en estos casos:

  • Para enviar y recibir datos de eventos personalizados con un esquema predefinido.
  • Para publicar o suscribirse a eventos en Apex.
  • Para tener la flexibilidad necesaria en la publicación y el procesamiento de eventos dentro y fuera de Salesforce Platform.
Nota

Otro tipo de evento de flujo es un evento de captura de datos de cambio. Este evento contiene cambios de registros de Salesforce para operaciones de creación, actualización, eliminación y anulación de eliminación.  Para obtener más información, consulte el módulo de Trailhead Fundamentos de Cambiar captura de datos.

En la siguiente unidad, analizaremos la definición de un evento de plataforma y la publicación de eventos.

Recursos

Comparta sus comentarios de Trailhead en la Ayuda de Salesforce.

Nos encantaría saber más sobre su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios en cualquier momento en el sitio de Ayuda de Salesforce.

Más información Continuar a Compartir comentarios