Este texto se tradujo utilizando el sistema de traducción automatizado de Salesforce. Realice nuestra encuesta para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación.

Normalmente, cuando implementa Salesforce, necesita integrarlo con otras aplicaciones. Aunque cada escenario de integración es único, existen problemas y requisitos comunes que los desarrolladores y arquitectos deben resolver.

Este documento describe estrategias (en forma de patrones) para estos escenarios de integración comunes. Cada patrón describe el diseño y el enfoque para un escenario concreto en vez de detallar una implementación específica. En este documento encontrará:

  • Un número de patrones que tratan escenarios de integración de “arquetipos” clave
  • Una matriz de selección para ayudar a determinar qué patrón se ajusta mejor a su escenario
  • Sugerencias y mejores prácticas de integración

Objetivo y ámbito

Este documento es para diseñadores y arquitectos que necesitan integrar Salesforce Platform con otras aplicaciones en su compañía. Este contenido es una destilación de muchas implementaciones correctas por arquitectos y socios de Salesforce.

Para familiarizarse con las funciones y opciones de integración disponibles para la adopción a gran escala de aplicaciones basadas en Salesforce, lea Resumen de patrón y Guía de selección de patrón. Los arquitectos y desarrolladores deben tener en cuenta estos detalles de patrón y mejores prácticas durante la fase de diseño e implementación de un proyecto de integración de Salesforce.

Si se implementan correctamente, estos patrones le permiten llegar a producción lo más rápido posible y tener el conjunto de aplicaciones más estable, ampliable y sin mantenimiento posible. Los propios arquitectos consultores de Salesforce utilizan estos patrones como puntos de referencia durante revisiones arquitectónicas y los mantienen y mejoran activamente.

Como con todos los patrones, este contenido cubre la mayoría de los escenarios de integración, pero no todos. Aunque Salesforce permite la integración de la interfaz de usuario (UI), mashups, por ejemplo, dicha integración está fuera del ámbito de este documento.

Plantilla de patrón

Cada patrón de integración sigue una estructura coherente. Esto proporciona coherencia en la información proporcionada en cada patrón y también facilita la comparación de patrones.

Nombre

El identificador de patrón que también indica el tipo de integración contenida en el patrón.

Context

Escenario de integración general que soluciona el patrón. El contexto proporciona información acerca de lo que los usuarios están intentando lograr y cómo se comportará la aplicación para dar cobertura a los requisitos.

Problema

El escenario o problema (expresado como una pregunta) para el que está diseñado el patrón. Cuando revise los patrones, lea esta sección para comprender rápidamente si el patrón es apropiado para su escenario de integración.

Fuerzas

Las restricciones y circunstancias que hacen que el escenario establecido sea difícil de resolver.

Solución

La forma recomendada de resolver el escenario de integración.

Boceto

Un diagrama de secuencia UML que le muestra cómo la solución aborda el escenario.

Resultados

Explica los detalles de cómo aplicar la solución a su escenario de integración y cómo resuelve las fuerzas asociadas con ese escenario. Esta sección también contiene nuevos retos que pueden surgir como resultado de la aplicación del patrón.

Barras laterales

Secciones adicionales relacionadas con el patrón que contienen problemas técnicos clave, variaciones del patrón, problemas específicos del patrón, etc.

Ejemplo

Un escenario de extremo a extremo que describe cómo se utiliza el patrón de diseño en un escenario de Salesforce real. El ejemplo explica los objetivos de integración y cómo implementar el patrón para alcanzar esos objetivos.

Resumen de patrón

La siguiente tabla enumera los patrones de integración contenidos en este documento.

Lista de patrones remote-process-invocation--request-and-reply

Patrones Escenario
Invocación de proceso remoto: Solicitud y respuesta Salesforce invoca un proceso en un sistema remoto, espera la finalización de ese proceso y luego realiza un seguimiento del estado basándose en la respuesta del sistema remoto.
Invocación de procesos remotos: Disparar y olvidar Salesforce invoca un proceso en un sistema remoto pero no espera a la finalización del proceso. En su lugar, el proceso remoto recibe y confirma la solicitud y luego devuelve el control a Salesforce.
Sincronización de datos por lotes Los datos almacenados en Lightning Platform se crean o actualizan para reflejar actualizaciones desde un sistema externo, y cuando se envían cambios desde Lightning Platform a un sistema externo. Las actualizaciones en cualquier dirección se realizan de forma por lotes.
Llamada remota Los datos almacenados en Salesforce Platform se crean, recuperan, actualizan o eliminan por un sistema remoto.
Actualización de interfaz de usuario basada en cambios de datos La interfaz de usuario de Salesforce debe actualizarse automáticamente como resultado de cambios en datos de Salesforce.
Virtualización de datos Salesforce accede a datos externos en tiempo real. Esto elimina la necesidad de mantener los datos en Salesforce y luego conciliar los datos entre Salesforce y el sistema externo.

Enfoque de patrón

Los patrones de integración de este documento se clasifican en tres categorías:

  • Integración de datos: Estos patrones abordan el requisito de sincronizar datos que residen en dos o más sistemas de modo que ambos sistemas siempre contengan datos oportunos y significativos. La integración de datos es a menudo el tipo de integración más sencillo de implementar, pero requiere técnicas de gestión de información adecuadas para que la solución sea sostenible y rentable. Tales técnicas a menudo incluyen aspectos de la gestión de datos principales (MDM), la gobernanza de datos, la masterización, la desduplicación, el diseño de flujos de datos y otros.

  • Integración de procesos: Los patrones de esta categoría abordan la necesidad de que un proceso de negocio aproveche dos o más aplicaciones para completar su tarea. Cuando implementa una solución para este tipo de integración, la aplicación que desencadena debe realizar una llamada a través de los límites del proceso a otras aplicaciones. Habitualmente, estos patrones también incluyen tanto orquestación (donde una aplicación es el “controlador” central) como coreografía (donde las aplicaciones son de múltiples participantes y no hay un “controlador” central). Estas integraciones a menudo requieren requisitos complejos de diseño, pruebas y gestión de excepciones. Del mismo modo, dichas aplicaciones compuestas son normalmente más exigentes en los sistemas subyacentes porque a menudo admiten transacciones de larga ejecución y la capacidad de crear reportes o gestionar el estado del proceso.

  • Integración virtual: Los patrones de esta categoría solucionan la necesidad de que un usuario vea, busque y modifique datos almacenados en un sistema externo. Cuando implementa una solución para este tipo de integración, la aplicación que desencadena debe llamar a otras aplicaciones e interactuar con sus datos en tiempo real. Este tipo de integración elimina la necesidad de replicación de datos entre sistemas y significa que los usuarios siempre interactúan con los datos más actuales.

La selección de la mejor estrategia de integración para su sistema no es trivial. Existen muchos aspectos a tener en cuenta y muchas herramientas que se pueden utilizar, siendo algunas herramientas más apropiadas que otras para ciertas tareas. Cada patrón aborda áreas críticas específicas incluyendo las funciones de cada uno de los sistemas, el volumen de datos, la gestión de fallos y la transaccionalidad.

Guía de selección de patrones

Las tablas matriciales de selección enumeran los patrones y sus aspectos clave para ayudarle a determinar qué patrón se ajusta mejor a sus requisitos de integración. Los patrones se categorizan utilizando estas dimensiones.

Aspecto Descripción
Tipo Especifica el estilo de integración: Proceso, Datos o Virtual.
  • Proceso: Las integraciones basadas en procesos son formas de integrar el procesamiento de flujos funcionales entre dos o más aplicaciones. Estas integraciones normalmente implican un mayor nivel de abstracción y complejidad, especialmente para la transaccionalidad y la reversión.
  • Datos: Las integraciones de datos son la integración de la información utilizada por las aplicaciones. Estas integraciones pueden variar desde un simple inserto o alteración de tabla a actualizaciones de datos complejas que requieren integridad referencial y traducciones complejas.
  • Virtual: Las integraciones virtuales son donde Salesforce interactúa con datos que residen en un sistema externo sin necesidad de replicar los datos que están dentro de Salesforce. Este tipo de integración siempre se desencadena a través de un evento desde Salesforce Platform como una acción de usuario, búsqueda o actualización de registro, dando como resultado la integración de datos con una fuente externa en tiempo real.
Cronología Especifica el estilo de integración: Proceso, Datos o Virtual.
  • Síncrono: El bloqueo y las solicitudes en tiempo real son operaciones de solicitud/respuesta. El resultado se devuelve a la persona que llama inmediatamente a través de esta operación.
  • Asíncrono: Las solicitudes no bloqueadas, en cola o basadas en mensajes se invocan por una operación unidireccional que es casi en tiempo real. Los resultados y cualquier fallo se devuelven invocando otras operaciones unidireccionales.Por lo tanto, el llamante realiza la solicitud y continúa sin esperar una respuesta.

Integración de Salesforce con otro sistema

Esta tabla enumera los patrones y sus aspectos clave para ayudarle a determinar qué patrón se ajusta mejor a sus requisitos cuando su integración es desde Salesforce a otro sistema.

Tipo Cronología Patrón clave a tener en cuenta
Integración de procesos Síncrono Invocación de proceso remoto: Solicitud y respuesta
Integración de procesos Asíncrono Invocación de procesos remotos: Disparar y olvidar
Integración de datos Síncrono Invocación de proceso remoto: Solicitud y respuesta
Integración de datos Asíncrono Actualización de interfaz de usuario basada en cambios de datos
Integración virtual Síncrono Virtualización de datos

Integración de otro sistema con Salesforce

Esta tabla enumera los patrones y sus aspectos clave para ayudarle a determinar el patrón que mejor se ajusta a sus requisitos cuando su integración es desde otro sistema en Salesforce.

Tipo Cronología Patrón clave a tener en cuenta
Integración de procesos Síncrono Llamada remota
Integración de procesos Asíncrono Llamada remota
Integración de datos Síncrono Llamada remota
Integración de datos Asíncrono Sincronización de datos por lotes

Términos y definiciones de middleware

Esta tabla enumera algunos términos clave relacionados con middleware y sus definiciones con respecto a estos patrones.

Plazo Definición
Gestión de eventos La gestión de eventos es la recepción de una incidencia identificable en un receptor designado (“controlador”). Los procesos clave implicados en la gestión de eventos incluyen:

  • Identificación de dónde reenviar un evento
  • Ejecución de esa acción de reenvío
  • Recepción de un evento reenviado
  • Realizar algún tipo de acción apropiada en respuesta, como escribir en un registro, enviar un error o un proceso de recuperación o enviar un mensaje adicional

Recuerde que el controlador de eventos puede en última instancia reenviar el evento a un consumidor de eventos.

Los usos comunes de esta función con middleware pueden ampliarse para incluir la popular función “publish/subscribe” o “pub/sub”. En un escenario de publicación/suscripción, el middleware enruta solicitudes o mensajes a suscriptores de eventos de datos activos desde publicadores de eventos de datos activos. Estos consumidores con oyentes activos pueden recuperar los eventos a medida que se publican.
En integraciones de Salesforce que utilizan middleware, la capa de middleware asume el control de la gestión de eventos. Recopila todos los eventos relevantes, síncronos o asíncronos, y gestiona la distribución a todos los extremos, incluyendo Salesforce.

De manera alternativa, esta función se puede lograr con la plataforma de mensajería de compañía Salesforce utilizando el bus de eventos con eventos de plataforma.
Conversión de protocolo La conversión de protocolos es normalmente una aplicación de software que convierte el protocolo estándar o propietario de un dispositivo en el protocolo adecuado para que otro dispositivo alcance la interoperabilidad.

En el contexto del middleware, la conectividad a un sistema de destino concreto puede estar restringida por el protocolo. En estos casos, el formato del mensaje debe convertirse o encapsularse en el formato del sistema de destino, donde se puede extraer la carga. Esto también se conoce como tunelización.
Salesforce no admite la conversión de protocolos nativos, por lo que se supone que la capa de middleware o el extremo cumplen cualquiera de estos requisitos.
Traducción y transformación La transformación es la capacidad de asignar un formato de datos a otro para garantizar la interoperabilidad entre los diversos sistemas que se están integrando. Habitualmente, el proceso implica dar nuevo formato a mensajes en ruta para coincidir con los requisitos del remitente o destinatario. En casos más complejos, una aplicación puede enviar un mensaje en su propio formato nativo, y otras dos o más aplicaciones pueden recibir una copia del mensaje en su propio formato nativo.

Las herramientas de transformación y traducción de middleware a menudo incluyen la capacidad de crear fachadas de servicio para extremos heredados u otros no estándar. Estas fachadas de servicio permiten que esos extremos aparezcan como direccionables por servicio.

Con integraciones de Salesforce, se asume que cualquiera de estos requisitos se cumple por la capa de middleware o el extremo. La transformación de datos se puede codificar en Apex, pero no se recomienda debido a consideraciones de mantenimiento y desempeño.
Colocación en cola y almacenamiento intermedio La colocación en cola y el almacenamiento en búfer generalmente se basan en el paso de mensajes asíncronos, en contraposición a una arquitectura de solicitud-respuesta. En sistemas asíncronos, las colas de mensajes proporcionan almacenamiento temporal cuando el programa de destino está ocupado o la conectividad está comprometida. Además, la mayoría de los sistemas de middleware asíncronos proporcionan almacenamiento persistente para realizar una copia de seguridad de la cola de mensajes.

El beneficio clave de un proceso de mensajes asíncronos es que si la aplicación del receptor falla por cualquier motivo, los remitentes pueden continuar sin verse afectados. Los mensajes enviados simplemente se acumulan en la cola de mensajes para su posterior procesamiento cuando se reinicia el receptor.
Salesforce solo proporciona capacidad de colocación en cola explícita en forma de mensajería saliente basada en flujo de trabajo. Para proporcionar colas de mensajes verdaderas para otros escenarios de integración, incluyendo orquestación, coreografía de procesos y calidad de servicio, se requiere una solución de middleware.
Protocolos de transporte síncronos Los protocolos de transporte síncronos hacen referencia a protocolos que admiten actividades en las que un “único hilo en el llamante envía el mensaje de solicitud, bloquea la espera del mensaje de respuesta y luego procesa la respuesta....El hilo de solicitud que espera la respuesta implica que solo hay una solicitud pendiente o que el canal de respuesta para esta solicitud es privado para este hilo”.
Protocolos de transporte asíncronos Los protocolos de transporte asíncronos hacen referencia a protocolos que admiten actividades en las que “un hilo de la persona que llama envía el mensaje de solicitud y configura una devolución de llamada para la respuesta. Un hilo separado escucha los mensajes de respuesta. Cuando llega un mensaje de respuesta, el hilo de respuesta invoca la devolución de llamada apropiada, que restablece el contexto de la persona que llama y procesa la respuesta. Este enfoque permite múltiples solicitudes pendientes para compartir un único hilo de respuesta.”
Enrutamiento de mediación El enrutamiento de mediación es la especificación de un “flujo” complejo de mensajes de componente a componente. Por ejemplo, muchas soluciones basadas en middleware dependen de un sistema de colas de mensajes. Aunque algunas implementaciones permiten proporcionar lógica de enrutamiento por la propia capa de mensajería, otras dependen de aplicaciones cliente para proporcionar información de enrutamiento o permitir una mezcla de ambos paradigmas. En casos tan complejos, la mediación por parte del middleware simplifica el desarrollo, la integración y la validación. coordinador [Mediador] podría asegurarse de que el mensaje correcto llega al consumidor correcto”.
Coreografía de procesos y orquestación de servicios La coreografía de procesos y la orquestación de servicios son formas de “composición de servicio” donde se están coordinando cualquier número de extremos y funciones.

La diferencia entre coreografía y orquestación de servicio es:
  • La coreografía se puede definir como un enfoque asíncrono que permite a los procesos trabajar de forma autónoma, eliminando cualquier problema causado por dependencias que es el comportamiento resultante de un grupo de entidades individuales que interactúan sin autoridad central.
  • La orquestación se puede definir como un enfoque síncrono que permite la ejecución de una consulta o proceso permitiendo a cada microservicio implementar tareas asignadas por el orquestador que es el comportamiento resultante de un director central coordinando los comportamientos de entidades individuales que realizan tareas independientes entre sí.
Además, una orquestación muestra el comportamiento completo de cada servicio mientras que la coreografía combina las descripciones de comportamiento de interfaz de cada servicio.
Partes de las coreografías de procesos de negocio se pueden crear en flujos de trabajo de Salesforce o utilizando Apex. Recomendamos que todas las orquestaciones complejas se implementen en la capa de middleware debido a los valores de tiempo de espera de Salesforce y los límites reguladores, especialmente en soluciones que requieren una verdadera gestión de transacciones.
Transaccionalidad (cifrado, firma, entrega fiable, gestión de transacciones) La transaccionalidad se puede definir como la capacidad de admitir transacciones globales que abarcan todas las operaciones necesarias en cada recurso requerido. La transaccionalidad implica el soporte de las cuatro propiedades ACID, atomicidad, consistencia, aislamiento, durabilidad, donde la atomicidad garantiza resultados de todo o nada para la unidad de trabajo (transacción).

Aunque Salesforce es transaccional dentro de sí mismo, no puede participar en transacciones distribuidas o transacciones iniciadas fuera de Salesforce. Por lo tanto, se asume que para soluciones que requieren transacciones complejas y multisistema, la transaccionalidad y los mecanismos de reversión/compensación asociados se implementan en la capa de middleware.
Enrutamiento El enrutamiento se puede definir como la especificación del flujo complejo de mensajes de componente a componente. En soluciones basadas en servicios modernas, dichos flujos de mensajes pueden basarse en una serie de criterios, incluyendo encabezado, tipo de contenido, regla y prioridad.

Con integraciones de Salesforce, se asume que cualquiera de estos requisitos se cumple por la capa de middleware o el extremo. El enrutamiento de mensajes puede codificarse en Apex, pero no lo recomendamos debido a consideraciones de mantenimiento y desempeño.
Extraer, transformar y cargar Extraer, transformar y cargar (ETL) hace referencia a un proceso que implica:
  • Extracción de datos desde los sistemas de origen. Este proceso suele implicar datos de varios sistemas de origen y estructuras relacionales y no relacionales.
  • Transformación de los datos para ajustarse a necesidades operativas, que pueden incluir niveles de calidad de datos. La etapa de transformación normalmente aplica una serie de reglas o funciones a los datos extraídos desde el origen para derivar los datos para cargar en los destinos finales.
  • Carga de los datos en el sistema de destino. El sistema de destino puede variar ampliamente de base de datos, almacén de datos operativo, almacén de datos u otros sistemas operativos.
Aunque no son estrictamente necesarias, la mayoría de las herramientas ETL maduras proporcionan una Captura de datos de cambios. Esta función es donde la herramienta identifica registros en el sistema de origen que cambiaron desde la última extracción, lo que reduce la cantidad de procesamiento de registros.

Salesforce ahora también admite Captura de datos de cambios, que es la publicación de eventos de cambio que representan cambios en registros de Salesforce. Con Captura de datos de cambios, el sistema cliente o externo recibe cambios casi en tiempo real de registros de Salesforce. Con esta información, el cliente o el sistema externo puede sincronizar registros correspondientes en un almacén de datos externo.
Sondeo largo Sondeo largo, también denominado programación Comet, emula un envío de información desde un servidor a un cliente. Al igual que un sondeo normal, el cliente conecta y solicita información al servidor. Sin embargo, en vez de enviar una respuesta vacía si la información no está disponible, el servidor mantiene la solicitud y espera hasta que la información esté disponible (se produce un evento). El servidor envía a continuación una respuesta completa al cliente. El cliente vuelve a solicitar información inmediatamente. El cliente mantiene continuamente una conexión con el servidor, de modo que siempre está esperando recibir una respuesta. Si se agota el tiempo de espera del servidor, el cliente se conecta de nuevo y comienza de nuevo.

La API de transmisión de Salesforce utiliza el protocolo Bayeux y CometD para sondeos largos.
  • Bayeux es un protocolo para transportar mensajes asíncronos, principalmente a través de HTTP.
  • CometD es un bus de enrutamiento de eventos basado en HTTP ampliable que utiliza un patrón de tecnología distribuida AJAX conocido como Comet. Implementa el protocolo Bayeux.

Context

Utiliza Salesforce para realizar un seguimiento de prospectos, gestionar sus oportunidades en curso, crear oportunidades y capturar detalles de pedidos que convierten prospectos en clientes. Pero el sistema de Salesforce no contiene ni procesa pedidos. Después de capturar los detalles del pedido en Salesforce, el pedido se crea en el sistema remoto, que gestiona el pedido hasta su conclusión.

Cuando implementa este patrón, Salesforce llama al sistema remoto para crear el pedido y luego espera que se complete correctamente. Si se realiza correctamente, el sistema remoto responde de forma síncrona con el estado del pedido y el número de pedido. Como parte de la misma transacción, Salesforce actualiza el número de pedido y el estado de forma interna. El número de pedido se utiliza como una clave externa para actualizaciones posteriores en el sistema remoto.

Problema

Cuando se produce un evento en Salesforce, ¿cómo iniciar un proceso en un sistema remoto, pasar la información requerida a ese proceso, recibir una respuesta del sistema remoto y luego utilizar esos datos de respuesta para realizar actualizaciones en Salesforce?

Fuerzas

Tenga en cuenta las siguientes fuerzas al aplicar soluciones basadas en este patrón.

  • ¿Requiere la llamada al sistema remoto que Salesforce espere una respuesta antes de continuar el procesamiento? ¿Es la llamada al sistema remoto una solicitud-respuesta síncrona o una solicitud asíncrona?
  • Si la llamada al sistema remoto es síncrona, ¿tiene Salesforce que procesar la respuesta como parte de la misma transacción que la llamada inicial?
  • ¿El tamaño del mensaje es pequeño o grande?
  • ¿Se basa la integración en la aparición de un evento específico, como un clic de botón en la interfaz de usuario de Salesforce o eventos basados en DML?
  • ¿El extremo remoto puede responder a la solicitud con baja latencia? ¿Cuántos usuarios tienen probabilidad de ejecutar esta transacción durante un periodo de pico?

Solución

Esta tabla contiene soluciones a este problema de integración.

Solución Ajuste Comentarios
Servicios externos invoca una llamada de API de REST Mejor Servicios externos le permite invocar un servicio alojado de forma externa de forma declarativa (no se requiere código). Esta función se utiliza mejor cuando se cumplen las siguientes condiciones:
  • El servicio alojado de forma externa es un servicio RESTful y las definiciones están disponibles en un formato de esquema OpenAPI 2.0 u OpenAPI 3.0 o YAML.
  • Las definiciones de solicitud y respuesta contienen tipos de datos primitivos como booleano, fecha y hora, doble, entero, cadena o una matriz de tipos de datos primitivos. Se admiten los tipos de objetos anidados y los parámetros de envío como encabezados en las solicitudes HTTP.
  • La transacción se puede invocar desde un flujo.
Salesforce Lightning: El componente o la página Lightning inicia una llamada de REST o SOAP de Apex síncrona.</

Si el extremo remoto supone un riesgo de respuesta de alta latencia (consulte la documentación de límites más recientes para los límites aplicables aquí), se recomienda una llamada asíncrona, también llamada continuación, para evitar alcanzar límites reguladores de transacciones Apex síncronos. 		Mejor Salesforce le permite consumir un WSDL y generar una clase Apex proxy resultante. Esta clase proporciona la lógica necesaria para llamar al servicio remoto.

Salesforce también le permite invocar servicios HTTP (REST) utilizando métodos GET, POST, PUT y DELETE estándar.

Una acción iniciada por el usuario en una página Lightning luego llama a una acción del controlador Apex que luego ejecuta esta clase Apex proxy para realizar la llamada remota. Las páginas Lightning requieren la personalización de la aplicación Salesforce.
Un desencadenador síncrono invocado desde cambios de datos de Salesforce realiza una llamada asíncrona de SOAP Apex o HTTP. Suboptimal Puede utilizar desencadenadores Apex para realizar la automatización basándose en cambios de datos de registro.

Se puede ejecutar una clase de proxy Apex como resultado de una operación DML utilizando un desencadenador Apex. Sin embargo, todas las llamadas realizadas desde el contexto del desencadenador deben ejecutarse de forma asíncrona desde el evento que inicia. Por lo tanto, no se recomienda esta solución para este problema de integración. Esta solución se adapta mejor al patrón Invocación de proceso remoto: Disparar y olvidar.
Un trabajo Apex por lotes realiza una llamada síncrona SOAP o HTTP de Apex. Suboptimal Puede realizar llamadas a un sistema remoto desde un trabajo por lotes. Esta solución permite la ejecución de procesos remotos por lotes y el procesamiento de la respuesta desde el sistema remoto en Salesforce. Sin embargo, un lote concreto tiene límites en el número de llamadas. Para obtener más información, consulte Límites reguladores.

Una ejecución por lotes determinada puede ejecutar múltiples contextos de transacciones (normalmente en intervalos de 200 registros). Los límites reguladores se restablecen por contexto de transacción.

Boceto

Este diagrama ilustra una invocación de proceso remoto síncrono utilizando llamadas Apex.

Llamada de Salesforce a un sistema remoto

Llamada de Salesforce a un sistema remoto

Diagrama de descarga

En este escenario:

  • Se inicia una acción en la página Lightning (por ejemplo, un clic de botón).
  • El navegador (a través de un controlador del lado del cliente en el caso de un componente Lightning) realiza una POST HTTP que a su vez realiza una acción en el controlador Apex correspondiente.
  • El controlador invoca la llamada real al servicio web remoto.
  • La respuesta del sistema remoto se devuelve al controlador de Apex. El controlador procesa la respuesta, actualiza los datos en Salesforce según sea necesario y vuelve a representar la página.

En casos donde se debe realizar un seguimiento del estado posterior, el sistema remoto devuelve un identificador exclusivo almacenado en el registro de Salesforce.

Resultados

La aplicación de las soluciones relacionadas con este patrón permite invocaciones de procesos remotos iniciados por eventos en los que Salesforce gestiona el procesamiento.

Mecanismos de llamadas

El mecanismo de llamada depende de la solución elegida para implementar este patrón.

Mecanismo de llamada Descripción
Servicio externo mejorado integrado en un flujo o

Componente Lightning o

Controladores Apex 		Se utiliza cuando el proceso remoto se desencadena como parte de un proceso de extremo a extremo que implica la interfaz de usuario, y el resultado debe mostrarse o actualizarse en un registro de Salesforce. Por ejemplo, el envío de un pago con tarjeta de crédito a una pasarela de pago externa y los resultados del pago se devuelven inmediatamente y se muestran al usuario.
Desencadenadores Apex Se utiliza principalmente para la invocación de procesos remotos utilizando llamadas Apex desde eventos iniciados por DML. Para obtener más información acerca de este mecanismo de llamada, consulte patrón Invocación de proceso remoto: Disparar y olvidar.
Clases por lotes Apex Se utiliza para la invocación de procesos remotos por lotes. Para obtener más información acerca de este mecanismo de llamada, consulte patrón Invocación de proceso remoto: Disparar y olvidar.

Tratamiento y recuperación de errores

Es importante incluir una estrategia de gestión y recuperación de errores como parte de la solución general.

  • Gestión de errores: Cuando se produce un error (se devuelven excepciones o códigos de error a la persona que llama), la persona que llama gestiona la gestión de errores. Por ejemplo, un mensaje de error mostrado en la página del usuario final o registrado en una tabla que requiere más acciones.

  • Recuperación: Los cambios no se confirman en Salesforce hasta que el llamante recibe una respuesta satisfactoria. Por ejemplo, el estado del pedido no se actualiza en la base de datos hasta que se reciba una respuesta que indique que se realizó correctamente. Si es necesario, el llamante puede reintentar la operación.

Consideraciones de diseño idempotentes

Las funciones idempotentes garantizan que las invocaciones repetidas son seguras. Si no se implementa la idempotencia, las invocaciones repetidas del mismo mensaje pueden tener resultados diferentes, lo que podría dar como resultado problemas de integridad de datos. Los posibles problemas incluyen la creación de registros duplicados o el procesamiento duplicado de transacciones.

Es importante asegurarse de que el procedimiento remoto al que se llama es idempotente. Si la llamada se realiza por la interfaz de usuario, necesitamos cuidar la idempotencia en la capa de integración, especialmente si no hay garantía de que Salesforce solo llame una vez.

El método más típico para crear un receptor idempotente es que realice un seguimiento de duplicados basándose en identificadores de mensajes exclusivos enviados por el consumidor. El servicio web Apex o las llamadas REST deben personalizarse para enviar un Id. de mensaje exclusivo.

Además, las operaciones que crean registros en el sistema remoto deben comprobar si hay duplicados antes de insertar. Compruebe pasando un Id. de registro exclusivo desde Salesforce. Si el registro existe en el sistema remoto, actualice el registro. En la mayoría de los sistemas, esta operación se denomina operación de alteración.

Consideraciones de seguridad

Cualquier llamada a un sistema remoto debe mantener la confidencialidad, integridad y disponibilidad de la solicitud. Las siguientes consideraciones de seguridad son específicas para utilizar llamadas SOAP y HTTP Apex en este patrón.

  • SSL unidireccional está activado de forma predeterminada, pero SSL bidireccional es compatible con certificados autofirmados y firmados por CA para mantener la autenticidad del cliente y el servidor.

  • Para simplificar su código Apex y simplificar la configuración de llamadas autenticadas, especifique una credencial nombrada en el extremo de la llamada.

  • Considere el uso de OAUTH 2.0 como el mecanismo de autenticación para la integración en sistemas externos.

  • Cuando sea necesario, considere el uso de hash unidireccionales o firmas digitales utilizando los métodos de clase Apex Crypto para garantizar la integridad de las solicitudes.

  • El sistema remoto debe protegerse implementando los mecanismos de cortafuegos apropiados. Consulte Consideraciones de seguridad.

  • Salesforce no admite actualmente WS-Security. Aunque no genera de forma nativa estos encabezados complejos de WS-Security o los aplica automáticamente desde un WSDL entrante, puede construirlos e implementarlos manualmente creando clases Apex personalizadas para gestionar los encabezados SOAP y los tokens de seguridad para solicitudes entrantes.

Barras laterales

Ninguno.

Puntualidad

La puntualidad reviste una importancia considerable en este contexto. Normalmente:

  • La solicitud se invoca habitualmente desde la interfaz de usuario, de modo que el proceso no debe hacer esperar al usuario.
  • Salesforce tiene un tiempo de espera configurable de hasta 120 segundos para llamadas desde Apex.
  • La finalización del proceso remoto se ejecuta de forma oportuna para concluir dentro del límite de tiempo de espera de Salesforce y dentro de las expectativas del usuario.
  • Las llamadas externas están sujetas a límites reguladores de transacciones síncronas Apex, de modo que asegúrese de mitigar el riesgo de crear instancias de más de 50 transacciones que se ejecutan durante más de cinco segundos cada una. Además de garantizar que el extremo externo tiene un desempeño, las opciones para mitigar el riesgo de un tiempo de inactividad incluyen:
    • Establecimiento del tiempo de espera de la llamada externa en cinco segundos.
    • Uso de una continuación en Componentes Lightning para gestionar transacciones de larga duración

Volúmenes de datos

Este patrón se utiliza principalmente para actividades en tiempo real de pequeño volumen, debido a los pequeños valores de tiempo de espera y el tamaño máximo de la solicitud o respuesta para la solución de llamada Apex. No utilice este patrón en actividades de procesamiento por lotes en las que la carga de datos está contenida en el mensaje.

Compatibilidad de funciones y estándares de extremos

La capacidad y la compatibilidad estándar para el extremo depende de la solución que seleccione.

Solución Consideraciones sobre los extremos
Llamadas HTTP Apex El extremo debe poder recibir llamadas HTTP. Salesforce debe poder acceder al extremo a través de Internet pública. Para comunicaciones privadas y seguras, Salesforce ahora también ha comenzado a admitir Salesforce Private connect a través de Hyperforce Platform de forma segura. Consulte Salesforce Private Connect para obtener más detalles.

Puede utilizar llamadas HTTP Apex para llamar a servicios de REST utilizando los métodos GET, POST, PUT, DELETE y PATCH estándar.
Llamadas de SOAP Apex El extremo debe poder recibir llamadas HTTP. Salesforce debe poder acceder al extremo a través de Internet pública. Para comunicaciones privadas y seguras, Salesforce ahora también ha comenzado a admitir Salesforce Private connect a través de Hyperforce Platform de forma segura. Consulte Salesforce Private Connect para obtener más detalles.

Esta solución requiere que el sistema remoto sea compatible con los estándares admitidos por Salesforce. En el momento de redactar este artículo, los estándares de servicio web admitidos por llamadas de SOAP de Salesforce for Apex son:
  • WSDL 1.1
  • JABÓN 1.1
  • Perfil básico de WSI 1.1

Gestión estatal

Al integrar sistemas, las claves son importantes para el seguimiento de estado continuo. Existen dos opciones.

  • Salesforce almacena la clave de sustitución principal o exclusiva del sistema remoto para el registro remoto.
  • El sistema remoto almacena el Id. de registro exclusivo de Salesforce o alguna otra clave sustitutiva exclusiva.

Existen consideraciones específicas para la gestión de claves de integración, dependiendo de qué sistema contiene el registro principal, como se muestra en la siguiente tabla.

Principal Sistema Descripción
Salesforce El sistema remoto almacena el RecordId de Salesforce o alguna otra clave sustitutiva exclusiva del registro.
Sistema remoto La llamada al proceso remoto devuelve la clave exclusiva de la aplicación, y Salesforce almacena ese valor de clave en un campo de registro exclusivo.

Escenarios de integración complejos

En ciertos casos, la solución prescrita por este patrón puede requerir la implementación de varios escenarios de integración complejos. Esto se sirve mejor utilizando middleware o haciendo que Salesforce llame a un servicio compuesto. Estos escenarios incluyen:

  • Orquestación de procesos de negocio y reglas que implican lógica de flujo compleja
  • Agregación de llamadas y sus resultados entre llamadas a múltiples sistemas
  • Transformación de mensajes entrantes y salientes
  • Mantenimiento de la integridad de las transacciones entre llamadas a múltiples sistemas

Límites reguladores

Para obtener información sobre los límites Apex, consulte Reguladores de ejecución y límites en la Guía del desarrollador Apex.

Funciones de middleware

La siguiente tabla resalta las propiedades deseables de un sistema de middleware que participa en este patrón.

Propiedad Obligatorio Deseable No se requiere
Gestión de eventos X
Conversión de protocolo X
Traducción y transformación X
Colocación en cola y almacenamiento intermedio X
Protocolos de transporte síncronos X
Protocolos de transporte asíncronos X
Enrutamiento de mediación X
Coreografía de procesos y orquestación de servicios X
Transaccionalidad (cifrado, firma, entrega fiable, gestión de transacciones) X
Enrutamiento X
Extraer, transformar y cargar X
sondeo largo X

Ejemplo

Una compañía de servicios públicos utiliza Salesforce y tiene un sistema separado que contiene información de facturación de clientes. Como parte del proceso de pedido, se deben crear nuevas cuentas de facturación en el sistema de facturación y Salesforce debe reflejar el número de cuenta Billing en el proceso de activación del pedido. Tienen un servicio web existente que permite la creación de una cuenta de facturación y devuelve el número de cuenta de facturación como respuesta.

Este requisito se puede realizar con el siguiente enfoque.

  1. Salesforce consume el servicio de cuenta de facturación WSDL desde una clase proxy Apex.
  2. Ejecute la clase de proxy Apex con la información del cliente pasada al servicio web externo desde un controlador Apex personalizado o servicio externo.
  3. A continuación, el controlador personalizado analiza los valores de devolución de la llamada de Apex y almacena esa información en el objeto de salesforce.

Este ejemplo demuestra que:

  • Se realiza un seguimiento del estado del cliente con un número de cuenta almacenado en el objeto de cuenta de Salesforce.
  • Procesamiento posterior del mensaje de respuesta por el llamante

Context

Utiliza Salesforce para realizar un seguimiento de prospectos, gestionar sus oportunidades en curso, crear oportunidades y capturar detalles de pedidos que convierten prospectos en clientes. Sin embargo, como parte de los procesos de gestión de pedidos, es necesario crear una cuenta de facturación en el sistema de facturación del pedido.

Cuando implementa este patrón, Salesforce llama al sistema remoto para crear la cuenta de facturación, pero no espera a que la llamada se complete correctamente. El sistema remoto puede opcionalmente actualizar Salesforce con la nueva cuenta de facturación creada en una transacción separada.

Problema

Cuando se produce un evento en Salesforce, ¿cómo iniciar un proceso en un sistema remoto y pasar la información requerida a ese proceso sin esperar una respuesta del sistema remoto?

Fuerzas

Tenga en cuenta las siguientes fuerzas al aplicar soluciones basadas en este patrón.

  • ¿Requiere la llamada al sistema remoto que Salesforce espere una respuesta antes de continuar el procesamiento? ¿La llamada al sistema remoto es síncrona o asíncrona?
  • Si la llamada al sistema remoto es síncrona, ¿necesita Salesforce procesar la respuesta como parte de la misma transacción que la llamada?
  • ¿El tamaño del mensaje es pequeño?
  • ¿Se basa la integración en la aparición de un evento específico, como un clic de botón en la interfaz de usuario de Salesforce o eventos basados en DML?
  • ¿Es un requisito la entrega de mensajes garantizada desde Salesforce al sistema remoto?
  • ¿Puede el sistema remoto participar en una integración de contrato primero en la que Salesforce especifica el contrato? En algunas variantes de solución (por ejemplo, mensajería saliente), Salesforce especifica un contrato que implementa el extremo del sistema remoto.
  • ¿El extremo o el Bus de servicio de compañía (ESB) admiten sondeos largos?
  • ¿Se prefieren los métodos de configuración declarativa al desarrollo Apex personalizado? En este caso, se prefieren soluciones como eventos de plataforma a llamadas Apex.

Solución

La siguiente tabla contiene soluciones a este problema de integración.

Solución Ajuste Comentarios
Eventos de plataforma dirigidos por flujos Mejor Cree flujos de forma declarativa para implementar eventos de plataforma. La solución recomendada es cuando se invoca el proceso remoto desde un evento de inserción o actualización.

Los eventos de plataforma son los mensajes de eventos (o notificaciones) que sus aplicaciones envían y reciben para realizar más acciones. Los eventos de plataforma simplifican el proceso de comunicar cambios y responder a ellos sin redactar lógica compleja. Uno o más suscriptores pueden escuchar el mismo evento y realizar acciones.

Por ejemplo, un sistema de software puede enviar eventos que contienen información acerca de cartuchos de tinta de impresora. Los suscriptores pueden suscribirse a los eventos para monitorear los niveles de tinta de la impresora y realizar pedidos para sustituir cartuchos con niveles de tinta bajos.

Las aplicaciones externas pueden escuchar mensajes de eventos suscribiéndose a un canal a través de CometD. Las aplicaciones de plataforma, como componentes Lightning, también pueden suscribirse a mensajes de eventos con CometD. La API de PubSub de Salesforce que se basa en gRPC y HTTP/2 también se puede utilizar aquí.

Salesforce también admite Flujos desencadenados por eventos de plataforma, lo que permite de forma efectiva crear un oyente utilizando la interfaz de Flow Builder. Este tipo de flujo se inicia automáticamente cuando se publica un mensaje de evento de plataforma específico en el Bus de eventos de Salesforce.
API Pub/Sub Mejor La API Pub/Sub es la forma recomendada para que los consumidores externos consuman los eventos en el Bus de eventos.

La API Pub/Sub basada en gRPC :
  • Admite tanto la publicación como la suscripción a eventos de plataforma desde aplicaciones externas
  • Está disponible con la autenticación apropiada (OAuth, JWT o tokens de sesión)

Una vez definido un evento de plataforma en Salesforce, queda disponible para consumidores internos y externos.
Captura de datos de cambios Mejor Captura de datos de cambios (CDC) publica eventos para cambios en registros de Salesforce correspondientes a operaciones de creación, actualización, eliminación y anulación de eliminación. Activar Captura de datos de cambios (CDC) en Salesforce es un proceso puramente declarativo, que no requiere código Apex.

Los mensajes de notificación se envían al bus de eventos al que los clientes pueden suscribirse utilizando desencadenadores de Apex o API Pub/Sub. Los sistemas dirigidos por eventos simplifican la comunicación entre sistemas de compañía distribuidos, aumentan la capacidad de ampliación y entregan datos en tiempo real.

Por ejemplo, si la información de pedidos reside en su sistema ERP y Salesforce, puede transmitir eventos de cambio de pedidos desde Salesforce a una aplicación de integración. La aplicación sincroniza a continuación los cambios en el sistema ERP
Procedimientos de integración de OmniStudio Bien Utilice procedimientos de integración de OmniStudio para automatizar de forma declarativa interacciones de datos entre Salesforce y aplicaciones externas externas. Los procedimientos de integración gestionan transformaciones de datos complejas, llamadas de API y automatización dirigida por eventos, y pueden ejecutar múltiples acciones en una sola llamada de servidor.

Utilice Procedimientos de integración cuando no se requiere interacción de usuario durante la ejecución y desea:
  • Recuperar, transformar y enviar datos entre Salesforce y sistemas externos
  • Cargar el procesamiento en el servidor para mejorar el desempeño y la capacidad de ampliación
  • Empaquetar múltiples operaciones en una sola transacción de servidor
  • Activar el almacenamiento en caché de datos para información a la que se accede frecuentemente

Consulte más detalles sobre Procedimientos de integración aquí.
Eventos de plataforma dirigidos por personalización Bien Similar a eventos de plataforma dirigidos por flujo, pero los eventos se crean por desencadenadores o clases Apex. Puede publicar y consumir eventos de plataforma utilizando Apex o una API.

Los eventos de plataforma se integran con la plataforma Salesforce a través de desencadenadores Apex. Los desencadenadores son los consumidores de eventos en Salesforce Platform que escuchan mensajes de eventos.

Cuando una aplicación externa utiliza la API o una aplicación nativa de Salesforce utiliza Apex para publicar el mensaje del evento, se desencadena un desencadenador en ese evento. Los desencadenadores ejecutan las acciones en respuesta a las notificaciones de eventos.
Mensajería saliente dirigida por flujo Ajuste La solución recomendada para este tipo de integración es cuando se invoca el proceso remoto desde un evento de inserción o actualización. Salesforce proporciona una función de mensajería saliente dirigida por flujo que permite enviar mensajes SOAP a sistemas remotos desencadenados por una operación de inserción o actualización en Salesforce. Estos mensajes se envían de forma asíncrona y son independientes de la interfaz de usuario de Salesforce.

El mensaje saliente se envía a un extremo remoto específico. El servicio remoto debe poder participar en una integración de contrato primero donde Salesforce proporciona el contrato.

Al recibir el mensaje, si el servicio remoto no responde con un acuse de recibo positivo, Salesforce reintenta enviar el mensaje, proporcionando una forma de entrega garantizada.
Componente Lightning personalizado que inicia una llamada asíncrona HTTP o SOAP de Apex Suboptimal Esta solución se utiliza habitualmente en escenarios basados en la interfaz de usuario, pero requiere personalización. Además, la solución debe gestionar la entrega garantizada del mensaje en el código.

Similar a la solución para la solución de patrón Remote Process Invocation: Request and Reply que especifica el uso de un componente Lightning, junto con una llamada Apex. La diferencia es que en este patrón, Salesforce no espera a que se complete la solicitud antes de traspasar el control al usuario.

Tras recibir el mensaje, el sistema remoto responde e indica la recepción del mensaje, luego procesa el mensaje de forma asíncrona. El sistema remoto devuelve el control a Salesforce antes de que comience a procesar el mensaje; por lo tanto, Salesforce no tiene que esperar a que se complete el procesamiento.
Apex desencadena la llamada asíncrona SOAP o HTTP de Apex Suboptimal Puede utilizar desencadenadores Apex para realizar la automatización basándose en cambios de datos de registro.

Se puede ejecutar una clase de proxy Apex como resultado de una operación DML utilizando un desencadenador Apex. Sin embargo, todas las llamadas realizadas desde el contexto del desencadenador deben ejecutarse de forma asíncrona.

Apex desencadena la llamada asíncrona SOAP o HTTP de Apex Suboptimal Las llamadas a un sistema remoto se pueden realizar desde un trabajo por lotes. Esta solución permite la ejecución de procesos remotos por lotes y el procesamiento de la respuesta desde el sistema remoto en Salesforce. Sin embargo, existen límites en el número de llamadas para un contexto por lotes concreto. Para obtener más información, consulte la Referencia rápida Límites y asignaciones de desarrollador de Salesforce.

Boceto

El siguiente diagrama ilustra una llamada desde Salesforce a un sistema remoto en el que la creación o actualización de operaciones en un registro desencadena la llamada.

Llamada de Salesforce a un sistema remoto

Diagrama de descarga

En este escenario:

  1. Un sistema remoto se suscribe al evento de plataforma.
  2. Se produce una actualización o inserción en un conjunto concreto de registros en Salesforce.
  3. Un flujo de Salesforce se desencadena cuando se cumple un conjunto de condiciones.
  4. Este flujo crea un evento de plataforma.
  5. El oyente remoto recibe el mensaje del evento y coloca el mensaje en una cola local.
  6. La aplicación en cola reenvía el mensaje a la aplicación remota para su procesamiento.

En el caso de que el sistema remoto deba realizar operaciones contra Salesforce, puede implementar una operación de devolución de llamada opcional.

Resultados

La aplicación de las soluciones relacionadas con este patrón permite:

  • Invocaciones de procesos remotos iniciadas por la interfaz de usuario en las que el resultado de la transacción puede mostrarse al usuario final
  • Invocaciones de procesos remotos iniciados por eventos DML en las que el resultado de la transacción puede procesarse por el proceso de llamada

Mecanismos de llamadas

El mecanismo de llamada depende de la solución elegida para implementar este patrón.

Mecanismo de llamada Descripción
Flujo Utilizado por las soluciones dirigidas por procesos y por personalización. Los eventos desencadenan el proceso de Salesforce, que luego puede publicar un evento de plataforma para su suscripción por un sistema remoto.
API Pub / Sub API Pub/Sub proporciona una única interfaz para publicar y suscribirse a eventos de plataforma, incluyendo eventos de monitoreo de eventos en tiempo real y eventos Captura de datos de cambios. Basándose en gRPC y HTTP/2, la API Pub/Sub publica y entrega de forma eficiente mensajes de eventos binarios en el formato Apache Avro.
Captura de datos de cambios Captura de datos Cambio de Salesforce publica eventos de cambio, que representan cambios en registros de Salesforce. Los cambios incluyen la creación de un nuevo registro, actualizaciones en un registro existente, la eliminación de un registro y la anulación de la eliminación de un registro.
Componente Lightning y controladores Apex Se utiliza para invocar un proceso remoto de forma asíncrona utilizando una llamada Apex.
Mensajería saliente dirigida por flujo Solo se utiliza para la solución de mensajería saliente. Los eventos DML de creación y actualización desencadenan las reglas de flujo de trabajo de Salesforce, que pueden enviar un mensaje a un sistema remoto.
Desencadenadores Apex Se utiliza para eventos de plataforma dirigidos por desencadenadores e invocación de procesos remotos, utilizando llamadas Apex desde eventos iniciados por DML.
Clases por lotes Apex Se utiliza para la invocación de procesos remotos en modo por lotes.

Tratamiento y recuperación de errores

Una estrategia de gestión y recuperación de errores debe considerarse como parte de la solución general. El mejor método depende de la solución que seleccione.

Solución Estrategia de gestión y recuperación de errores
Flujo
  • Gestión de errores: En ciertas condiciones, los flujos pueden fallar en el procesamiento completo. Cuando falla una entrevista de flujo o proceso, se envía un email detallado al administrador que modificó por última vez el flujo o el proceso. Modifique el comportamiento predeterminado agregando rutas de fallo a todos los elementos que pueden fallar. Este comportamiento debe mejorarse para poner en comportamiento personalizado como la creación de un caso o errores de escritura en un objeto personalizado que se puede monitorear y seguir.
  • Recuperación: La recuperación es más compleja en este escenario. Se debe crear un mecanismo de reintento personalizado si los requisitos de calidad de servicio lo dictan.
Llamadas Apex
  • Gestión de errores: El sistema remoto transfiere la invocación del proceso de finalización, de modo que la llamada solo gestiona excepciones en la invocación inicial del servicio remoto. Por ejemplo, un evento de tiempo de espera se desencadena si no se recibe ninguna confirmación positiva desde la llamada remota. El sistema remoto debe gestionar los errores posteriores cuando se transfiere la invocación inicial para el procesamiento asíncrono.
  • Recuperación: La recuperación es más compleja en este escenario. Se debe crear un mecanismo de reintento personalizado si los requisitos de calidad de servicio lo dictan.
Captura de datos de cambios (CDC) / Eventos de plataforma
  • Tratamiento de errores: El tratamiento de errores debe realizarse por el servicio remoto porque el evento se transfiere de forma efectiva al sistema remoto para su posterior procesamiento. Debido a que este patrón es asíncrono, el sistema remoto gestiona la colocación en cola de mensajes, el procesamiento y la gestión de errores. Además, los eventos de plataforma no se procesan en transacciones de base de datos. Como resultado, los eventos de plataforma publicados no se pueden revertir en una transacción.
  • Recuperación: Como este patrón es asíncrono, el sistema remoto debe iniciar reintentos basándose en los requisitos de calidad de servicio del servicio. El Id. de reproducción asociado con cada evento es atómico y aumenta con cada evento publicado. Este Id. se puede utilizar para reproducir la transmisión desde un evento específico (por ejemplo, basándose en el último evento capturado con éxito). Los mensajes de eventos de plataforma de gran volumen se almacenan durante 72 horas (tres días). Puede recuperar mensajes de eventos pasados cuando utilice clientes de CometD para suscribirse a un canal.

Consideraciones de diseño idempotentes

Los eventos de plataforma solo se publican en el bus una vez. No hay reintento en el lado de Salesforce. Depende del ESB solicitar que se reproduzcan los eventos. En una reproducción, el Id. de reproducción del evento de plataforma permanece igual y el ESB puede probar mensajes duplicados basándose en el Id. de reproducción.

La ideopotencia es importante para la mensajería saliente porque es asíncrona y los reintentos se inician cuando no se recibe ninguna confirmación positiva. Por lo tanto, el servicio remoto debe poder gestionar mensajes desde Salesforce de una forma idempotente.

La mensajería saliente envía un Id. exclusivo por mensaje y este Id. permanece igual para cualquier reintento. El sistema remoto puede realizar un seguimiento de mensajes duplicados basándose en este Id. exclusivo. El Id. de registro exclusivo para cada registro que se actualiza también se envía y se puede utilizar para evitar la creación de registros duplicados.

Las consideraciones de diseño idempotentes en el patrón Invocación de proceso remoto: Solicitud y respuesta también se aplican a este patrón.

Consideraciones de seguridad

Cualquier llamada a un sistema remoto debe mantener la confidencialidad, integridad y disponibilidad de la solicitud. Se aplican diferentes consideraciones de seguridad, dependiendo de la solución que seleccione.

Solución Consideraciones de seguridad
Llamadas Apex Una llamada a un sistema remoto debe mantener la confidencialidad, integridad y disponibilidad de la solicitud. Las siguientes son consideraciones de seguridad específicas para utilizar llamadas SOAP y HTTP Apex en este patrón.
  • SSL unidireccional está activado de forma predeterminada, pero SSL bidireccional es compatible con certificados autofirmados y firmados por CA para mantener la autenticidad del cliente y el servidor.
  • Salesforce no admite WS-Security al generar la clase de proxy Apex.
  • Cuando sea necesario, considere el uso de hash unidireccionales o firmas digitales utilizando los métodos de clase Apex Crypto para garantizar la integridad de la solicitud.
  • El sistema remoto debe protegerse implementando los mecanismos de cortafuegos apropiados.
Captura de datos de cambios (CDC) / Eventos de plataforma Para eventos de plataforma, el sistema externo suscriptor debe poder autenticarse en la API de transmisión de Salesforce.

Los eventos de plataforma se ajustan al modelo de seguridad existente configurado en la organización de Salesforce. Para suscribirse a un evento, el usuario necesita acceso de lectura a la entidad del evento. Para publicar un evento, el usuario necesita el permiso “crear” en la entidad del evento.

Consulte Consideraciones de seguridad.

Barras laterales

Ninguno.

Puntualidad

La puntualidad es menos un factor con el patrón de desencadenar y olvidar. El control se devuelve al cliente inmediatamente o después del reconocimiento positivo de una transferencia correcta al sistema remoto. Con la mensajería saliente de Salesforce, la confirmación debe producirse en un plazo de 24 horas (puede ampliarse a siete días); de lo contrario, el mensaje caduca. Para eventos de plataforma, Salesforce envía los eventos al bus de eventos y no espera una confirmación o confirmación del suscriptor. Si el suscriptor no selecciona el mensaje, el suscriptor puede solicitar reproducir el evento utilizando el Id. de respuesta del evento. Los mensajes de eventos de gran volumen se almacenan durante 72 horas (tres días). Para recuperar mensajes de eventos pasados, utilice clientes CometD para suscribirse a un canal.

Volúmenes de datos

Las consideraciones sobre el volumen de datos dependen de la solución que seleccione. Para consultar los límites de cada solución, consulte la Referencia rápida Límites de Salesforce.

Compatibilidad de funciones y estándares de extremos

La capacidad y la compatibilidad estándar para el extremo depende de la solución que seleccione.

Solución Consideraciones sobre los extremos
Llamadas de SOAP Apex El extremo debe poder procesar una llamada de servicio web a través de HTTP. Salesforce debe poder acceder al extremo a través de Internet pública. Esta solución requiere que el sistema remoto sea compatible con los estándares admitidos por Salesforce. En el momento de redactar este artículo, los estándares de servicio web admitidos por llamadas de SOAP de Salesforce for Apex son:
  • WSDL 1.1
  • JABÓN 1.1
  • Perfil básico de WSI 1.1
  • HTTP
Llamadas HTTP Apex El extremo debe poder recibir llamadas HTTP y ser accesible a través de Internet pública por Salesforce.

Las llamadas HTTP Apex se pueden utilizar para llamar a servicios RESTful utilizando los métodos GET, POST, PUT y DELETE estándar.
Captura de datos de cambios (CDC) / Eventos de plataforma
  • Los desencadenadores, procesos y flujos pueden suscribirse a eventos. Puede recibir notificaciones de eventos independientemente de cómo se publicaron.
  • Utilice CometD para suscribirse a eventos de plataforma desde un cliente externo. Implemente su propio cliente CometD o utilice Conector EMP, una herramienta de código abierto compatible con la comunidad que implementa todos los detalles de la conexión a CometD y la escucha en un canal. Salesforce envía eventos de plataforma a clientes CometD secuencialmente en el orden en que se reciben. El orden de las notificaciones de eventos se basa en el Id. de reproducción de eventos.

Gestión estatal

Al integrar sistemas, los identificadores de registro exclusivos son importantes para el seguimiento de estado continuo. Por ejemplo, si se crea un registro en el sistema remoto, tiene dos opciones.

  • Salesforce almacena la clave de sustitución principal o exclusiva del sistema remoto para el registro remoto.
  • El sistema remoto almacena el Id. de registro exclusivo de Salesforce o alguna otra clave sustitutiva exclusiva.

La siguiente tabla enumera consideraciones para la gestión de estados en este patrón.

Principal Sistema Descripción
Salesforce El sistema remoto debe almacenar el RecordId de Salesforce o alguna otra clave sustitutiva exclusiva en el registro de Salesforce.
Sistema remoto Salesforce debe almacenar una referencia al identificador exclusivo en el sistema remoto. Como el proceso es asíncrono, el almacenamiento de este identificador exclusivo no puede formar parte de la transacción original.

Salesforce debe proporcionar un Id. exclusivo en la llamada al proceso remoto. El sistema remoto debe volver a llamar a Salesforce para actualizar el registro en Salesforce con el identificador exclusivo del sistema remoto, utilizando el Id. exclusivo de Salesforce.

La devolución de llamada implica la gestión de estado específico en la aplicación remota para almacenar el identificador exclusivo de Salesforce para que esa transacción se utilice para la devolución de llamada cuando se complete el procesamiento, o el identificador exclusivo de Salesforce se almacena en el registro del sistema remoto.

Escenarios de integración complejos

Cada solución en este patrón tiene diferentes consideraciones para escenarios de integración complejos como la transformación y la orquestación de procesos.

Solución Consideraciones
Llamadas Apex En ciertos casos, las soluciones prescritas por este patrón requieren la implementación de varios escenarios de integración complejos mejor servidos utilizando middleware o haciendo que Salesforce llame a un servicio compuesto. Estos escenarios incluyen:
  • Orquestación de procesos de negocio y reglas que implican lógica de flujo compleja
  • Agregación de llamadas y sus resultados entre llamadas a múltiples sistemas
  • Transformación de mensajes entrantes y salientes
  • Mantenimiento de la integridad de las transacciones entre llamadas a múltiples sistemas
Captura de datos de cambios (CDC) / Eventos de plataforma Dada la naturaleza declarativa y estática de los eventos, no se pueden realizar escenarios de integración complejos, como agregación, orquestación o transformación en Salesforce. El sistema remoto o middleware debe gestionar estos tipos de operaciones.
Procedimientos de integración de OmniStudio Procedimientos de integración (OmniStudio) proporciona orquestación sin estado del lado del servidor para coordinar múltiples servicios backend mientras realiza transformaciones de datos declarativas complejas.

Pasos de cadena de Procedimientos de integración como Acciones HTTP, Extracción/Transformación/Carga de DataRaptor, Establecer valores, Bucle/Si y búsquedas matriciales para normalizar, enriquecer, agregar y asignar cargas entre contratos de la interfaz de usuario y API dispares.

Admiten sólidos controles de tiempo de ejecución como la bifurcación condicional, la paginación, los tiempos de espera, los reintentos, la gestión de fallos parciales y la continuación de errores, así como optimizaciones de desempeño como el almacenamiento en caché del lado del servidor y la configuración de respuestas.

Las direcciones IP se pueden invocar de forma síncrona desde OmniScripts o de forma desatendida a través de REST, lo que permite “fachadas de integración” versionadas reutilizables que ocultan la complejidad del backend a los canales.

Límites reguladores

Debido a la naturaleza multiarrendatario de la plataforma Salesforce, existen límites para las llamadas salientes. Los límites dependen del tipo de llamada saliente y la cronología de la llamada.

Para consultar los límites y las asignaciones que se aplican a eventos de plataforma, consulte la Guía del desarrollador de eventos de plataforma.

Mensajería fiable

Mensajería fiable intenta resolver el problema de garantizar la entrega de un mensaje a un sistema remoto en el que los componentes individuales no son fiables. El método para garantizar la recepción de un mensaje por el sistema remoto depende de la solución que seleccione.

En caso de Captura de datos de cambios de Salesforce, se proporcionan tipos de eventos de cambio para gestionar situaciones especiales, como la captura de cambios no capturados en los servidores de aplicaciones de Salesforce o la gestión de altas cargas de cambios.

En algunos casos, Salesforce envía eventos Déficit en vez de eventos de cambio para informar a los suscriptores sobre errores o si no es posible generar eventos de cambio. Un evento de brecha contiene información acerca del cambio en el encabezado, como el tipo de cambio y el Id. de registro. No incluye detalles acerca del cambio, como campos de registro. Para capturar cambios de forma más eficiente, los eventos Desbordamiento se generan para transacciones únicas que superan un umbral. Para más información, consulte aquí.

Solución Consideraciones de mensajería fiable
Llamadas Apex Salesforce no proporciona asistencia explícita para protocolos de mensajería fiables (por ejemplo, WS-ReliableMessaging). Recomendamos que el extremo remoto que recibe el mensaje de Salesforce implemente un sistema de mensajería fiable, como JMS o MQ. Este sistema garantiza la entrega completa garantizada de extremo a extremo al sistema remoto que procesa el mensaje en última instancia. Sin embargo, este sistema no garantiza la entrega garantizada desde Salesforce al extremo remoto al que llama.

La entrega garantizada debe gestionarse a través de personalizaciones en Salesforce. Se deben implementar técnicas específicas, como el procesamiento de un reconocimiento positivo desde el extremo remoto además de la lógica de reintento personalizada.
Captura de datos de cambios (CDC) / Eventos de plataforma Eventos de plataforma intenta proporcionar mensajería fiable manteniendo temporalmente mensajes de eventos en el bus de eventos. Los suscriptores pueden ponerse al día con mensajes de eventos perdidos reproduciendo mensajes desde el bus de eventos utilizando el Id. de reproducción de mensajes de eventos.

El bus de eventos es un sistema distribuido y no tiene las mismas garantías que una base de datos de transacciones. Como resultado, Salesforce no puede proporcionar una respuesta síncrona para una solicitud de publicación de evento. Los eventos se colocan en cola y en la memoria intermedia, y Salesforce intenta publicar los eventos de forma asíncrona. En raras ocasiones, es posible que el mensaje de evento no persista en el sistema distribuido durante el intento inicial o posteriores. Esto significa que los eventos no se entregan a suscriptores y no son recuperables.

Funciones de middleware

La siguiente tabla resalta las propiedades deseables de un sistema de middleware que participa en este patrón.

Propiedad Obligatorio Deseable No se requiere
Gestión de eventos X
Conversión de protocolo X
Traducción y transformación X
Colocación en cola y almacenamiento intermedio X
Protocolos de transporte síncronos X
Protocolos de transporte asíncronos X
Enrutamiento de mediación X
Coreografía de procesos y orquestación de servicios X
Transaccionalidad (cifrado, firma, entrega fiable, gestión de transacciones) X
Enrutamiento X
Extraer, transformar y cargar X
sondeo largo X (obligatorio para eventos de plataforma)

Variante de solución: Eventos de plataforma: Comportamiento de publicación y transacciones

Cuando los mensajes de eventos de plataforma se publican inmediatamente, la publicación de eventos no respeta los límites de transacciones del proceso de publicación. Los mensajes de eventos se pueden publicar antes de que se complete la transacción o incluso si una transacción falla. Este comportamiento puede generar problemas cuando un suscriptor espera encontrar datos que la transacción de publicación confirma. Es posible que los datos no estén presentes cuando el suscriptor reciba el mensaje del evento. Para resolver este problema, establezca el comportamiento de publicación del evento de plataforma como Publicar después de confirmar en la definición del evento. Los comportamientos de publicación que puede establecer en una definición de evento de plataforma son:

  • Publicar después de confirmar para que el mensaje del evento se publique solo después de que una transacción se confirme correctamente. Seleccione esta opción si los suscriptores se basan en datos que confirma la transacción de publicación. Por ejemplo, un proceso publica un mensaje de evento y crea un registro de tarea. Un segundo proceso suscrito al evento se desencadena y espera encontrar el registro de tarea. Otra razón para elegir este comportamiento es cuando no desea que se publique el mensaje del evento si la transacción falla.
  • Publicar inmediatamente para que el mensaje del evento se publique cuando se ejecute la llamada de publicación. Seleccione esta opción si desea que se publique el mensaje del evento independientemente de si la transacción se realiza correctamente. Seleccione también esta opción si el publicador y los suscriptores son independientes y los suscriptores no se basan en datos confirmados por el publicador. Por ejemplo, el comportamiento de publicación inmediato es adecuado para un evento utilizado para fines de registro. Con esta opción, un suscriptor podría recibir el mensaje del evento antes de que la transacción del publicador confirme los datos.

Ejemplo

Una compañía de telecomunicaciones desea utilizar Salesforce como interfaz para la creación de cuentas utilizando el proceso de prospecto a oportunidad. Se crea un pedido en Salesforce cuando se cierra y se gana la oportunidad, pero el sistema ERP back-end es el principal de datos. El pedido debe guardarse en el registro de oportunidad de Salesforce y el estado de la oportunidad debe cambiarse para indicar que se creó el pedido.

Se aplican las siguientes restricciones.

  • Solo se puede implementar el desarrollo declarativo.
  • No requiere notificación inmediata del número de pedido después de que la oportunidad se convierta en un pedido.
  • La organización tiene un ESB que admite el protocolo CometD y puede suscribirse a eventos de plataforma.

Este ejemplo se implementa mejor utilizando eventos de plataforma de Salesforce, pero requiere que el ESB se suscriba al evento de plataforma.

En el lado de Salesforce:

  • Cree un flujo para iniciar el evento de plataforma (por ejemplo, cuando el estado de la oportunidad cambia a Cerrada ganada).
  • Cree un nuevo evento de plataforma que publique los detalles de la oportunidad.

En el lado del sistema remoto:

  • El ESB se suscribe al evento de plataforma Salesforce utilizando el protocolo CometD.
  • El ESB recibe una o más notificaciones indicando que la oportunidad se va a convertir en un pedido.
  • El ESB reenvía el mensaje al sistema ERP back-end de modo que se pueda crear el pedido.
  • Después de crear el pedido en el sistema ERP, un hilo separado vuelve a llamar a Salesforce utilizando SessionId como token de autenticación. La devolución de llamada actualiza la oportunidad con el número de pedido y el estado. Puede realizar esta devolución de llamada utilizando soluciones de patrón documentadas, como eventos de plataforma Salesforce, API de SOAP de Salesforce, API de REST o un servicio web Apex.

Este ejemplo demuestra lo siguiente.

  • Implementación de un proceso remoto invocado de forma asíncrona
  • Entrega garantizada de extremo a extremo
  • Devolución de llamada posterior a Salesforce para actualizar el estado del registro

Context

Está trasladando su implementación de CRM a Salesforce y desea:

  • Extraiga y transforme cuentas, contactos y oportunidades del sistema CRM actual y cargue los datos en Salesforce (importación de datos inicial).
  • Extraiga, transforme y cargue datos de facturación de clientes en Salesforce desde un sistema remoto de forma semanal (continua).
  • Extraiga información de actividad de clientes de Salesforce e impórtela en un almacén de datos local semanalmente (de forma continua).

Problema

¿Cómo importa datos en Salesforce y exporta datos fuera de Salesforce, teniendo en cuenta que estas importaciones y exportaciones pueden interferir con las operaciones del usuario final durante el horario de oficina e implicar grandes cantidades de datos?

Fuerzas

Existen varias fuerzas a tener en cuenta al aplicar soluciones basadas en este patrón:

  • ¿Deberían almacenarse los datos en Salesforce? Si no, existen otras opciones de integración que un arquitecto puede y debe considerar (mashups, por ejemplo).
  • Si los datos se deben almacenar en Salesforce, ¿se deben actualizar los datos en respuesta a un evento en el sistema remoto?
  • ¿Se deben actualizar los datos de forma programada?
  • ¿Los datos admiten procesos de negocio principales?
  • ¿Existen requisitos de análisis (creación de reportes) afectados por la disponibilidad de estos datos en Salesforce?

Solución

La siguiente tabla contiene varias soluciones a este problema de integración.

Solución Ajuste Maestro de datos Comentarios
Replicación a través de una herramienta ETL externa Mejor Sistema remoto Donde un sistema externo necesita enviar una gran cantidad de datos a Salesforce, aproveche una herramienta ETL externa que le permite ejecutar Captura de datos de cambios en datos de origen.

La herramienta reacciona a cambios en el conjunto de datos de origen, transforma los datos y luego llama a la API masiva de Salesforce para emitir declaraciones DML. Esto también se puede implementar utilizando las API de REST de Salesforce si el número de registros es inferior.
Replicación a través de una herramienta ETL externa Bien Salesforce Aproveche una herramienta ETL externa que le permite ejecutar Captura de datos de cambios en conjuntos de datos de ERP y Salesforce.

En esta solución, Salesforce es el origen de datos y puede utilizar información de tiempo/estado en filas individuales para consultar los datos y filtrar el conjunto de resultados de destino. Esto se puede implementar utilizando la API masiva 2.0 o las API de REST estándar (si el número de registros es inferior a ).
Asistente de importación de datos y Cargador de datos Ajuste Salesforce / Sistema externo El Asistente de importación de datos y el Cargador de datos se pueden utilizar para importar, exportar y migrar datos. Aunque los comandos del Cargador de datos también se pueden programar para automatizar la importación y exportación de datos, la interfaz de línea de comandos es solo para Windows. Ninguna de estas herramientas es una base recomendada para una estrategia de integración de datos. En su lugar, deben complementar su estrategia de mantenimiento y administración de datos.

Para obtener más información sobre el Cargador de datos, consulte aquí.
Llamada remota Suboptimal Sistema remoto Es posible que un sistema remoto llame a Salesforce utilizando una de las API y realice actualizaciones en datos a medida que se producen. Sin embargo, esto provoca un tráfico considerable entre los dos sistemas.

Se debe hacer mayor hincapié en la gestión y el bloqueo de errores. Este patrón tiene el potencial de provocar actualizaciones continuas, lo que tiene el potencial de afectar al desempeño para usuarios finales.
Invocación de proceso remoto Suboptimal Salesforce Es posible que Salesforce llame a un sistema remoto y realice actualizaciones en datos a medida que se producen. Sin embargo, esto provoca un tráfico considerable entre los dos sistemas.

Se debe hacer mayor hincapié en la gestión y el bloqueo de errores. Este patrón tiene el potencial de provocar actualizaciones continuas, lo que tiene el potencial de afectar al desempeño para usuarios finales.

Boceto

El siguiente diagrama ilustra la secuencia de eventos en este patrón, donde Salesforce es el principal de datos.

Diagrama de descarga

El siguiente diagrama ilustra la sincronización posterior de eventos casi en tiempo real, donde Salesforce es el principal de datos.

Resultados

Puede integrar datos originados de forma externa con Salesforce bajo los siguientes escenarios:

  • Sistema externo es el principal de datos: Salesforce es consumidor de datos proporcionados por un único sistema de origen o múltiples sistemas. En este escenario, es común tener un almacén de datos o mercado de datos que agrega los datos antes de importar los datos en Salesforce.
  • Salesforce es el principal de datos: Salesforce es el sistema de registro para ciertas entidades y las aplicaciones cliente de Captura de datos Salesforce Change pueden ser informadas de cambios en datos de Salesforce.

En un escenario de integración habitual de Salesforce, el equipo de implementación realiza una de las siguientes acciones:

  • Implemente Captura de datos de cambios en el conjunto de datos de origen.
  • Implemente un conjunto de estructuras de base de datos compatibles, conocidas como tablas de control, en una base de datos local intermedia.

La herramienta ETL se utiliza a continuación para crear programas que:

  1. Lea una tabla de control para determinar el último tiempo de ejecución del trabajo y extraer cualquier otro valor de control necesario.
  2. Utilice los valores de control anteriores como filtros y consulte el conjunto de datos de origen.
  3. Aplique reglas de procesamiento predefinidas, incluyendo validación, enriquecimiento, etc.
  4. Utilice conectores/funciones de transformación disponibles de la herramienta ETL para crear el conjunto de datos de destino.
  5. Redacte el conjunto de datos en objetos de Salesforce.
  6. Si el procesamiento se realiza correctamente, actualice los valores de control en la tabla de control.
  7. Si el procesamiento falla, actualice las tablas de control con valores que activan un reinicio y una salida.

Nota: Le recomendamos crear las tablas de control y las estructuras de datos asociadas en un entorno al que la herramienta ETL tenga acceso incluso si el acceso a Salesforce no está disponible. Esto proporciona niveles adecuados de resiliencia. Salesforce debe tratarse como un interlocutor en este proceso y la infraestructura de ETL es el núcleo.

Para que una herramienta ETL obtenga el máximo beneficio de las funciones de sincronización de datos, considere lo siguiente:

  • Encadene y ordene los trabajos de ETL para proporcionar un proceso coherente.
  • Utilice claves principales de ambos sistemas para comparar datos entrantes.
  • Utilice métodos de API específicos para extraer solo datos actualizados.
  • Si importa registros secundarios en una relación principal-detalle o de búsqueda, agrupe los datos importados utilizando su clave principal en el origen para evitar el bloqueo. Por ejemplo, si está importando datos de contacto, asegúrese de agrupar los datos de contacto por la clave de cuenta principal de modo que se pueda cargar el número máximo de contactos para una sola cuenta en una llamada de API. La no agrupación de los datos importados suele dar como resultado la carga del primer registro de contacto y el fallo de los registros de contacto posteriores para esa cuenta en el contexto de la llamada de API.
  • Cualquier procesamiento posterior a la importación, como desencadenadores, solo debe procesar datos de forma selectiva.
  • Si su escenario implica grandes volúmenes de datos, siga las mejores prácticas de este módulo Trailhead Mejores prácticas para implementaciones con grandes volúmenes de datos
    • .

Tratamiento y recuperación de errores

Una estrategia de gestión y recuperación de errores debe considerarse como parte de la solución general. El mejor método depende de la solución que seleccione.

Ubicación del error Estrategia de gestión y recuperación de errores
Leer desde Salesforce utilizando Captura de datos de cambios
  • Gestión de errores: La gestión de errores debe realizarse en el servicio remoto porque el evento se transfiere de forma efectiva al sistema remoto para su posterior procesamiento. Debido a que este patrón es asíncrono, el sistema remoto gestiona la colocación en cola de mensajes, el procesamiento y la gestión de errores. Además, los eventos de Captura de datos no se procesan en transacciones de base de datos. Como resultado, los eventos publicados no se pueden revertir en una transacción.
  • Recuperación: Debido a que este patrón es asíncrono, el sistema remoto debe iniciar reintentos basándose en los requisitos de calidad de servicio del servicio. El Id. de reproducción asociado con cada evento Captura de datos de cambio es atómico y aumenta con cada evento publicado. Este Id. se puede utilizar para reproducir la transmisión desde un evento específico (por ejemplo, basándose en el último evento capturado con éxito). Los mensajes de eventos de plataforma de gran volumen se almacenan durante 72 horas (3 días). Puede recuperar mensajes de eventos pasados cuando utilice clientes de CometD para suscribirse a un canal.
Leer desde Salesforce utilizando un sistema ETL externo
  • Gestión de errores: Si se produce un error durante una operación de lectura, implemente un reintento para errores que no están relacionados con la infraestructura. En caso de fallo repetido, el procesamiento estándar utilizando tablas de control/tablas de error debe implementarse en el contexto de una operación ETL para:
    • Registrar el error
    • Reintentar la operación de lectura
    • Terminar si no se realiza correctamente
    • Enviar una notificación
  • Recuperación: reinicie el proceso de ETL para recuperarse de una operación de lectura fallida.
Si la operación se realiza correctamente pero existen registros con fallos, un reinicio inmediato o una ejecución posterior del trabajo debe solucionar el problema. En este caso, un reinicio retrasado podría ser una mejor solución porque da tiempo a filtrar y corregir datos que podrían estar causando los errores.
Redactar en Salesforce
  • Gestión de errores: Los errores que se producen durante una operación de escritura pueden deberse a una combinación de factores en la aplicación. Las llamadas de API devuelven un conjunto de resultados que consta de la información enumerada a continuación. Esta información debe utilizarse para reintentar la operación de escritura (si es necesario).
    • Información de identificación de registro
    • Notificación de operación correcta/fallo
    • Una recopilación de errores para cada registro
  • Recuperación: reinicie el proceso de ETL para recuperarse de una operación de lectura fallida.
Si la operación se realiza correctamente pero existen registros con fallos, un reinicio inmediato o una ejecución posterior del trabajo debe solucionar el problema. En este caso, un reinicio retrasado podría ser una mejor solución porque da tiempo a filtrar y corregir datos que podrían estar causando los errores.
Sistema principal externo Los errores deben tratarse de acuerdo con las mejores prácticas del sistema general.

Consideraciones de seguridad

Cualquier llamada a un sistema remoto debe mantener la confidencialidad, integridad y disponibilidad de la solicitud. Se aplican diferentes consideraciones de seguridad, dependiendo de la solución que seleccione.

  • Se requiere una licencia de Lightning Platform con al menos permisos de usuario “Solo API” para permitir el acceso de API autenticado a la API de Salesforce.
  • Recomendamos que se utilice el cifrado estándar para mantener el acceso de contraseña seguro.
  • Utilice el protocolo HTTPS cuando realice llamadas a las API de Salesforce. También puede asignar tráfico a las API de Salesforce a través de una solución de seguridad local, si es necesario.

Consulte Consideraciones de seguridad.

Barras laterales

Ninguno.

Puntualidad

La puntualidad no es de importancia significativa en este patrón. Sin embargo, debe tenerse cuidado de diseñar las interfaces de modo que todos los procesos por lotes se completen en un plazo de lotes designado.

Como con todas las operaciones orientadas por lotes, recomendamos encarecidamente que tenga cuidado de aislar los sistemas de origen y destino durante los plazos de procesamiento por lotes. La carga de lotes durante el horario de oficina podría dar como resultado cierta contención, dando como resultado un fallo en la actualización de un usuario o, lo que es más importante, un fallo en la carga de lotes (o carga parcial de lotes).

Para organizaciones que tienen operaciones globales, es posible que no sea factible ejecutar todos los procesos por lotes al mismo tiempo porque el sistema podría estar en uso continuamente. Se pueden utilizar técnicas de segmentación de datos utilizando tipos de registro y otros criterios de filtrado para evitar la contención de datos en estos casos.

Gestión estatal

Puede implementar la gestión de estados utilizando claves sustitutivas entre los dos sistemas. Si necesita cualquier tipo de gestión de transacciones entre entidades de Salesforce, le recomendamos utilizar el patrón Llamada remota utilizando Apex.

El bloqueo de registros optimista estándar se produce en la plataforma, y cualquier actualización realizada utilizando la API requiere que el usuario, que está modificando el registro, actualice el registro e inicie su transacción. En el contexto de la API de Salesforce, el bloqueo optimista hace referencia a un proceso donde:

  • Salesforce no mantiene el estado de un registro que está siendo modificado por un usuario específico.
  • Al leer, registra la hora en la que se extrajeron los datos.
  • Si el usuario actualiza el registro y lo guarda, Salesforce comprueba si otro usuario actualizó el registro mientras tanto.
  • Si el registro se actualizó, el sistema notifica al usuario que se realizó una actualización y el usuario debe recuperar la versión más reciente del registro antes de continuar con sus actualizaciones.

Funciones de middleware

Las tecnologías externas más efectivas utilizadas para implementar este patrón son las herramientas ETL tradicionales. Es importante que las herramientas de middleware elegidas admitan la API masiva de Salesforce.

Es útil, pero no crítico, que las herramientas de middleware admitan la función getUpdated(). Esta función proporciona la implementación más cercana a la función Captura de datos de cambios estándar en Salesforce Platform.

La siguiente tabla resalta las propiedades deseables de un sistema de middleware que participa en este patrón.

Propiedad Obligatorio Deseable No se requiere
Gestión de eventos X
Conversión de protocolo X
Traducción y transformación X
Colocación en cola y almacenamiento intermedio X
Protocolos de transporte síncronos X
Protocolos de transporte asíncronos X
Enrutamiento de mediación X
Coreografía de procesos y orquestación de servicios X
Transaccionalidad (cifrado, firma, entrega fiable, gestión de transacciones) X
Enrutamiento X
Extraer, transformar y cargar X
Sondeo largo X (obligatorio para Captura de datos Salesforce Change)

Ejemplo

Una compañía de servicios públicos utiliza un proceso por lotes basado en mainframe que asigna clientes potenciales a equipos y representantes de ventas individuales. Esta información debe importarse en Salesforce cada noche.

El cliente decidió implementar Captura de datos de cambios en las tablas de origen utilizando una herramienta ETL disponible comercialmente. La solución funciona del siguiente modo:

  • Un programador similar a un cronólogo ejecuta un trabajo por lotes que asigna clientes potenciales a usuarios y equipos.
  • Después de que el trabajo por lotes ejecute y actualice los datos, la herramienta ETL reconoce estos cambios utilizando Captura de datos de cambios. La herramienta ETL recopila los cambios desde el almacén de datos.
  • El conector ETL utiliza la API de REST de Salesforce para cargar los cambios en Salesforce.

Context

Utiliza Salesforce para realizar un seguimiento de prospectos, gestionar sus oportunidades en curso, crear oportunidades y capturar detalles de pedidos que convierten prospectos en clientes. El sistema de Salesforce crea los pedidos de forma interna y luego envía esos datos al sistema de facturación externo para su aprovisionamiento y activación. Los pedidos de facturación se gestionan por un sistema externo (remoto). Ese sistema remoto necesita actualizar el estado del pedido en Salesforce cuando cambia el pedido o la entidad de facturación en el estado del sistema de facturación.

Problema

¿Cómo se conecta y autentica un sistema remoto con Salesforce para notificar a Salesforce sobre eventos externos, crear registros y actualizar registros existentes?

Fuerzas

Existen varias fuerzas a tener en cuenta al aplicar soluciones basadas en este patrón:

  • ¿El propósito de la llamada remota a Salesforce es notificar a Salesforce de un evento que se produjo de forma externa utilizando una arquitectura dirigida por eventos? ¿O el propósito es realizar operaciones CRUD en registros específicos? Si utiliza una arquitectura dirigida por eventos, el productor del evento (el proceso remoto) se desvincula del consumidor del evento de Salesforce.
  • ¿Requiere la llamada a Salesforce que el proceso remoto espere una respuesta antes de continuar el procesamiento? Las llamadas remotas a Salesforce siempre son síncronas, aunque el proceso remoto puede descartar la respuesta si no es necesario para simular una llamada asíncrona.
  • ¿Opera cada transacción en un único objeto de Salesforce o múltiples objetos relacionados?
  • ¿Cuál es el formato del mensaje (por ejemplo, SOAP o REST, o ambos a través de HTTP)?
  • ¿El tamaño del mensaje es relativamente pequeño o grande?
  • Si el sistema remoto tiene capacidad para SOAP, ¿puede el sistema remoto participar en un enfoque de contrato primero, donde Salesforce dicta el contrato? Esto es obligatorio donde se utiliza nuestra API de SOAP, para la que se proporciona un WSDL predefinido.
  • ¿Se requiere procesamiento de transacciones?
  • ¿Cuál es la medida en que es tolerante a la personalización en Salesforce?

Solución

Esta tabla contiene varias soluciones a este problema de integración.

Solución Ajuste Comentarios
API compuesta Mejor Salesforce proporciona una API compuesta que es básicamente una API de REST y admite solicitudes compuestas. Esto puede ser utilizado por sistemas remotos para:
  • Envíe hasta 25 solicitudes en una sola llamada.
  • Para consultar, crear y modificar datos en organizaciones de Salesforce utilizando solicitudes JSON.

API síncrona: Después de realizar la llamada de API, la aplicación cliente remota espera hasta que recibe una respuesta del servicio.

Comportamiento de transacción/confirmación: de forma predeterminada, la API compuesta no permite el éxito parcial si algunos registros están marcados con errores. Esto se puede cambiar marcando “todo o nada” como falso, lo que permitirá un éxito parcial.

Tratamiento de errores: La gestión de errores apropiada debe examinar el cuerpo de la respuesta, no solo los códigos de estado HTTP. Un extremo compuesto responde con código de estado HTTP 200 incluso si dentro del cuerpo de respuesta muestra que una de las subsolicitudes falló y la transacción tuvo que revertirse.
API DE REST Mejor Accesibilidad: Salesforce proporciona una API de REST que los sistemas remotos pueden utilizar para:
  • Publicar eventos para notificar a su organización de Salesforce
  • Consultar datos en su organización
  • Crear, actualizar y eliminar datos
  • Obtener metadatos acerca de su organización

API síncrona: Después de realizar la llamada de API, la aplicación cliente remota espera hasta que recibe una respuesta del servicio.

La API de REST respeta la seguridad a nivel de objeto y de campo configurada en Salesforce basándose en el perfil del usuario que inició sesión.

REST expone recursos (entidades/objetos) como URI y utiliza verbos HTTP para definir operaciones CRUD en estos recursos. A diferencia de SOAP, la API de REST no requiere ningún contrato predefinido, utiliza XML y JSON para respuestas y tiene escritura suelta. API de REST es ligera y proporciona un método sencillo para interactuar con Salesforce. Sus ventajas incluyen la facilidad de integración y desarrollo, y es una excelente opción para su uso con aplicaciones móviles y aplicaciones web.

Comportamiento de transacción/confirmación: de forma predeterminada, cada registro se trata como una transacción separada y se confirma por separado. El fallo de un cambio de registro no causa la reversión de otros cambios de registro. Este comportamiento puede alterarse a un comportamiento “todo o nada”. Utilice los recursos compuestos de API de REST para realizar una serie de actualizaciones en una llamada de API.

Datos masivos: Cualquier operación de datos que incluya más de 2.000 registros es un buen candidato para que la API masiva 2.0 prepare, ejecute y gestione con éxito un flujo de trabajo asíncrono que utilice el marco de trabajo masivo.
API masiva 2.0 Ideal para operaciones masivas API masiva 2.0 es la API moderna y simplificada de Salesforce para gestionar operaciones de datos a gran escala. La API masiva basada en REST 2.0 proporciona una opción programática para insertar, alterar, consultar o eliminar de forma asíncrona grandes conjuntos de datos en su organización de Salesforce. Está diseñado para la eficiencia cuando necesita cargar grandes cantidades de datos en Salesforce o realizar consultas masivas en los datos de su organización.

A diferencia de la API masiva 1.0, la API masiva 2.0 siempre procesa lotes en paralelo y no admite el modo serie. Esto significa que:
  • Los registros se procesan de forma simultánea entre múltiples hilos
  • No hay garantía de procesamiento de pedidos entre lotes
  • Existe un mayor desempeño pero también un potencial para la contención de bloqueo

Cada lote en API masiva 2.0 se procesa como su propia transacción. Esto significa:
  • Los lotes correctos se confirman de forma independiente
  • Los lotes con fallos no afectan a los lotes con éxito
  • De forma predeterminada, no hay comportamiento de "todo o nada" entre todos los trabajos

Aunque la API de SOAP también se puede utilizar para procesar grandes números de registros, se vuelve menos óptima cuando los conjuntos de datos contienen cientos de miles a millones de registros. Esto se debe a su sobrecarga relativamente alta y características de desempeño más bajas.
  • Arquitectura dirigida por eventos: Los eventos de plataforma se definen del mismo modo que define objetos de Salesforce. Publicar un evento a través de la API masiva 2.0 es lo mismo que crear un registro de Salesforce. Solo se admiten las operaciones de creación e inserción. Los eventos dentro de un lote se publican en el bus de eventos de Salesforce de forma asíncrona a medida que se procesa el trabajo por lotes.
API Pub/Sub Mejor La API Pub/Sub es la forma recomendada para que los publicadores externos publiquen eventos en el Bus de eventos.

API Pub/Sub es una API basada en gRPC que permite a los sistemas externos publicar eventos de plataforma. API Pub/Sub:
  • Admite tanto la publicación como la suscripción a eventos de plataforma desde aplicaciones externas
  • Está disponible con la autenticación apropiada (OAuth, JWT o tokens de sesión)

Una vez definido un evento de plataforma en Salesforce, queda disponible para consumidores internos y externos.
Eventos de plataforma Mejor Los eventos de plataforma se definen del mismo modo que define los objetos de Salesforce. Los eventos de plataforma se pueden publicar utilizando diferentes mecanismos como las API de REST, la API masiva y las API de SOAP.

Publicar un evento a través de la API de REST es lo mismo que crear un registro de Salesforce.

Formato de extremo: POST /services/data/vXX.X/sobjects/NombreEvento__e/
  • Content-Type: application/json
  • Autenticación: Token de soporte (OAuth)

Con la API masiva, solo se admiten las operaciones de creación e inserción. Los eventos dentro de un lote se publican en el bus de eventos de Salesforce de forma asíncrona a medida que se procesa el trabajo por lotes.

Puesto que los eventos de plataforma son SObjects, se admiten las operaciones de API de SOAP estándar.
API DE SOAP Ajuste Accesibilidad: Salesforce proporciona una API de SOAP que los sistemas remotos pueden utilizar para:
  • Publicar eventos para notificar a su organización de Salesforce
  • Consultar datos en su organización
  • Crear, actualizar y eliminar datos
  • Obtener metadatos acerca de su organización
  • Ejecutar utilidades para realizar tareas administrativas

API síncrona: Después de realizar la llamada de API, la aplicación cliente remota espera hasta que recibe una respuesta del servicio. No se admiten las llamadas asíncronas a Salesforce.

WSDL generado: Salesforce proporciona dos WSDL para sistemas remotos:
  • WSDL de compañía: Proporciona un WSDL tipificado con fuerza específico de una organización de Salesforce.
  • WSDL de socio: contiene un WSDL poco tipificado que no es específico de una organización de Salesforce.

Seguridad: El cliente que ejecuta la API de SOAP debe tener un inicio de sesión válido y obtener una sesión para realizar cualquier llamada de API. La API respeta la seguridad a nivel de objeto y de campo configurada en Salesforce basándose en el perfil del usuario que inició sesión.

Comportamiento de transacción/confirmación: de forma predeterminada, cada llamada de API permite el éxito parcial si algunos registros están marcados con errores. Esto se puede cambiar a un comportamiento de “todo o nada” donde todos los resultados se revierten si se produce cualquier error. No es posible abarcar una transacción entre múltiples llamadas de API. Para superar esta limitación, es posible que una sola llamada de API afecte a múltiples objetos.
Servicios web Apex Suboptimal Los métodos de clase Apex pueden exponerse como métodos de servicio web a aplicaciones externas. Este método es una alternativa a la API de SOAP y se utiliza habitualmente solo donde se deben cumplir los siguientes requisitos adicionales.
  • Se requiere compatibilidad transaccional completa (por ejemplo, crear una cuenta, un contacto y una oportunidad en una sola transacción).
  • La lógica personalizada debe aplicarse en el lado de Salesforce antes de confirmar.

El beneficio de utilizar un servicio web Apex debe sopesarse con el código adicional que se debe mantener en Salesforce.

No aplicable para eventos de plataforma porque la lógica de inserción previa de transacciones en el consumidor no se aplica en un arquitectura dirigida por eventos. Para notificar a una organización de Salesforce que se produjo un evento, utilice API de SOAP, API de REST o API masiva 2.0.
Servicios REST Apex Suboptimal Una clase Apex puede exponerse como recursos REST asignados a URI específicos con un verbo HTTP definido (por ejemplo, POST o GET).

Puede utilizar recursos compuestos de API de REST para realizar múltiples actualizaciones en una sola transacción.

A diferencia de SOAP, no es necesario que el cliente consuma una definición/contrato de servicio (WSDL) y genere código auxiliar de cliente. El sistema remoto solo requiere la capacidad de formar una solicitud HTTP y procesar los resultados devueltos (XML o JSON).

No aplicable para eventos de plataforma porque la lógica de inserción previa de transacciones en el consumidor no se aplica en un arquitectura dirigida por eventos. Para notificar a una organización de Salesforce que se produjo un evento, utilice API de SOAP, API de REST o API masiva 2.0.

Boceto

Los siguientes diagramas ilustran la secuencia de eventos cuando implementa este patrón utilizando API de REST para notificaciones desde eventos externos o API de SOAP para consultar un objeto de Salesforce. La secuencia de eventos es la misma cuando se utiliza la API de REST.

Consulta del sistema remoto a Salesforce a través de la API de SOAP

Sistema remoto que notifica a Salesforce con eventos a través de la API de REST

Resultados

En una arquitectura dirigida por eventos, el sistema remoto llama a Salesforce utilizando API de SOAP, API de REST o API masiva 2.0 para publicar un evento en el bus de eventos de Salesforce. La publicación de un evento notifica a todos los suscriptores. Los suscriptores de eventos pueden estar en Salesforce Platform como Flujos o Componentes Lightning, desencadenadores Apex. Los suscriptores de eventos también pueden ser externos a Salesforce Platform como suscriptores de CometD.

Al trabajar directamente con objetos de Salesforce, las soluciones relacionadas con este patrón permiten:

  • El sistema remoto llama a las API de Salesforce para consultar la base de datos y ejecutar operaciones de un solo objeto (crear, actualizar, eliminar, etc.).
  • El sistema remoto para llamar a los recursos compuestos de API de REST de Salesforce para realizar una serie de operaciones de objetos.
  • Sistema remoto para llamar a API (servicios) de Salesforce creadas a medida que pueden admitir operaciones de transacciones de múltiples objetos y lógica de procesamiento previo/posterior personalizada.

Mecanismos de llamadas

El mecanismo de llamada depende de la solución elegida para implementar este patrón.

Mecanismo de llamada Descripción
API DE SOAP El sistema remoto utiliza Salesforce Enterprise o Partner WSDL para generar código auxiliar de cliente que se utilizan a su vez para invocar la API de SOAP estándar.
API DE REST El sistema remoto tiene que autenticarse antes de acceder a cualquier servicio REST Apex. El sistema remoto puede utilizar OAuth 2.0 o autenticación de nombre de usuario y contraseña. En cualquier caso, el cliente debe establecer el encabezado HTTP de autorización con el valor apropiado (se puede adquirir un token de acceso de OAuth o un Id. de sesión a través de una llamada de inicio de sesión a la API de SOAP).

El sistema remoto genera a continuación invocaciones de REST (solicitudes HTTP) con los verbos apropiados y procesa los resultados devueltos (se admiten formatos de datos JSON y XML).
Servicio web Apex El sistema remoto consume el servicio web Apex personalizado WSDL para generar código auxiliar de cliente que se utilizan a su vez para invocar el servicio web Apex personalizado.
Servicio REST Apex Según la API de REST, el URI del recurso y los verbos aplicables se definen utilizando las anotaciones @RestResource, @HttpGet y @HttpPost.
API masiva 2.0 API masiva 2.0 es una API basada en REST, por lo que se aplican los mismos mecanismos de llamada que la API de REST.
API de REST para invocar Flujo Utilice la API de REST para llamar a un extremo de acciones invocables personalizadas para invocar un flujo iniciado automáticamente.

Tratamiento y recuperación de errores

Una estrategia de gestión y recuperación de errores debe considerarse como parte de la solución general.

  • Gestión de errores: Todos los métodos de llamadas remotas, las API estándar o personalizadas, requieren que el sistema remoto gestione cualquier error posterior, como los tiempos de espera y la gestión de reintentos. El middleware se puede utilizar para proporcionar la lógica para la gestión y recuperación de errores.
  • Recuperación: Se necesita crear un mecanismo de reintento personalizado si los requisitos de calidad de servicio lo dictan. En este caso, es importante garantizar características de diseño idempotentes. El evento de plataforma permite a los suscriptores utilizar el Id. de reproducción para obtener mensajes en un periodo de tiempo específico después de la publicación de esos mensajes.

Consideraciones de diseño idempotentes

Las funciones idempotentes garantizan que las invocaciones repetidas son seguras y no tendrán un efecto negativo. Si no se implementa la idempotencia, las invocaciones repetidas del mismo mensaje pueden tener resultados diferentes, lo que podría dar como resultado problemas de integridad de datos, como, por ejemplo, la creación de registros duplicados, el procesamiento duplicado de transacciones, etc.

El sistema remoto debe gestionar múltiples llamadas (duplicadas), en caso de errores o tiempos de espera, para evitar inserciones duplicadas y actualizaciones redundantes (especialmente si se desencadenan desencadenadores descendentes y reglas de flujo de trabajo). Aunque es posible gestionar algunas de estas situaciones en Salesforce (particularmente en el caso de servicios SOAP y REST personalizados), recomendamos que el sistema remoto (o middleware) gestione el tratamiento de errores y el diseño idempotente.

Consideraciones de seguridad

Se aplican diferentes consideraciones de seguridad, dependiendo de la solución de patrón elegida. En todos los casos, la plataforma utiliza los derechos de acceso del usuario que inició sesión (por ejemplo, configuración de perfil, reglas de colaboración, conjuntos de permisos, etc.). Además, se pueden utilizar restricciones de IP de perfil para restringir el acceso a la API para un intervalo de direcciones IP específico.

Solución Consideraciones de seguridad
API DE SOAP alesforce admite los protocolos Secure Sockets Layer v3 (SSL) y Transport Layer Security (TLS). Los cifrados deben tener una longitud de clave de al menos 128 bits.

El sistema remoto debe iniciar sesión utilizando credenciales válidas para obtener un Id. de sesión. Si el sistema remoto ya tiene un Id. de sesión válido, puede llamar a la API sin un inicio de sesión explícito. Esto se utiliza en patrones de devolución de llamadas tratados anteriormente en este documento, donde un mensaje saliente de Salesforce anterior contenía un Id. de sesión y un Id. de registro para su uso posterior.

Recomendamos que los clientes que llaman a la caché de API de SOAP y reutilicen el Id. de sesión para maximizar el desempeño, en vez de obtener un nuevo Id. de sesión para cada llamada.
API DE REST Recomendamos que el sistema remoto establezca un Trust OAuth para la autorización. Las llamadas de REST se pueden realizar en recursos específicos utilizando verbos HTTP. También es posible realizar llamadas de REST con un Id. de sesión válido que podría haberse obtenido por otros medios (por ejemplo, recuperado llamando a la API de SOAP o proporcionado a través de un mensaje saliente).

Recomendamos que los clientes que llaman a la caché de API de REST y reutilicen el Id. de sesión para maximizar el desempeño, en vez de obtener un nuevo Id. de sesión para cada llamada.
Servicio web Apex Recomendamos que el sistema remoto establezca un Trust OAuth para la autorización.
Servicio REST Apex Recomendamos que el sistema remoto establezca un Trust OAuth para la autorización.
API masiva 2.0 Recomendamos que el sistema remoto establezca un Trust OAuth para la autorización.

Consulte Consideraciones de seguridad.

Barras laterales

Ninguno.

Puntualidad

API de SOAP y API de servicio web Apex son síncronas. Se aplican los siguientes tiempos de espera:

  • Tiempo de espera de sesión: La sesión se agota si no hay actividad basada en la configuración de tiempo de espera de sesión de la organización de Salesforce.
  • Tiempo de espera de consulta: Cada consulta SOQL tiene un límite de tiempo de espera individual de 120 segundos.

Volúmenes de datos

Las consideraciones sobre el volumen de datos dependen del tipo de comunicación y solución que seleccione.

Solución Tipo de comunicación Límites
API de SOAP o API de REST Síncrono
  • Inicio de sesión SOAP: El tamaño de la solicitud de inicio de sesión SOAP está limitado a 10 KB o menos. Puede realizar un máximo de 3.600 llamadas a la función login() por usuario y hora. Si supera este límite, la API devuelve un error.
  • Crear, actualizar, eliminar: El sistema remoto puede crear, actualizar o eliminar hasta 200 registros a la vez. Se pueden realizar múltiples llamadas para procesar más de un total de 200 registros, pero cada solicitud está limitada a 200 registros de tamaño
  • Datos de BLOB: Puede utilizar recursos de REST Información básica de SObject, Filas de SObject o Recopilaciones de SObject para insertar o actualizar datos de BLOB en objetos estándar de Salesforce. Para los recursos Información básica de SObject o Filas de SObject, el tamaño máximo de archivo para cargas es de 2 GB para objetos ContentVersion y 500 MB para todos los demás objetos estándar aptos. Utilizando los recursos Recopilaciones de SObject, el tamaño total máximo de todos los archivos en una sola solicitud es de 500 MB.
  • Tamaño de resultados de consulta: de forma predeterminada, el número de filas devueltas en el objeto de resultado de consulta (tamaño de lote), devueltas en una llamada query() o queryMore() se establece en 500. El número máximo de filas devueltas es 2.000. Puede establecer explícitamente el tamaño del lote, pero no hay garantía de que el tamaño del lote solicitado sea el tamaño del lote real. Esto se hace para maximizar el desempeño. Donde el número de filas a devolver supera el tamaño del lote, utilice la llamada de API queryMore() para iterar entre múltiples lotes. Se podrían aplicar reglas adicionales, por lo que para obtener más información.
  • Mensaje de evento: El tamaño máximo de mensaje de evento es de 1 MB. La publicación de un evento utilizando las API de Salesforce cuenta en sus límites de API estándar.
API masiva 2.0 Asíncrono API masiva 2.0 está optimizada para importar y exportar grandes conjuntos de datos de forma asíncrona.

Cualquier operación de datos que incluya más de 2.000 registros es un buen candidato para la API masiva 2.0 para preparar, ejecutar y gestionar con éxito un flujo de trabajo asíncrono que utiliza el marco de trabajo masivo. Los trabajos con menos de 2.000 registros deben implicar llamadas síncronas “masificadas” en REST (por ejemplo, Compuesto) o SOAP.

La API masiva 2.0 es síncrona al enviar la solicitud por lotes y los datos asociados. El procesamiento real de los datos se produce de forma asíncrona. Para obtener más información acerca de los límites de API y procesamiento por lotes, consulte Límites.

Compatibilidad de funciones y estándares de extremos

La capacidad y la compatibilidad estándar para el extremo depende de la solución que seleccione.

Solución Consideraciones sobre los extremos
API DE SOAP El sistema remoto debe poder implementar un cliente que pueda llamar a la API de SOAP de Salesforce, basándose en un formato de mensaje predefinido por Salesforce.

El sistema remoto (cliente) debe participar en una implementación de contrato primero donde el contrato se proporciona por Salesforce (por ejemplo, Enterprise o Partner WSDL).
API DE REST El sistema remoto debe poder implementar un cliente de REST que invoque servicios de REST definidos por Salesforce y procese los resultados XML o JSON.
Servicio web Apex El sistema remoto debe ser capaz de implementar un cliente que pueda invocar mensajes SOAP de un formato predefinido, como lo define Salesforce.

El sistema remoto debe participar en una implementación de código primero, donde el contrato lo proporciona Salesforce después de implementar el servicio web Apex. Cada servicio web Apex tiene su propio WSDL.
Servicio REST Apex Se aplican las mismas consideraciones de extremo que la API de REST.

Gestión estatal

Al integrar sistemas, las claves son importantes para el seguimiento de estado continuo, por ejemplo, si se crea un registro en el sistema remoto, para admitir actualizaciones continuas en ese registro. Existen dos opciones:

  • Salesforce almacena la clave de sustitución principal o exclusiva del sistema remoto para el registro remoto.
  • El sistema remoto almacena el Id. de registro exclusivo de Salesforce o alguna otra clave sustitutiva exclusiva. Existen consideraciones específicas para la gestión de claves de integración en este patrón síncrono.
Principal sistema Descripción
Salesforce En este escenario, el sistema remoto almacena el RecordId de Salesforce o alguna otra clave sustitutiva exclusiva desde el registro.
Sistema remoto En este escenario, Salesforce almacena una referencia al identificador exclusivo en el sistema remoto. Como el proceso es síncrono, la clave se puede proporcionar como parte de la misma transacción utilizando campos de Id. externo.

Escenarios de integración complejos

Cada solución en este patrón tiene diferentes consideraciones al gestionar escenarios de integración complejos como la transformación y la orquestación de procesos.

Solución Consideraciones
API de SOAP o API de REST API de SOAP y API de REST proporcionan transacciones sencillas en objetos. Los escenarios de integración complejos, como agregación, orquestación y transformación, no se pueden realizar en Salesforce. Estos escenarios deben ser gestionados por el sistema remoto o middleware, con middleware como el método preferido.
Servicio web Apex o servicio REST Apex Los servicios web personalizados pueden proporcionar funciones de objetos cruzados, lógica personalizada y compatibilidad de transacciones más compleja. Esta solución debe utilizarse con cuidado y siempre debe tener en cuenta la idoneidad del middleware para cualquier transformación, orquestación y lógica de gestión de errores.

Límites reguladores

Debido a la naturaleza multiusuario de Salesforce Platform, existen límites al utilizar las API.

Solución Límites
API de SOAP, API de REST y API de Apex personalizadas
  • Límites de solicitudes de API: Salesforce aplica un límite al número de llamadas de API por periodo de 24 horas. El límite se basa en el tipo de edición de Salesforce y el número de licencias. Por ejemplo, Unlimited Edition proporciona 5.000 solicitudes de API por licencia de Salesforce Platform cada 24 horas. Para obtener más información, consulte Referencia rápida Límites y asignaciones de desarrollador de Salesforce.
  • Límites de cursores de consultas de API: Un usuario puede tener hasta 10 cursores de consultas abiertos a la vez. De lo contrario, se liberará el cursor más antiguo de los 10. Si la aplicación remota intenta abrir el cursor de consulta liberado, se produce un error. Por ejemplo, si comparte credenciales de usuario de integración, es necesario tener en cuenta el máximo de cursores de consulta. Siempre que sea posible, el middleware debe completar la consulta completa antes de ejecutar otra consulta (de forma serial) o cada aplicación debe utilizar un usuario de integración designado. De manera alternativa, el middleware puede necesitar ejecutar solicitudes entre múltiples usuarios de una forma “round robin”.
  • Límites de llamadas: Consulte la barra lateral Volúmenes de datos para límites de creación, actualización y consulta.
API masiva 2.0 Consulte la barra lateral Volúmenes de datos para obtener más información.
Eventos de plataforma
  • Límites de notificación de eventos: se puede publicar un máximo de 100.000 eventos por hora para eventos de plataforma de volumen estándar. Se puede publicar un máximo de 250.000 eventos por hora para eventos de plataforma basados en uso de gran volumen. Para monitorear el uso de eventos de gran volumen, utilice el recurso de límites de API de REST.
  • Límites de tamaño de mensajes de eventos: El tamaño máximo de mensajes de eventos es de 1 MB. La publicación de un evento utilizando las API de Salesforce cuenta en sus límites de API estándar.

Mensajería fiable

Mensajería fiable intenta resolver el problema de garantizar la entrega de un mensaje a un sistema remoto donde los componentes individuales en sí podrían no ser fiables. La API de SOAP de Salesforce y la API de REST son síncronas y no proporcionan asistencia explícita para ningún protocolo de mensajería fiable, per se (por ejemplo, WS-ReliableMessaging).

Recomendamos que el sistema remoto implemente un sistema de mensajería fiable para garantizar que los escenarios de error y tiempo de espera se gestionan correctamente. La publicación de eventos de plataforma desde sistemas externos se basa en las API de Salesforce, de modo que se aplican las mismas consideraciones para la API de SOAP y la API de REST.

Funciones de middleware

Esta tabla resalta las propiedades deseables de un sistema de middleware que participa en este patrón:

Propiedad Obligatorio Deseable No se requiere
Gestión de eventos X
Conversión de protocolo X
Traducción y transformación X
Colocación en cola y almacenamiento intermedio X
Protocolos de transporte síncronos X
Protocolos de transporte asíncronos X
Enrutamiento de mediación X
Coreografía de procesos y orquestación de servicios X
Transaccionalidad (cifrado, firma, entrega fiable, gestión de transacciones) X
Enrutamiento X
Extraer, transformar y cargar X (para granel/lotes)

Ejemplo

Una compañía de suministros y servicios de impresión utiliza Salesforce como interfaz para crear y gestionar pedidos y suministros de impresora. Los registros de activos de Salesforce que representan impresoras se actualizan periódicamente con estadísticas de uso de impresión (estado de tinta, nivel de papel) desde el Sistema de gestión de impresoras (PMS) local, que monitorea regularmente impresoras en sitios de clientes. Al alcanzar un valor de umbral establecido (por ejemplo, bajo estado de tinta o bajo/vacío nivel de papel inferior al 30%), se notifican múltiples aplicaciones/procesos (variable) interesados en el evento, se envían alertas de email o Chatter y se crea un registro Pedido. El PMS almacena el Id. de Salesforce (Salesforce es el principal del registro de activos).

Se aplican las siguientes restricciones:

  • El PMS puede participar en una integración de contrato primero, donde Salesforce proporciona el contrato y el PMS actúa como un cliente (consumidor) del servicio de Salesforce (definido a través de la WSDL de compañía o socio).
  • No debe haber desarrollo personalizado en Salesforce.

Este ejemplo se implementa mejor utilizando la API de SOAP de Salesforce o la API de REST para publicar eventos y la automatización declarativa (Flow) en Salesforce. La razón principal para utilizar eventos de plataforma es la variable y el número no finito de suscriptores; sin embargo, para actualizaciones sencillas en una lista finita de registros como pedidos, utilice la API de REST o SOAP para actualizar los registros.

En Salesforce:

  • Defina un evento de plataforma en Salesforce para incluir los datos de notificación procedentes del PMS.
  • Cree un flujo desencadenado por la notificación de evento de impresora. El proceso actualiza el activo de impresora y crea un pedido (utilizando un flujo iniciado automáticamente).
  • Descargue el WSDL de compañía o socio y proporciónelo al sistema remoto.

En el sistema remoto:

  • Cree un código auxiliar de cliente desde el WSDL de compañía o socio.
  • Autentique en Salesforce (a través del flujo de token de soporte o servidor web de OAuth) utilizando las credenciales del usuario de integración.
  • Tras el evento de estado de impresora, el PMS llama a la API para crear el evento de plataforma de estado de impresora (con estadísticas de uso de impresora). El bus de eventos de Salesforce notifica al suscriptor de Flow y a todos los demás suscriptores.

Cuando utiliza eventos de plataforma, el bus de eventos le permite reproducir eventos durante 72 horas para eventos de plataforma de gran volumen. La publicación de esos eventos utilizando una solución de middleware puede ayudar a incorporar la gestión de errores en el lado de la publicación. Sin embargo, puede implementar la gestión de errores en el lado de suscripción si necesita una fiabilidad superior.

Este ejemplo demuestra lo siguiente:

  • Implementación de un cliente de API síncrona de Salesforce (consumidor).
  • Una devolución de llamada a Salesforce para publicar un evento de plataforma (alineado con patrones de eventos de plataforma de solicitud/respuesta cubiertos anteriormente).

Context

Utiliza Salesforce para gestionar casos de clientes. Un representante de servicio al cliente está al teléfono con un cliente que trabaja en un caso. El cliente realiza un pago, y el representante de servicio al cliente necesita ver una actualización en tiempo real en la aplicación Salesforce desde la aplicación de procesamiento de pagos, indicando que el cliente pagó correctamente el importe pendiente del pedido.

Problema

Cuando se produce un evento en Salesforce, ¿cómo se puede notificar al usuario en la interfaz de usuario de Salesforce sin tener que actualizar su pantalla y posiblemente perder trabajo?

Fuerzas

Existen varias fuerzas a tener en cuenta al aplicar soluciones basadas en este patrón:

  • ¿Es necesario almacenar los datos sobre los que se están realizando acciones en Salesforce?
  • ¿Se puede crear una capa de interfaz de usuario personalizada para ver estos datos?
  • ¿Tendrá el usuario acceso para invocar la interfaz de usuario personalizada?

Solución

La solución recomendada para este problema de integración es utilizar eventos de plataforma que garantizan la realización de eventos casi en tiempo real en Salesforce. Eventos de plataforma proporciona una carga estructurada y flexible independiente de cualquier objeto de Salesforce. También garantiza temas duraderos con un plazo de reproducción de 72 horas. Esto garantiza que los eventos estén disponibles incluso si un consumidor sin conexión queda disponible más adelante. Esta solución se compone de los siguientes componentes:

  • Desencadenador Apex o Flujos con una lógica para publicar un evento de plataforma en un tema
  • Un tema que le permite publicar un evento desde Apex Trigger o Flow
  • Una implementación basada en JavaScript del protocolo Bayeux (actualmente CometD ) que puede ser utilizada por la interfaz de usuario
  • Un componente Lightning
  • Una biblioteca JavaScript incluida como un recurso estático

Boceto

El siguiente diagrama ilustra cómo se puede implementar la API de transmisión para transmitir notificaciones a la interfaz de usuario de Salesforce. Estas notificaciones se desencadenan por cambios de registro en Salesforce.

Actualización de interfaz de usuario en Salesforce desencadenada por un cambio de datos

Resultados

Beneficios

La aplicación de la solución relacionada con este patrón tiene los siguientes beneficios:

  • Elimina la necesidad de redactar mecanismos de sondeo personalizados
  • Elimina la necesidad de un bucle de comentarios iniciado por el usuario

Requisitos no admitidos

La solución tiene las siguientes limitaciones:

  • No se garantiza la entrega de notificaciones.
  • No se garantiza el orden de las notificaciones.
  • Las notificaciones no se generan desde cambios de registro realizados por la API masiva.

Consideraciones de seguridad

Se respeta la seguridad a nivel de organización de Salesforce estándar. Se recomienda que utilice el protocolo HTTPS para conectar con la API de transmisión. Consulte Consideraciones de seguridad

Barras laterales

La solución óptima implica la creación de una interfaz de usuario personalizada en Salesforce. Es imperativo que tenga en cuenta un contenedor de interfaz de usuario apropiado que se pueda utilizar para representar la interfaz de usuario personalizada. Los navegadores compatibles se enumeran en la Guía del desarrollador de API de transmisión

Ejemplo

Una compañía de telecomunicaciones utiliza Salesforce para gestionar casos de clientes. Los gestores de servicio al cliente desean que se les notifique cuando uno de sus representantes de servicio al cliente cierre correctamente un caso.

Implementando la solución prescrita por este patrón, el cliente debe:

  • Cree un PushTopic desencadenado por Apex que envíe un evento de plataforma cuando se guarde un caso con un estado de “Cerrado” y una resolución de “Exitoso”.
  • Cree una interfaz de usuario personalizada disponible para gestores de servicio al cliente. Esta interfaz de usuario se suscribe al bus de eventos para consumir eventos de plataforma.
  • Implemente lógica en la interfaz de usuario personalizada que muestra alertas generadas por los representantes de servicio al cliente de ese gestor.

Context

Utiliza Salesforce para realizar un seguimiento de prospectos, gestionar sus oportunidades en curso, crear oportunidades y capturar detalles de pedidos que convierten prospectos en clientes. Sin embargo, Salesforce no es el sistema que contiene o procesa pedidos. Los pedidos se gestionan por un sistema externo (remoto). Pero los representantes de ventas desean ver y actualizar información de pedidos en tiempo real en Salesforce sin necesidad de aprender o utilizar el sistema externo.

Problema

En Salesforce, ¿cómo puede ver, buscar y modificar datos almacenados fuera de Salesforce sin mover los datos del sistema externo a Salesforce?

Fuerzas

Existen varias fuerzas a tener en cuenta al aplicar soluciones basadas en este patrón:

  • ¿Desea crear una integración saliente declarativa/de apuntar y hacer clic o una interfaz de usuario en Salesforce?
  • ¿Tiene una gran cantidad de datos que no desea copiar en su organización de Salesforce?
  • ¿Necesita acceder a pequeñas cantidades de datos del sistema remoto en cualquier momento?
  • ¿Necesita acceso en tiempo real a los datos más recientes?
  • ¿Almacena sus datos en la nube o en un sistema de back-office, pero desea mostrar o procesar esos datos en su organización de Salesforce?
  • ¿Tiene problemas de residencia de datos para almacenar ciertos tipos de datos en Salesforce?

Solución

La siguiente tabla contiene varias soluciones a este problema de integración.

Solución Ajuste Comentarios
Salesforce Connect Mejor Utilice Salesforce Connect para acceder a datos de fuentes externas, junto con sus datos de Salesforce. Extraiga datos de sistemas como SAP, Microsoft, Oracle y otros sistemas basados en la nube como Snowflake en tiempo real sin realizar una copia de los datos en Salesforce.

Salesforce Connect asigna tablas de datos en sistemas externos a objetos externos en su organización. Los objetos externos son similares a los objetos personalizados, excepto que se asignan a datos ubicados fuera de su organización de Salesforce. Salesforce Connect utiliza una conexión en vivo con datos externos para mantener siempre actualizados los objetos externos. El acceso a un objeto externo obtiene los datos del sistema externo en tiempo real.

Salesforce Connect le permite:
  • Consulte datos en un sistema externo.
  • Cree, actualice y elimine datos en un sistema externo.
  • Acceda a objetos externos a través de vistas de lista, páginas de detalles, noticias en tiempo real de registros, fichas personalizadas y formatos de página.
  • Defina relaciones entre objetos externos y objetos estándar o personalizados para integrar datos desde diferentes orígenes.
  • Ejecute reportes (limitados) sobre datos externos.
  • Visualice los datos en la aplicación móvil Salesforce.

Para acceder a datos almacenados en un sistema externo utilizando Salesforce Connect, puede utilizar uno de los siguientes adaptadores:

  • Adaptador Odata 2.0 u adaptador Odata 4.0: se conecta a datos expuestos por cualquier productor Odata 2.0 o 4.0.
  • Adaptador entre organizaciones: se conecta a datos almacenados en otra organización de Salesforce. El adaptador entre organizaciones utiliza la API de REST de plataforma Lightning estándar. A diferencia de Odata, el adaptador entre organizaciones se conecta directamente a otra organización sin necesidad de un servicio web intermediario.
  • Adaptador personalizado creado mediante Apex: si los adaptadores Odata y entre organizaciones no son adecuados para sus necesidades, desarrolle su propio adaptador con el Marco de trabajo del conector Apex.
Solicitud y respuesta Suboptimal Utilice las API de servicios web de Salesforce para realizar solicitudes de datos ad-hoc para acceder y actualizar datos del sistema externo. Esta solución incluye los siguientes enfoques:

Utilice la API de SOAP de Salesforce. Una página o botón personalizado inicia una llamada REST/SOAP de Apex de forma síncrona. En Salesforce, puede consumir un WSDL y generar una clase Apex proxy resultante. Esta clase proporciona la lógica necesaria para llamar al servicio remoto. Una acción iniciada por el usuario en una página luego llama a una acción del controlador Apex que ejecuta esta clase Apex proxy para realizar la llamada remota. Las páginas requieren la personalización de la aplicación Salesforce.

Utilice la API de REST de Salesforce. Una página o botón personalizado inicia una llamada HTTP Apex (servicio REST) de forma síncrona. En Salesforce, puede invocar servicios HTTP utilizando métodos GET, POST, PUT y DELETE estándar.

Para obtener más información acerca de esta solución, consulte Invocación de procesos remotos: Solicitud y respuesta.

Boceto

El siguiente diagrama ilustra cómo puede utilizar Salesforce Connect para extraer datos de un sistema externo utilizando un adaptador Odata.

En este escenario:

  1. El navegador realiza una llamada AJAX que a su vez realiza una acción en el adaptador de objeto externo correspondiente.
  2. El adaptador traduce la acción en una solicitud Odata y realiza una solicitud GET HTTP al sistema remoto a través de las capas Integración y Servicios.
  3. El sistema remoto devuelve una respuesta JSON a Salesforce a través de las capas Integración y Servicios.
  4. La respuesta se traduce de Odata a un objeto externo y se presenta de nuevo al navegador.

Resultados

La aplicación de las soluciones relacionadas con este patrón permite invocaciones iniciadas por la interfaz de usuario en las que el resultado de la transacción puede mostrarse al usuario final.

Mecanismos de llamadas

El mecanismo de llamada depende de la solución elegida para implementar este patrón.

Mecanismo de llamada Descripción
Objetos externos Salesforce Connect asigna objetos externos de Salesforce a tablas de datos en sistemas externos. En vez de copiar los datos en su organización, Salesforce Connect accede a los datos on demand y en tiempo real. Aunque los datos se almacenan fuera de su organización, Salesforce Connect proporciona una integración sencilla con Lightning Platform. Los objetos externos están disponibles para herramientas de Salesforce, como la búsqueda global, las relaciones de búsqueda, las noticias en tiempo real de registros y la aplicación móvil Salesforce. Los objetos externos también están disponibles para consultas Apex, SOSL, SOQL, API de Salesforce e implementación a través de la API de metadatos, conjuntos de cambios y paquetes.
Componentes de iluminación Se utiliza cuando el proceso remoto se desencadena como parte de un proceso de extremo a extremo que implica la interfaz de usuario, y el resultado debe mostrarse o actualizarse en un registro de Salesforce. Por ejemplo, un proceso que envía pagos con tarjeta de crédito a una pasarela de pago externa y devuelve inmediatamente resultados de pago que se muestran al usuario. La integración desencadenada desde eventos de interfaz de usuario requiere habitualmente la creación de componentes Lightning personalizados.

Tratamiento de errores

Es importante incluir la gestión de errores como parte de la solución general. Cuando se produce un error (se devuelven excepciones o códigos de error al llamante), el llamante gestiona la gestión de errores. Salesforce Connect Validator es una herramienta gratuita para ejecutar algunas consultas comunes y detectar tipos de error y causas de fallo.

Beneficios

Algunos de los beneficios de utilizar una solución Salesforce Connect son:

  • Esta solución no consume almacenamiento de datos en Salesforce.
  • Los usuarios no tienen que preocuparse por la sincronización regular de datos entre el sistema externo y Salesforce.
  • Una configuración declarativa que se puede lograr rápidamente con Odata, o un adaptador entre organizaciones, o utilizando código mínimo con un adaptador Apex personalizado.
  • Los usuarios pueden acceder a datos externos con muchas de las mismas funciones que los objetos personalizados en forma de objetos externos.
  • Capacidad de realizar una búsqueda federada en el sistema externo conectado utilizando la búsqueda global.
  • Capacidad de ejecutar reportes que acceden a datos externos desde la nube y fuentes locales. Consulte las consideraciones de creación de reportes a continuación.

Consideraciones Salesforce Connect

La solución Salesforce Connect tiene las siguientes consideraciones:

Consideraciones de seguridad

Las soluciones para este patrón deben cumplir la seguridad a nivel de organización de Salesforce estándar. Se recomienda utilizar el protocolo HTTPS para conectar con cualquier sistema remoto. Para obtener más detalles, consulte Consideraciones de seguridad

Si está utilizando un conector Odata, asegúrese de comprender los comportamientos especiales, las limitaciones y las recomendaciones para la falsificación de solicitudes de sitio cruzado (CSRF) en orígenes de datos externos Odata. Para obtener más información, consulte Consideraciones de CSRF para Salesforce Connect: Adaptadores Odata 2.0 y 4.0.

Barras laterales

Ninguno.

Puntualidad

La puntualidad reviste una importancia considerable en este contexto. Tenga en cuenta los siguientes puntos:

  • La solicitud se invoca habitualmente desde la interfaz de usuario, de modo que el proceso no debe hacer esperar al usuario.
  • Dependiendo de la disponibilidad y la conexión con el sistema externo, puede tardar mucho tiempo en recuperar datos externos. Salesforce tiene un valor de tiempo de espera máximo de 120 segundos configurable para esperar una respuesta del sistema externo.
  • La finalización del proceso remoto debe ejecutarse de forma oportuna y completa dentro del límite de tiempo de espera de Salesforce y dentro de las expectativas del usuario.

Volúmenes de datos

Este patrón se utiliza principalmente para actividades en tiempo real de pequeño volumen, debido a los pequeños valores de tiempo de espera y el tamaño máximo de la solicitud o respuesta para la solución de llamada Apex. No utilice este patrón en actividades de procesamiento por lotes en las que la carga de datos está contenida en el mensaje.

Compatibilidad de funciones y estándares de extremos

La compatibilidad de funciones y estándares para el extremo depende de la solución que seleccione.

Solución Consideraciones sobre los extremos
Salesforce Connect API Odata: Utilice el Protocolo de datos abiertos para acceder a datos almacenados fuera de Salesforce. Los datos externos deben exponerse a través de productores Odata.

Otras API: Utilice el Marco de trabajo del conector Apex para desarrollar su propio adaptador personalizado cuando los otros adaptadores disponibles no son adecuados para sus necesidades. Un adaptador personalizado puede obtener datos de cualquier origen. Por ejemplo, algunos datos pueden recuperarse de Internet a través de llamadas, mientras que otros datos pueden manipularse o incluso generarse de forma programática.

Conectar con Salesforce: Utiliza la API de REST de Lightning Platform para acceder a datos almacenados en otras organizaciones de Salesforce.

Conectar a través de Middleware

Connect a través de Middleware: El ecosistema de socios Salesforce Connect ha trabajado estrechamente con Salesforce para asegurarse de que sus pasarelas de middleware exponen extremos Odata de su servicio de modo que Salesforce pueda conectar con ellos sin redactar código adicional.
Solicitud y respuesta Llamadas de SOAP Apex:

El extremo debe poder recibir una llamada de servicio web a través de HTTP.

Llamadas HTTP Apex -

El extremo debe poder recibir llamadas HTTP.

Puede utilizar llamadas HTTP Apex para llamar a servicios RESTful utilizando los métodos GET, POST, PUT y DELETE estándar

Gestión estatal

Al integrar sistemas, las claves son importantes para el seguimiento de estado continuo. Por ejemplo, si se crea un registro en el sistema remoto, normalmente el registro necesita algún tipo de clave de identificación para admitir actualizaciones en curso. Existen dos opciones para almacenar claves.

  • Salesforce almacena la clave de sustitución principal o exclusiva para el registro remoto.
  • El sistema remoto almacena el Id. de registro exclusivo de Salesforce o alguna otra clave sustitutiva exclusiva. Existen consideraciones específicas para la gestión de claves de integración en este patrón síncrono.
Sistema principal Descripción
Salesforce El sistema remoto almacena el Id. de registro de Salesforce o alguna otra clave sustitutiva exclusiva del registro.
Sistema remoto La llamada al proceso remoto devuelve la clave exclusiva de la aplicación, y Salesforce almacena ese valor de clave en un campo de registro exclusivo.

Integraciones complejas

En ciertos casos, la solución prescrita por este patrón puede requerir la implementación de un escenario de integración complejo. Estos escenarios a menudo se resuelven utilizando middleware.

  • Agregación de llamadas y sus resultados entre llamadas a múltiples sistemas
  • Transformación de mensajes entrantes y salientes
  • Mantenimiento de la integridad de las transacciones entre llamadas a múltiples sistemas
  • Otras actividades de orquestación de procesos entre Salesforce y el sistema externo

Límites vigentes

Se aplican diferentes límites para diferentes adaptadores. Para obtener más detalles, consulte Límites generales para Salesforce Connect.

Funciones de middleware

La siguiente tabla resalta las propiedades deseables de un sistema de middleware que participa en este patrón.

Propiedad Obligatorio Deseable No se requiere
Gestión de eventos X
Conversión de protocolo X
Traducción y transformación X
Colocación en cola y almacenamiento intermedio X
Protocolos de transporte síncronos X
Protocolos de transporte asíncronos X
Enrutamiento de mediación X
Coreografía de procesos y orquestación de servicios X
Transaccionalidad (cifrado, firma, entrega fiable, gestión de transacciones) X
Enrutamiento X
Extraer, transformar y cargar X
Sondeo largo X

Relaciones de objetos externos

Los objetos externos admiten relaciones de búsqueda estándar, que utilizan el Id. de registro de Salesforce de 18 caracteres para asociar registros relacionados. Sin embargo, los datos almacenados fuera de su organización de Salesforce a menudo no contienen esos Id. de registro. Por lo tanto, hay dos tipos especiales de relaciones de búsqueda disponibles para objetos externos: búsquedas externas y búsquedas indirectas.

Esta tabla resume los tipos de relaciones disponibles para objetos externos.

Relación Objetos secundarios permitidos Objetos principales permitidos Campo principal para coincidencia de registros
Búsqueda Estándar, Personalizado, Externo Estándar, personalizado El Id. de registro de Salesforce de 18 caracteres
Búsqueda externa Estándar, Personalizado, Externo Externo El campo estándar Id. externo
Búsqueda indirecta Externo Estándar, personalizado Seleccionar un campo personalizado con los atributos Id. externo y Exclusivo

Consideraciones de gran volumen de datos para Salesforce Connect: Adaptadores Odata 2.0 y 4.0

Si su organización alcanza límites de frecuencia al acceder a objetos externos, considere seleccionar la opción Gran volumen de datos en las fuentes de datos externas asociadas. Al hacerlo se omiten la mayoría de los límites de frecuencia, pero se aplican algunos comportamientos y limitaciones especiales. Para obtener más información, consulte Consideraciones de gran volumen de datos para Salesforce Connect.

Página dirigida por el cliente y dirigida por el servidor para Salesforce Connect: Adaptadores Odata 2.0 y 4.0

Es común que las consultas Salesforce Connect de datos externos tengan un conjunto de resultados grande que se divide en lotes o páginas más pequeños. Usted decide si el comportamiento de la paginación está controlado por el sistema externo (dirigido por el servidor) o por el adaptador Odata 2.0 o 4.0 para Salesforce Connect (dirigido por el cliente). El campo Paginación dirigida por el servidor en el origen de datos externo especifica si utilizar la paginación dirigida por el cliente o dirigida por el servidor. Si activa la paginación dirigida por servidor en un origen de datos externo, Salesforce ignora los tamaños de página solicitados, incluyendo el tamaño de lote predeterminado de queryMore() de 500 filas. Las páginas devueltas por el sistema externo determinan los lotes, pero cada página no puede superar 2.000 filas. Sin embargo, los límites para los adaptadores Odata para Salesforce Connect aún se aplican.

Ejemplo

Una compañía de fabricación utiliza Salesforce para gestionar casos de clientes. Los agentes de servicio al cliente desean acceder a la información de pedidos en tiempo real desde el sistema ERP de back-office para obtener una vista 360 del cliente sin necesidad de aprender y ejecutar reportes manualmente en ERP.

Implementando la solución prescrita por este patrón, debe:

  • Configure su origen de datos externo con un extremo Odata. Su aplicación remota puede incluir compatibilidad nativa con Odata. Para otras aplicaciones, los principales proveedores de integración como Dell Boomi, Informatica, Jitterbit, MuleSoft y Progress Software se asociaron con Salesforce en Salesforce Connect para crear adaptadores.
  • Apunte Salesforce Connect al extremo de Odata, ya sea directamente o a través de una solución de middleware.
  • Sincronice sus tablas de base de datos externas con objetos externos en Salesforce. Cuando un usuario accede a una página con datos de estos objetos externos, Salesforce Connect realiza llamadas en tiempo real a sus aplicaciones de back-end.

Documentación de desarrollador

Trailhead

Para ser miembros efectivos de la cartera de empresas, todas las solicitudes deben crearse e integrarse con los mecanismos de seguridad pertinentes. Las estrategias de TI modernas emplean una combinación de servicios locales y basados en la nube.

Aunque la integración de servicios de nube a nube normalmente se centra en servicios web y autorización asociada, la conexión de servicios en las instalaciones y en la nube a menudo introduce una complejidad aumentada. Esta sección describe herramientas de seguridad, técnicas y consideraciones específicas de Salesforce.

Servidor proxy inverso

Un proxy inverso es un servidor que se encuentra frente a servidores web y reenvía solicitudes de cliente (por ejemplo, navegador web) a esos servidores web. Los proxies inversos se implementan habitualmente para ayudar a aumentar la seguridad, el desempeño y la fiabilidad.

Es un tipo de servidor proxy que recupera recursos en nombre de un cliente desde uno o más servidores. Estos recursos se devuelven al cliente como si se originaran desde el servidor proxy en sí. A diferencia de un proxy directo, que es un intermediario para que sus clientes asociados hagan contacto con cualquier servidor, un proxy inverso es un intermediario para que cualquier cliente haga contacto con sus servidores asociados.

En implementaciones de Salesforce, dicho servicio se proporciona habitualmente a través de un producto de pasarela externo. Por ejemplo, se pueden utilizar opciones de código abierto como HTTP de Apache, lighttpd y nginix. Los productos comerciales incluyen IBM WebSeal y SiteMinder de Asociados de computación. Estos productos se pueden configurar fácilmente para representar y gestionar todas las solicitudes de Salesforce salientes en nombre del solicitante interno.

Cifrado

Algunas compañías requieren que las transacciones o los campos de datos seleccionados se cifren entre una combinación de aplicaciones locales y basadas en la nube. Si su organización debe cumplir requisitos de cumplimiento adicionales, puede implementar alternativas, incluyendo:

  • Servicios de pasarela de cifrado comercial in situ, incluyendo los propios de Salesforce, CipherCloud, IBM DataPower, Computer Associates. Para cada solución, el motor de cifrado o la pasarela se invocan en el límite de la transacción enviando y recibiendo una carga cifrada o al cifrar o descifrar campos de datos específicos antes de que se ejecute la solicitud HTTP(S).

  • Opciones basadas en la nube, como Salesforce Shield Platform Encryption. Shield Platform Encryption proporciona a sus datos una capa completamente nueva de seguridad mientras mantiene funciones de plataforma críticas. Los datos que seleccione se cifran en periodos de inactividad utilizando un sistema de derivación de claves avanzado. Puede proteger sus datos de forma más segura que nunca. Consulte la ayuda online de Salesforce para obtener más información.

Compatibilidad con protocolos WS-* especializados

Para tratar los requisitos de protocolos de seguridad (como WS-*), recomendamos estas alternativas.

  • Pasarela Security/XML: Inyecte credenciales de WS-Security (IBM WebSeal o Datapower, Capa7, TIBCO, etc.) en la transmisión de transacciones en sí. Este enfoque no requiere cambios en los servicios web a nivel de aplicación o invocaciones de servicio web desde Salesforce. También puede reutilizar este enfoque en la instalación de Salesforce. Sin embargo, requiere diseño, configuración, pruebas y mantenimiento adicionales para gestionar la inyección de WS-Security apropiada en el enfoque de pasarela de seguridad existente.

  • Cifrado a nivel de transporte: Cifre el canal de comunicación utilizando restricciones SSL e IP bidireccionales. Aunque este enfoque no implementa directamente el protocolo WS-* por sí mismo, protege el canal de comunicación entre las aplicaciones locales y Salesforce sin pasar un nombre de usuario y una contraseña. Tampoco requiere cambios en clases generadas por Salesforce. Sin embargo, es posible que se requieran algunas modificaciones de servicios web locales (en la aplicación en sí o en la capa middleware/ESB).

  • Desarrollo personalizado de Salesforce: Agregue encabezados de WS-Security a la solicitud de SOAP saliente a través de la utilidad WSDL2Apex. Esto genera una clase de Apex similar a Java desde el archivo WSDL utilizado para invocar el servicio interno. Aunque este enfoque no requiere cambios en servicios web back-end o componentes adicionales en la DMZ, requiere:

    • un esfuerzo de construcción y prueba aumentado
    • un proceso relativamente complejo y manual para codificar manualmente los atributos de WS-Security (incluyendo la serialización XML dentro del código Apex)
    • un mayor esfuerzo de mantenimiento a largo plazo

Nota: La última opción no se recomienda debido a su complejidad y el riesgo de que dichas integraciones necesiten revisiones periódicas basadas en actualizaciones regulares en Salesforce.

Otras consideraciones de seguridad

  • Credenciales nombradas: Destinada a proteger y simplificar llamadas de API autenticadas a sistemas externos, una credencial nombrada especifica la URL de un extremo de llamada y sus parámetros de autenticación requeridos en una sola definición. Para simplificar su código Apex y simplificar la configuración de llamadas autenticadas, especifique una credencial nombrada como el extremo de llamada. Para más detalles consulte aquí.

  • OAUTH 2.0: OAuth 2.0 es un marco de trabajo de autorización estándar de la industria que permite a un usuario otorgar acceso limitado a sus recursos protegidos a una aplicación externa sin compartir sus credenciales (como contraseñas). En vez de un intercambio de contraseña directo, el usuario aprueba una solicitud de token de acceso, que la aplicación utiliza a continuación para acceder a los datos del usuario desde un servidor de recursos. Este proceso separa la aplicación cliente de la identidad y contraseña del usuario, mejorando la seguridad proporcionando una "clave" temporal específica del ámbito para acceder a los recursos. Para más información consulte aquí.

  • Conexión privada: Cuando integra su organización de Salesforce con aplicaciones alojadas en servicios de nube externos, es esencial poder enviar y recibir tráfico HTTP/s de forma segura. Con Private Connect, aumente la seguridad en sus integraciones de Amazon Web Services (AWS) configurando una conexión de red completamente gestionada entre su organización de Salesforce y su AWS Virtual Private Cloud (VPC). A continuación, enrute su tráfico entre nubes a través de la conexión en vez de a través de Internet pública para reducir la exposición a amenazas de seguridad externas. Private Connect está disponible en asociación con AWS a través de una función denominada AWS PrivateLink. Conexión privada es bidireccional: puede iniciar el tráfico entrante y saliente. Con conexiones entrantes, puede enviar tráfico a Salesforce utilizando las API estándar. Además, con conexiones salientes, puede enviar tráfico fuera de Salesforce a través de funciones como llamadas Apex, Servicios externos y Objetos externos. Para más información sobre VPC, por favor aquí.

El Bus de eventos de Salesforce con Eventos de plataforma, Captura de datos de cambios (CDC) y API Pub / Sub permite a las empresas crear arquitecturas de estilo dirigidas por eventos (EDA).

Una EDA desvincula consumidores de mensajes de eventos (suscriptores) de productores de mensajes de eventos (editores), permitiendo una mayor escala y flexibilidad. Los patrones específicos se tratan en este documento como parte de la estructura de patrones existente que compara y contrasta alternativas u opciones relacionadas. Sin embargo, obtener una comprensión holística de la arquitectura dirigida por eventos y cómo interactúan los patrones puede ayudarle a seleccionar el patrón correcto para sus necesidades.

Khalid Mohammed es un distinguido líder Arquitecto en Servicios profesionales de Salesforce. Desde su incorporación a Salesforce en 2015, ha aprovechado su amplia experiencia en Arquitectura y aplicaciones de negocio, perfeccionada a través de numerosas transformaciones de clientes antes de su permanencia en Salesforce. Khalid dirige el Consejo de Arquitectura de entregas y también es reconocido como líder de Arquitecto Técnico Certificado.

Gulal Kumar es Arquitecto de Ingeniería de Software en Salesforce, con un enfoque en datos y arquitectura de integración. Con más de 20 años de experiencia en integración y API, programas de modernización, seguridad e iniciativas AIML, aporta una gran experiencia. Gulal se ha comprometido a avanzar en iniciativas de transformación de negocio, mejorando la seguridad y la resiliencia, promoviendo la excelencia de la arquitectura y liderando iniciativas de AIML entre varios dominios.

Sushant es Arquitecto Técnico de Salesforce, especializado en arquitectura de soluciones y entrega integral de plataformas de Salesforce. Con amplia experiencia en gobernanza de plataforma, desarrollo de aplicaciones, integración y DevOps, ha liderado numerosos programas de transformación de clientes entre industrias. Sushant se compromete a impulsar la excelencia de entrega y resultados arquitectónicos ampliables.