Empiece a realizar un seguimiento de su progreso
Inicio de Trailhead
Inicio de Trailhead

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. Del mismo modo, puede suscribirse a eventos de plataforma empleando desencadenadores, flujos, procesos de Apex, un componente Lightning y una herramienta basada en CometD. 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.

Del mismo modo, estar familiarizado con los conceptos de la API de transmisión es útil para este módulo. Si aún no lo ha hecho, complete el módulo Fundamentos de la API de la plataforma Lightning antes de empezar a trabajar en este módulo.

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 con independencia 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 Fundamentos de la API de Lightning Platform, usamos como analogía el radar de un barco pirata para representar la detección de eventos. Esta analogía funciona bien para la transmisión de eventos de envío de tema, los cuales 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 evento
Es el publicador de un mensaje de evento en un canal. Por ejemplo, puede ser una aplicación de generación de pedidos.

Canal de evento
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.

Consumidor de evento
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.

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

Diagrama en el que se muestran componentes de sistemas basados en eventos: los productores de eventos pasan información al bus de eventos, el cual envía mensajes a los consumidores de 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 en Salesforce, su compañía ha ganado en 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. 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 y crea un pedido de envío para un producto específico.

En este diagrama, una aplicación de pedidos de productos publica un evento de pedido en un bus de eventos. Varias aplicaciones de proveedores están suscritas al bus de eventos y reciben el evento.

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.

Una aplicación de proveedor externa publica un mensaje de evento de plataforma para una solicitud de devolución de mercancía. En Salesforce, un desencadenador se suscribe al bus de eventos y recibe el evento.

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 escenario, puede realizar las mismas acciones con otras funciones de Salesforce, como Process Builder o los flujos. 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.

En este diagrama, una aplicación de Salesforce publica un evento de plataforma. Un desencadenador se suscribe a este canal de eventos y recibe el evento.

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 Longitud
del texto: 100
Urgente Urgent__c Casilla
Contenido de noticias News_Content__c Área de texto (largo)

Eventos de plataforma y sObjects

Un evento de plataforma es un tipo de entidad especial de Salesforce, similar en muchos aspectos a un sObject. 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 personalizado. A diferencia de los objetos personalizados, no puede actualizar o eliminar registros de eventos 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 la plataforma de Salesforce usan un método Apex para publicar eventos y un desencadenador de Apex o el componente Lightning empApi para consumir eventos. Como alternativa al código, puede publicar eventos con herramientas declarativas, como Process Builder y Flow Builder. Las aplicaciones externas publican eventos utilizando la API de sObject y consumen eventos empleando CometD. Como puede ver, el grado de flexibilidad es considerable a la hora de elegir cómo usar los eventos de plataforma.

Diferencias entre los eventos de plataforma y otros eventos de transmisión

¿Qué sabemos acerca de otros eventos de transmisión? Algunos otros eventos son los eventos genéricos y de envío de tema. En el caso de los eventos de envío de tema, los clientes reciben mensajes sobre los cambios en los registros de Salesforce en función de una consulta predefinida. Los eventos genéricos le permiten enviar y recibir el contenido de los mensajes de forma arbitraria (cargas) y no están vinculados necesariamente a los registros de Salesforce. Los eventos de plataforma son similares a los eventos genéricos, pero permiten una personalización más eficiente. Con los eventos de plataforma, puede publicar cualquier dato personalizado. Puede definir el esquema de los datos de un evento con el mismo nivel de granularidad que los campos tipificados. Además, puede usar eventos de plataforma tanto en aplicaciones de plataforma de Salesforce nativas como en aplicaciones externas. Use eventos de plataforma en los siguientes 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 para la publicación y el procesamiento de eventos dentro y fuera de la plataforma de Salesforce.

En la tabla siguiente se comparan las funciones de los eventos genéricos y los eventos de plataforma.

Función Evento genérico Evento de plataforma
Definir un esquema de eventos como campos tipificados
Marca de activación
Incluir cargas definidas por el usuario Marca de activación Marca de activación
Publicar eventos mediante una o varias API Marca de activación Marca de activación
Publicar eventos mediante Apex
Marca de activación
Suscribirse mediante CometD Marca de activación Marca de activación
Suscribirse mediante desencadenadores de Apex
Marca de activación
Publicar de forma declarativa mediante Process Builder y Flow Builder
Marca de activación
Nota

Nota

Para ver una comparativa de más tipos de eventos, consulte Funciones de eventos de transmisión en la Guía del desarrollador de la API de transmisión.

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