El procesamiento asíncrono aumenta la escalabilidad permitiendo límites más altos por contexto. Las solicitudes asíncronas se ejecutan en sus propios hilos en segundo plano, de modo que los usuarios pueden continuar realizando trabajo en el lado del cliente cuando las tareas asíncronas se ejecutan en segundo plano.

Salesforce Lightning Platform ofrece una variedad de tecnologías asíncronas que se pueden utilizar para resolver un caso de uso concreto. Cada tecnología tiene beneficios y límites que deberá tener en cuenta al seleccionar un enfoque para cada caso de uso.

Al elegir una tecnología para la implementación, tres consideraciones importantes a tener en cuenta son:

1. El procesamiento asíncrono no es el mejor enfoque para cada problema. Puede ser tentador pensar en cualquier proceso que no requiera directamente la interacción del usuario como un buen candidato para el procesamiento asíncrono, pero existen algunos inconvenientes. En primer lugar, los procesos asíncronos no tienen SLA, lo que significa que no hay garantía de que un proceso asíncrono se complete en un plazo establecido. En segundo lugar, no hay garantía de una latencia de respuesta coherente. Si un proceso asíncrono se completa en un periodo de tiempo determinado, un proceso posterior puede tardar un periodo de tiempo diferente en completarse. Por lo tanto, incluso si un usuario no está esperando directamente una respuesta, el procesamiento asíncrono podría no ser adecuado para su escenario si tiene procesos posteriores que dependen de una respuesta, o si le preocupa que los tiempos de respuesta excesivos puedan provocar que sus datos no estén sincronizados con los datos en un sistema externo.
2. Existen diferentes formas de procesar solicitudes asíncronas en Salesforce Platform, de modo que asegúrese de elegir el mejor enfoque. Las tecnologías que admiten el procesamiento asíncrono en Salesforce Platform funcionan de forma diferente “bajo el capó”, y algunas se diseñaron para casos de uso muy específicos.
3. Si una tecnología es asíncrona en el lado del cliente, no significa necesariamente que todo el procesamiento de extremo a extremo se realice en paralelo. Dependiendo de las opciones que realice, los mensajes del cliente a veces pueden seguir serializándose en el lado del servidor.

Si utiliza las tecnologías incorrectas o las combinaciones incorrectas de tecnologías para un trabajo, pueden producirse consecuencias no deseadas que cancelan los beneficios del procesamiento asíncrono. Esta guía proporciona explicaciones y recomendaciones, así como posibles inconvenientes y antipatrones para varios casos de uso asíncronos, junto con la justificación de esas recomendaciones. También proporciona perspectivas sobre cómo funcionan y se regulan varias técnicas de implementación asíncronas en Salesforce Platform.

Si está tomando una decisión acerca de qué tecnología utilizar, existe una Guía de decisiones de procesamiento asíncrono centrada que proporciona una asignación rápida de casos de uso típicos a la tecnología más adecuada.

Salesforce Lightning Platform es una plataforma integral dirigida por IA que unifica empleados, agentes de IA autónomos, datos de la compañía y aplicaciones en un único sistema de confianza para mejorar la productividad y la experiencia del cliente. Permite la creación de una "compañía agencia" conectando aplicaciones Customer 360, Data Cloud y Slack para la automatización de extremo a extremo.

Este documento no cubre tecnologías en otros ecosistemas como MuleSoft, Informatica, Commerce Cloud, Tableau y Marketing Cloud.

Tenga en cuenta que esta guía se centra exclusivamente en el procesamiento asíncrono en Salesforce Lightning Platform. Si está buscando información acerca de patrones de integración asíncronos, consulte Arquitectura dirigida por eventos.

• Antes de utilizar el procesamiento asíncrono, asegúrese de que sus casos de uso se ajustan al patrón. Los patrones asíncronos no tienen SLA, están sujetos a múltiples mecanismos reguladores, pueden tener límites de capacidad definidos basándose en licencias y pueden causar retrasos de procesamiento debido a la naturaleza finita de los recursos asignados a infraestructura asíncrona en Salesforce Platform. Tenga en cuenta estas limitaciones cuando utilice el procesamiento asíncrono en escenarios donde un usuario requiere una respuesta del sistema antes de poder continuar con su trabajo.
• El procesamiento asíncrono con Salesforce no es una solución para necesidades de ampliación ilimitadas. Salesforce Platform no se amplía infinitamente, y los patrones asíncronos aún están sujetos a limitaciones. El procesamiento asíncrono utiliza hilos, que contienen la información contextual que una CPU necesita para ejecutar una transmisión de instrucciones. Las cadenas pueden ejecutarse en paralelo. El número de hilos disponibles en cualquier CPU es limitado, de modo que la plataforma tiene mecanismos establecidos para garantizar que sus hilos disponibles se utilizan de la forma más eficiente posible. El mecanismo de control de flujo de la plataforma evita que las organizaciones consuman demasiados hilos y afecten negativamente a otras organizaciones. El algoritmo de uso justo de la plataforma controla el número de hilos que una organización tiene disponibles para cada tipo de mensaje concreto.
• Sepa cuándo las transacciones son verdaderamente asíncronas. Algunos patrones de arquitectura se comportan de forma asíncrona de extremo a extremo. Sin embargo, otros procesos se comportan de forma asíncrona en el lado del cliente o del navegador, pero serializan solicitudes del lado del servidor, que luego están sujetas a límites reguladores síncronos.
• Para crear integraciones salientes a gran escala desde Salesforce Platform, utilice eventos de plataforma y middleware sólido en vez de llamadas a través de Apex asíncrono. Debido a que hay un número finito de hilos asíncronos disponibles en la plataforma, las integraciones salientes a través de Apex asíncrono tienen una capacidad de ampliación limitada. Si su organización tiene integraciones salientes que implican altos volúmenes de mensajes, superan el número de hilos disponibles y tienen largos tiempos de procesamiento, el uso de Apex asíncrono inevitablemente introducirá retrasos.
• Asegúrese de incorporar monitoreo cuando utilice procesamiento asíncrono. Con el monitoreo, puede detectar problemas lo antes posible y corregirlos antes de que se produzcan incidentes de desempeño importantes.
• Tenga en cuenta eventos que pueden causar cargas extremas. Cuando diseñe procesos asíncronos, asegúrese de que pueden gestionar de forma predecible picos y pausas de carga de trabajo. Considere cómo gestiona su implementación eventos inesperados, como cortes de energía, y diseñe salvaguardas que mitiguen la pérdida de datos o la pérdida de funciones.

Cuando selecciona un enfoque para el procesamiento asíncrono del lado del servidor, primero evalúe los requisitos de su organización y los recursos disponibles. Su objetivo es seleccionar un enfoque que minimice los costos de implementación y mantenimiento garantizando al mismo tiempo la capacidad de ampliación y minimizando su probabilidad de limitar las infracciones. Este objetivo depende de las consideraciones técnicas descritas en las siguientes secciones, así como de la composición de su equipo. Por ejemplo, considere si tiene desarrolladores Apex en su equipo que puedan mantener su solución de procódigo. De lo contrario, un enfoque declarativo puede tener más sentido. Además, tenga en cuenta que diferentes conjuntos de límites pueden aplicarse a diferentes herramientas.

Considere el caso de uso de un proceso de pedido asíncrono en Salesforce. Cuando se guarda un pedido, desencadena un mensaje a un sistema de gestión de almacén externo con instrucciones especiales sobre cómo empaquetar y enviar un artículo. El usuario que realiza el pedido no necesita una respuesta inmediata del sistema de gestión de almacenes, de modo que la solicitud se puede enviar de forma asíncrona. El procesamiento asíncrono permite al usuario continuar su trabajo sin demoras.

Consideraciones para su arquitectura:

• ¿Cuántos procesos simultáneos se necesitan?
• ¿Cómo interactuará el proceso simultáneo entre sí?
• ¿Cuántas consultas SOQL se ejecutarán en cada proceso?
• ¿Cuántas operaciones DML se ejecutarán en cada proceso?
• ¿Cuánto tiempo durará cada proceso?
• ¿Qué grado de sensibilidad tienen los procesos para una cronología específica?

La arquitectura de múltiples arrendatarios de Salesforce Platform aísla y admite simultáneamente los requisitos variables de muchos arrendatarios (organizaciones). Todos los métodos Apex asíncronos cubiertos en esta guía se ejecutan dentro de la misma infraestructura asíncrona en Salesforce Platform. Utilizan un marco de trabajo de cola de mensajes que se rige por dos mecanismos de aplicación principales: control de flujo y uso justo.

El control de flujo y los mecanismos de uso justo evitan que un arrendatario único utilice demasiados recursos de servidor y no deje suficientes recursos para los arrendatarios restantes. Aunque es útil comprender cómo funcionan estos mecanismos, su conclusión clave debe ser que el seguimiento de mejores prácticas de procesamiento asíncrono, como las descritas en las siguientes secciones, reduce significativamente su probabilidad de tener problemas con ellos.

El mecanismo de control de flujo de la plataforma evita que una organización inunde un tipo de mensaje concreto, lo que consume demasiados hilos y afecta negativamente a otras organizaciones. Antes de que el marco agregue nuevas entradas a la cola asociada con un tipo de mensaje, comprueba las primeras miles de entradas existentes en la cola. Si la mayoría de las entradas existentes están asociadas con esa misma organización y esa organización ya tiene entradas en hilos de trabajo, las entradas recién agregadas se trasladan a la parte posterior de la cola. Este proceso se denomina volver a colocar en cola. La recolocación en cola suele producirse en procesos de Apex por lotes y API masiva porque a menudo insertan un gran número de entradas en sus colas al mismo tiempo.

El mecanismo de uso justo de la plataforma implementa un sistema basado en niveles. El sistema garantiza que cada organización en Salesforce Platform obtiene una parte justa del tiempo de procesamiento para un tipo de mensaje concreto, incluyendo tipos de mensajes Futuro, Colocable en cola y Por lotes. Si una organización domina un tipo de mensaje concreto durante el mismo tiempo que otras organizaciones están esperando para realizar trabajo en el mismo tipo de mensaje, el algoritmo de uso justo reduce el número de hilos que la organización tiene disponibles para ese tipo de mensaje concreto.

Un beneficio de utilizar métodos Apex asíncronos es que algunos límites reguladores, como los límites de consulta SOQL y los límites de tamaño de pila, son más altos. Sin embargo, no se base demasiado en estos métodos. Debido a los recursos finitos asignados a la infraestructura asíncrona, el uso intensivo de Apex futuro, colocable en cola y por lotes puede causar retrasos de procesamiento derivados de limitaciones basadas en el uso justo y el control de flujos.

Las llamadas salientes que utilizan Apex asíncrono cuentan en el límite de Apex asíncrono. El límite diario es actualmente 250.000 o 200 veces el número de licencias de usuario aplicables, cualquiera que sea superior. Este límite puede ser un problema para casos de uso de gran volumen. Si supera el límite, sus trabajos de Apex asíncronos y sus llamadas salientes asociadas fallarán.

Además, debido a que la plataforma tiene un número finito de hilos asíncronos disponibles, las integraciones salientes a través de Apex asíncrono tienen una capacidad de ampliación limitada. Cualquier integración saliente de gran volumen que supere el número de hilos disponibles puede tener largos tiempos de procesamiento y provocar retrasos.

Para casos de uso de gran volumen, considere estos enfoques alternativos. Las llamadas de API con estos enfoques cuentan en el límite de solicitudes de API diarias, que es significativamente superior al límite de Apex asíncrono diario. Por lo tanto, estos enfoques son más ampliables. Tenga en cuenta, sin embargo, que aún existen limitaciones físicas en el número de solicitudes simultáneas que cualquier CPU puede procesar.

• Extracción programada de middleware. Evite retrasos asociados con trabajos de integración salientes de gran volumen utilizando middleware para extraer los datos de forma programada en vez de enviarlos mediante Apex asíncrono. El middleware, como MuleSoft Anypoint Platform, puede utilizar la API de SOAP nativa o la API de REST de forma síncrona de modo que se introduzcan pocos retrasos, si los hubiera. El middleware también puede utilizar la API masiva nativa para grandes volúmenes de datos.

• Extracción de middleware a través de Notificación de evento de plataforma. En vez de poner en cola Apex asíncrono Futuro, Colocable en cola o Por lotes para realizar integraciones salientes, puede utilizar eventos de plataforma. El evento de plataforma puede entregar la información saliente en sí o indicar a una herramienta de middleware que extraiga la información requerida a través de una API nativa y la entregue a su destino final. Ninguno de estos enfoques está sujeto a los retrasos a los que está sujeto Apex asíncrono. Sin embargo, los límites de eventos de plataforma aún se aplican.

Con Apex colocable en cola, puede ejecutar procesos Apex que implican operaciones de base de datos extensas o llamadas de servicios web externos de forma asíncrona. Para utilizar Apex colocable en cola, implemente la interfaz Colocable en cola y luego agregue un trabajo a la cola de trabajos Apex. Este enfoque garantiza que el trabajo Apex asíncrono se ejecute en segundo plano en su propio hilo aislado y no retrase la ejecución de su lógica Apex principal. Cada trabajo en cola se ejecuta cuando los recursos del sistema están disponibles.

Apex colocable en cola representa la evolución del Apex asíncrono. Ofrece funciones que no están disponibles para métodos futuros de Apex, incluyendo:

• Id. de trabajo: Cuando envía un trabajo invocando el método System.enqueueJob, el método devuelve el Id. del nuevo trabajo. Puede utilizar este Id. para identificar su trabajo. Para monitorear su progreso, vea la página Trabajos de Apex en Configuración de Salesforce o consulte el objeto AsyncApexJob.
• Soporte para tipos no primitivos: Las clases colocables en cola pueden contener variables de miembros de tipos de datos no primitivos, como sObjects o tipos Apex personalizados.
• Soporte para encadenamiento de trabajos: Puede encadenar trabajos colocables en cola entre sí iniciando un segundo trabajo desde un trabajo en ejecución. Esta técnica puede ayudarle a solucionar escenarios que implican dependencias de procesos.
• Control de profundidad máximo: Puede configurar trabajos colocables en cola con una profundidad de pila máxima para garantizar que las cadenas de trabajos no terminen con una repetición inesperada.
• Firmas de deduplicación: Los trabajos colocables en cola proporcionan una firma opcional para detectar y eliminar trabajos duplicados.
• Demora configurable: Puede definir un retraso de hasta 10 minutos antes de que se ejecute el trabajo Colocable en cola.
• Finalizadores de transacciones: Puede adjuntar una secuencia posterior a la acción a un trabajo Colocable en cola y realizar acciones relevantes basándose en su resultado. Por ejemplo, un finalizador de transacciones puede volver a poner en cola un trabajo colocable en cola que falló debido a una excepción no gestionada hasta cinco veces.

Salesforce utiliza un marco de trabajo basado en colas para gestionar procesos asíncronos. Esta cola se utiliza para equilibrar cargas de trabajo de solicitudes entre organizaciones. Para asegurarse de que su organización utiliza esta cola de la forma más eficiente posible:

• Evite poner en cola métodos futuros o colocables en cola directamente desde acciones generadas por grandes volúmenes de actividad de usuario final o llamadas de API de integración. Este enfoque puede agotar rápidamente los límites de Apex asíncronos diarios, dando como resultado impactos de negocio graves.
• Evite poner en cola más de una acción asíncrona por acción síncrona. Cuando se ponen en cola múltiples métodos asíncronos desde una sola acción síncrona, las actividades asíncronas a menudo se ejecutan al mismo tiempo y contribuyen a errores de tiempo de espera de bloqueo de filas y/o contención de bloqueo de filas.
• Evite agregar un gran número de métodos futuros o colocables en cola a la cola asíncrona.
• Asegúrese de que los métodos futuros y colocables en cola se ejecutan lo más rápido posible. Cuanto más tarde un método futuro en ejecutarse, más posibilidades habrá de que las solicitudes que se encuentren detrás de él en la cola se retrasen. Para garantizar la ejecución rápida de trabajos por lotes, minimice los tiempos de llamadas de servicios web, ajuste las consultas utilizadas en sus métodos futuros y optimice cualquier otra automatización de objetos incluyendo procesos de Process Builder, reglas de flujo de trabajo, flujos y desencadenadores Apex.
• Pruebe sus métodos asíncronos a escala. Utilice un entorno que genere el número máximo de métodos que espera gestionar. Esta prueba ayuda a determinar si encontrará problemas con el desempeño o los límites en su entorno de producción. Considere también la repercusión en los límites diarios acumulados.
• Utilice Apex por lotes en vez de métodos futuros o colocables en cola para procesar un gran número de registros. Apex por lotes puede gestionar procesos complejos de larga ejecución que se ejecutan en miles de registros y se pueden programar para ejecutarse durante las horas libres cuando hay más recursos disponibles.

Utilice Apex programado para ejecutarse a una hora especificada y con una frecuencia repetida como se define por una expresión cron. Aunque el acto de programar Apex mediante la expresión cron es un proceso asíncrono, el código subyacente se ejecuta de forma síncrona cuando se inicia el trabajo. Apex programado es ideal para tareas de mantenimiento diarias o semanales.

• Solo puede tener 100 trabajos Apex programados a la vez. Para evitar esta limitación, considere utilizar un flujo desencadenado por programación que invoca código Apex en vez de utilizar Apex programado.
• Tenga mucho cuidado si está planificando programar una clase desde un desencadenador. Debe poder garantizar que el desencadenador no agregará más clases programadas que el límite. En particular, considere actualizaciones masivas de API, asistentes de importación, cambios de registro masivos a través de la interfaz de usuario y todos los casos donde se puede actualizar más de un registro a la vez.
• Para tareas puntuales que necesitan programarse hasta 10 minutos en el futuro, utilice un trabajo Colocable en cola retrasado. Este enfoque no cuenta en el límite de 100 trabajos programados.
• Apex programado se ejecuta en un contexto síncrono con límites síncronos.
• Considere el tiempo durante el que se ejecutará el trabajo programado. Un trabajo de larga duración puede solaparse con el inicio del siguiente trabajo programado.
• Salesforce programa la clase para su ejecución a la hora especificada. La ejecución real puede retrasarse en base a la disponibilidad del servicio. Los trabajos programados para ejecutarse durante el tiempo de inactividad de mantenimiento del servicio se programarán para ejecutarse después de que vuelva a aparecer el servicio.
• Utilice System.scheduleBatch para programar trabajos por lotes en vez de tener un trabajo programado con el único propósito de poner un trabajo por lotes en cola.

Históricamente, las llamadas síncronas realizadas desde un método Apex ejecutándose en un contexto de transacción Apex síncrono, como un controlador Visualforce o un controlador de componente Lightning, estaban sujetas al límite de concurrencia Apex respecto de solicitudes de larga duración. A partir de Winter ’19, las llamadas síncronas ya no se cuentan como de larga duración. Aunque las continuaciones Apex se crearon inicialmente como una solución a llamadas síncronas que dieron como resultado solicitudes de larga ejecución, también proporcionan algunos beneficios adicionales.

• Una sola acción síncrona puede realizar hasta tres acciones de continuación. La continuación anterior debe completarse antes de que se realice una nueva acción de continuación.
• Cada acción de continuación puede realizar hasta un máximo de tres llamadas, que se ejecutan en paralelo.
• Cuando todas las llamadas realizadas por una acción de continuación están completas, la plataforma invoca el método de devolución de llamada de continuación para gestionar los resultados.

Aunque las continuaciones se ejecutan de forma asíncrona con respecto a la acción síncrona de origen, existen diferencias clave entre Apex Continuations y otras técnicas Apex asíncronas como métodos futuros, Colocable en cola o Por lotes. Las diferencias clave son:

• Las continuaciones no están en cola de ninguna manera.
• Las continuaciones no contribuyen al límite de ejecución de Apex asíncrono diario.
• Las continuaciones cambian el contexto de hilo en el servidor de aplicaciones de un hilo de plataforma Apex pesado a un hilo ligero que solo realiza llamadas. Para fines de ejecución de llamadas que pueden ejecutarse hasta 120 segundos, las continuaciones ofrecen ahorros de memoria significativos del servidor de aplicaciones.
• Originalmente, las continuaciones solo se podían ejecutar desde una llamada remota de Visualforce JavaScript. Sin embargo, en Summer ‘19, las continuaciones se agregaron oficialmente al marco de componentes Lightning, lo que eliminó la necesidad de Visualforce.

Los eventos de plataforma son la implementación de Salesforce Platform de una arquitectura dirigida exclusivamente por eventos. Puede encontrar más detalles acerca de los componentes asociados con este tipo de arquitectura en la Guía del arquitecto de arquitectura dirigida por eventos.

Los eventos de plataforma y los desencadenadores/flujos de eventos de plataforma son a menudo excelentes alternativas a ejecutar Apex asíncrono. También son una excelente forma de invocar el procesamiento fuera de la plataforma. Por ejemplo, puede utilizar una combinación de retransmisiones de eventos de Amazon Web Services (AWS) y eventos de plataforma para invocar funciones de computación sin servidor en AWS Lambda. El trabajo que se realiza con relativa rapidez y sin ninguna llamada (que no es posible desde un flujo o desencadenador de evento de plataforma) es un excelente candidato para una combinación de evento/desencadenador de plataforma o evento/flujo.

Los eventos publicados en el bus a través de publicación después de confirmación se entregan en orden y pueden procesarse de forma masiva por el desencadenador o el flujo en un contexto síncrono separado. El contexto es síncrono y aplica todos los límites reguladores síncronos. Seleccione el desencadenador de evento de plataforma/tamaño de lote de flujo cuidadosamente para evitar alcanzar límites.

• Como los eventos se publican en el bus de eventos, están disponibles para consumidores. En el caso de desencadenadores de eventos (Apex o flujo), estos eventos se despachan a hilos síncronos disponibles en el nivel de aplicación (un hilo por desencadenador/flujo de evento). Tenga en cuenta que este proceso no tiene un SLA.
• Cuando se agregan operaciones de publicación a la cola, el resultado del proceso de colocación en cola se almacena en el objeto Database.SaveResult. Estas entradas solo indican si la operación de colocación en cola se realizó correctamente o no. Para obtener el resultado final de un evento publicado a través del bus de eventos, implemente una devolución de llamada de publicación Apex. Con esta información adicional, puede tomar decisiones sobre más acciones, como intentar volver a publicar eventos con fallos.
• Aunque los eventos de plataforma no están sujetos a los mismos límites que Apex asíncrono, tienen sus propios conjuntos de límites reguladores. Si se encuentra con problemas con límites, puede activar mediciones de uso de eventos mejoradas para determinar si eventos específicos están utilizando más de sus asignaciones de lo que pretendía. Si necesita un mayor rendimiento en desencadenadores de eventos, considere utilizar suscripciones paralelas para procesar eventos de forma simultánea en vez de en una sola transmisión. Con suscripciones paralelas, puede ampliar desencadenadores de eventos de plataforma Apex para gestionar grandes volúmenes de eventos. Las suscripciones paralelas están disponibles para eventos de plataforma de gran volumen personalizados pero no para eventos estándar o eventos de cambio.
• Los eventos de plataforma tienen dos opciones para el comportamiento de publicación:
  • Publicar inmediatamente: Los eventos se publican inmediatamente durante la transacción, antes de la confirmación final de la base de datos. No se garantiza que los eventos publicados de esta forma se publiquen en orden.
  • Publicar después de confirmar: Los eventos se publican en el momento en que la transacción de la base de datos se confirma correctamente. Los eventos que se publican de esta forma tienen garantizada su publicación en orden.

Es útil utilizar Publicar inmediatamente para casos de uso como el registro, donde desea publicar el evento de registro independientemente de si la transacción se realiza correctamente y se confirma, o falla y se revierte. Es posible publicar inmediatamente un evento de plataforma consumido por un desencadenador de evento de plataforma. El desencadenador de evento de plataforma compite a continuación por un bloqueo de fila de base de datos con la transacción que lo publicó. Revise todos los diseños minuciosamente antes de publicar inmediatamente eventos de plataforma para asegurarse de evitar este escenario.

Los flujos asíncronos proporcionan alternativas de código bajo a Apex asíncrono. Al igual que con otras formas de procesamiento asíncrono, se ejecutan en segundo plano cuando los recursos están disponibles. Los flujos asíncronos tampoco tienen SLA y pueden tener tiempos de espera impredecibles.

Las Rutas programadas se basan en desencadenadores de cronología para ejecutarse a una hora específica. Se ejecutan cuando se crean, actualizan o eliminan registros y le proporcionan control granular sobre cuándo ejecutar la automatización relativa al cambio de registro. (Ejemplo: envíe un email a un usuario una hora antes del vencimiento de una tarea.) A diferencia de los métodos futuros Apex, que están limitados a un máximo de 50 métodos en cola en una transacción síncrona, las acciones de flujo programadas no tienen actualmente un límite máximo de colas por transacción. Sin embargo, existe una configuración de tamaño de lote dentro de la definición de la ruta programada que permite cierto control sobre cuántos registros se gestionan por la ejecución del flujo de ruta programada.

Se pueden agregar rutas asíncronas a flujos desencadenados por registros. Se ejecutan en segundo plano y no retrasan la ejecución de la transacción que desencadenó originalmente el flujo. Puede utilizar una ruta asíncrona para ejecutar una operación de larga ejecución o cualquier operación que desee ejecutar en su propio momento. Las rutas asíncronas pueden ayudar a evitar errores DML mixtos que se producen cuando necesita actualizar un valor en un registro relacionado que no forma parte del registro que desencadenó el flujo.

Nota: La mensajería saliente es una función heredada y los eventos de plataforma (descritos en la sección anterior) son un enfoque más moderno y ofrecen mayor flexibilidad. Eventos de plataforma son el patrón recomendado por Salesforce para la integración dirigida por eventos.

Los mensajes salientes proporcionan un medio de comunicación saliente asíncrona a través de la API de SOAP. Cuando se configura en Salesforce, la definición del mensaje saliente produce un WSDL de SOAP que puede consumir un proveedor de servicios web externo. Los mensajes salientes pueden desencadenarse desde reglas de flujo de trabajo, procesos de Process Builder o desencadenadores de flujo después del guardado Lightning. Un mensaje de SOAP saliente puede contener hasta 100 notificaciones. Cada notificación contiene el Id. de objeto y una referencia a los datos de sObject asociados. Si la información en el objeto subyacente cambia después de poner la notificación en cola pero antes de enviarse, solo se entregan los datos más recientes y no los cambios intermedios.

Cuando un oyente de mensajes salientes (el servicio web que configuró con el WSDL generado) recibe un mensaje, utiliza la información de Id. de sesión incluida para llamar a la API de Lightning Platform para actualizar el registro en Salesforce que desencadenó el mensaje saliente.

• Los mensajes salientes no se gestionan a través de la infraestructura asíncrona basada en colas en Salesforce que ejecuta actividades como métodos futuros, Apex colocable en cola, Apex por lotes, API masiva, etc. En su lugar, los registros se almacenan localmente en el objeto OutboundMessage. Los mensajes se despachan y se reintentan a través de un proceso en segundo plano programado local.
• Los mensajes no se envían de forma síncrona cuando la acción de mensaje saliente se ejecuta por la automatización que inicia (por ejemplo, un desencadenador de flujo después de guardar). En su lugar, permanecen en el objeto OutboundMessage hasta que se envían correctamente o hasta que se descartan después de 24 horas de entrega incorrecta.
• Para evitar un bucle infinito de mensajes salientes, asegúrese de que el usuario que actualiza los objetos no tiene el permiso Enviar mensajes salientes.

Email para registro de casos normalmente funciona de forma síncrona. Existe un límite de cuatro hilos síncronos para gestionar solicitudes de Email para registro de casos entrantes. La forma síncrona del controlador mantiene una conexión con el servidor de correo entrante de Salesforce (MTA) que recibe el email. Sin embargo, existen razones por las que Email para registro de casos se puede gestionar de forma asíncrona:

• Email para registro de casos está sujeto a límites de hilos, específicamente 10 hilos de controlador en total por servidor de aplicación: cuatro hilos para procesamiento síncrono y seis hilos para procesamiento asíncrono.
• Si un controlador de email síncrono supera los 15 segundos de tiempo de ejecución, esa dirección de servicio de email concreta se marca como asíncrona durante un periodo de 30 minutos. Las solicitudes de gestor posteriores para esa dirección de servicio dan como resultado un mensaje que se pone en cola para MessageTypeName = MAILCATCHER_EMAIL_TO_CASE, junto con una referencia al contenido del email.
• Si un hilo síncrono ya está en uso para una organización y dirección de servicio concretas, las solicitudes adicionales para esa dirección de servicio se ponen en cola de forma asíncrona.
• Si un email gestionado de forma síncrona encuentra un error, como un tiempo de espera de bloqueo de filas, la solicitud se guarda y se pone en cola de forma asíncrona.
• Si no hay hilos de controlador síncronos disponibles, la solicitud se pone en cola de forma asíncrona.

• Existe una opción de deduplicación cuando configura Email para registro de casos, pero no deduplica archivos adjuntos hasta después de procesar el email. Esta deduplicación ahorra espacio en la base de datos, pero no reduce los tiempos de procesamiento de email. Sin embargo, puede mejorar el desempeño implementando un controlador de Email para registro de casos Apex personalizado para el procesamiento de mensajes. Esta implementación no afecta a ningún límite regulador, pero proporciona al controlador acceso al mensaje de email y todos sus archivos adjuntos antes de que se confirme nada en la base de datos. Este acceso le permite calcular sumas de comprobación para todos los archivos adjuntos incluidos y descartar cualquiera que decida que es innecesario, incluyendo duplicados, imágenes de firma conocidas o tipos de archivo no deseados.
• La confirmación de archivos adjuntos de email en Salesforce Files es responsable de la mayoría del tiempo de procesamiento de email. A medida que las respuestas a o desde el contacto aumentan y la cadena de email se hace más grande, el tiempo de procesamiento para cada email también aumenta. Si la opción de email “Responder solo con nuevo contenido” no está seleccionada, las cadenas de email crecerán con cada respuesta. Por lo tanto, recomendamos que utilice un controlador de Email para registro de casos Apex con lógica que implemente la deduplicación de archivos adjuntos en el momento del procesamiento.
• A pesar de la invocación de desencadenadores Apex como parte de la gestión, los gestores de Email para registro de casos están exentos del límite de Apex simultáneo.

Para procesar grandes volúmenes de registros de forma asíncrona, considere utilizar uno de estos enfoques.

Puede utilizar Apex por lotes para crear procesos complejos de larga ejecución que implican miles de registros. Apex por lotes funciona dividiendo su conjunto de registros y procesándolo en partes gestionables. Por ejemplo, puede crear una solución de archivado que se ejecuta de forma nocturna y agrega registros con una antigüedad superior a una fecha determinada a un archivo. O bien puede crear una operación de limpieza de datos que examine todas las cuentas y oportunidades de forma nocturna y realice cualquier actualización necesaria basándose en un conjunto de criterios predefinidos.

• Apex por lotes es mejor para procesar grandes cantidades de datos porque Apex asíncrono tiene límites más altos que Apex síncrono. Apex por lotes también tiene un desempeño más eficiente cuando procesa más elementos por lote porque utiliza operaciones masivas que generan menos gastos generales desde la gestión de colas. Por lo tanto, para evitar desencadenar el mecanismo de control de flujo a través de inundación de colas y evitar agotar el límite de Apex asíncrono diario, no cree lotes con tamaños de ámbito pequeños o que tengan tiempos de procesamiento rápidos.
• Evite poner en cola trabajos por lotes directamente desde acciones generadas por grandes volúmenes de actividad de usuario final o llamadas de API de integración. Este enfoque puede agotar rápidamente la cola flexible. Si tiene intención de invocar un trabajo por lotes desde un desencadenador, debe garantizar que el desencadenador no agregue más trabajos por lotes que el límite.
• Apex por lotes está limitado a un máximo de cinco hilos simultáneos, lo que limita su rendimiento mucho más que métodos futuros o Apex colocable en cola.
• Los trabajos por lotes que implican grandes volúmenes de datos deben programarse idealmente para ejecutarse durante las horas de menor producción con el fin de liberar recursos para procesos que requieren respuestas en tiempo real o casi en tiempo real.
• Cuando llama a System.scheduleBatch, la plataforma programa su trabajo para su ejecución a la hora que especifique. La ejecución real se produce en o después de esa hora, dependiendo de la disponibilidad del servicio.
• El programador se ejecuta en contexto del sistema. Todas las clases se ejecutan, independientemente de si el usuario que programó la ejecución tiene permiso o no para ejecutar la clase.
• Todos los límites Apex programados se aplican a trabajos por lotes programados utilizando System.scheduleBatch. Después de poner el trabajo por lotes en cola (con un estado de En espera o En cola), se aplican todos los límites de trabajos por lotes y el trabajo ya no cuenta en los límites Apex programados.
• Para un trabajo por lotes con una programación recurrente, considere el comportamiento correcto si el trabajo anterior aún se está ejecutando cuando el nuevo trabajo comienza a ejecutarse.
• Los trabajos por lotes en cola de transacciones Apex síncronas utilizan la cola flexible. La cola flexible está limitada a un máximo de 100 elementos en cualquier punto. Si una transacción intenta agregar más entradas, la plataforma genera errores y no envía el trabajo por lotes.
• Las llamadas y otras operaciones no transaccionales desde trabajos por lotes deben seguir consideraciones de diseño idempotentes. Los trabajos por lotes en cola antes de un tiempo de inactividad de mantenimiento de servicio de Salesforce permanecen en la cola. Cuando finaliza el tiempo de inactividad del servicio y los recursos del sistema están disponibles, se ejecutan los trabajos por lotes en cola. Si se está ejecutando un trabajo por lotes cuando se produce el tiempo de inactividad, la ejecución por lotes se revierte y se reinicia después de restaurar el servicio. Debido a que los métodos de ejecución pueden ejecutarse varias veces, cualquier operación no transaccional, como llamadas, puede reintentarse.
• Considere configurar el trabajo por lotes para elevar eventos BatchApexErrorEvent para gestionar escenarios de error y excepción.

Un flujo desencadenado por programación es un flujo programado para ejecutarse a una hora especificada y con una frecuencia repetida (diariamente, semanalmente o una vez) para realizar acciones en un lote de registros. (Ejemplo: actualice un campo en todos los casos con un estado de "Abierto" a las 2 a.m. cada noche.) Los flujos programados se ejecutan a través del mecanismo de desencadenador de cronología y se procesan de forma masiva.

• Un flujo desencadenado por programación ejecuta 200 registros por invocación, pero se ejecutará con múltiples hilos simultáneos si hay más de 200 registros presentes.
• Los flujos desencadenados por programación se ejecutan en un contexto síncrono con límites síncronos.
• Actualmente no hay forma de controlar el número de registros procesados por invocación de flujo programada. Si la ejecución es para más de 200 registros, existe un peligro real de errores Apex simultáneos.

La API masiva se basa en principios de REST y está optimizada para trabajar con grandes conjuntos de datos. Puede utilizarlo para insertar, actualizar, alterar, consultar o eliminar muchos registros de forma asíncrona y procesar los resultados más adelante. Salesforce Platform procesa la solicitud en segundo plano. Por el contrario, la API de SOAP y la API de REST utilizan solicitudes síncronas y están optimizadas para aplicaciones cliente en tiempo real que actualizan algunos registros a la vez. Puede utilizar ambas API para procesar varios registros, pero cuando los conjuntos de datos contienen cientos de miles de registros, son menos prácticos. El marco de trabajo asíncrono de la API masiva está diseñado para facilitar y hacer eficiente el procesamiento de datos desde algunos miles a millones de registros.

La forma más sencilla de utilizar la API masiva es activarla para el procesamiento de registros en el Cargador de datos utilizando archivos CSV. Con el Cargador de datos, no tiene que redactar su propia aplicación cliente. Sin embargo, a veces los requisitos exclusivos requieren redactar una aplicación personalizada.

Existen dos API masivas disponibles en Salesforce Platform.

• API masiva 2.0 es la API más reciente. Proporciona un flujo de trabajo simplificado y fácil de utilizar, y es el centro de atención para mejoras.
• La API masiva original aún es completamente compatible, pero ya no se está mejorando. Recomendamos que utilice la API masiva 2.0 donde sea posible.

Para obtener más información sobre los límites de API, consulte Límites de API masiva y Límites de API masiva 2.0.

Consulte esta guía cuando cree o considere el procesamiento asíncrono en Salesforce Platform. Siempre es una buena idea comprender el alcance completo de las opciones disponibles para usted y cómo pueden ajustarse a su caso de uso específico. Asegúrese de evaluar a fondo su panorama actual antes de realizar cambios en cualquiera de sus arquitecturas existentes, especialmente si su solución actual está funcionando bien.