Empezando Apex Asíncrono por las colas

1. Introducción

En esta entrada me centraré, en cómo diseñar la ejecución de Procesos Asíncronos Apex (en adelante Apex Async), aprovechando las capacidades de la plataforma.

Pero lo haré de manera invertida a como se hace habitualmente, donde se explica como programar los mecanismos de programación. Pero en IMMO, si los desarrolladores, arquitectos y administradores, entendemos bien como gestiona Salesforce los procesos asíncronos, sus colas de Espera y Ejecución, sus límites asociados, etc., la elección del mecanismo de programación, es muy sencilla u obvia.

En el contexto asíncrono, un diseño centrado en la programación y no en las capacidades de la plataforma, puede suponer limitar el rendimiento y las prestaciones de nuestro proyecto.

Y  es que si lo hubieras sabido, te hubieras cortado el pelo antes, y  no hubieras ido con tu compañero.

  1. Introducción
  2. Back to Basics: ¿Qué és un proceso Apex asíncrono?
  3. Estados de un Job Apex asíncrono
  4. Apex Flex Queue(s) y la Apex Jobs Queue
    4.1. Apex Flex Queue
    4.1.1. Orden de inserción en la Flex Queue y reordenación de prioridades
    4.2. Test-Context Queue (la otra Flex Queue)
    4.3. Apex Jobs Queue
  5. Límites de las colas
  6. Monitorización de las colas
    6.1. Mediante Interfaz de usuario
    6.2. Mediante el objeto AsyncApexJob
    6.3. Mediante CronTrigger y CronJobDetail para los Jobs Scheduled
  7. Retos reales no cubiertos por la plataforma

2. Back to Basics: ¿Qué és un proceso Apex asíncrono?

Un Job de Apex con naturaleza asíncrona (en adelante Apex Async ó Job Async), se ejecuta cuando la plataforma tiene recursos disponibles (lo que sucede muy a menudo) sin ninguna horquilla de finalización ni ANS o ETC (Service Level Agreement – Estimated Time to Complete), y siempre sin perjudicar al ámbito síncrono, donde trabaja el usuario final, que se ejecuta con prioridad.

En contrapartida, los límites para un Job Async son límites superiores que para un proceso síncrono. Así un Job asíncrono posee:

Los Limites para Jobs Asíncronos son superiores en prestaciones clave

Recalco, no existe ETC por parte de Salesforce, y por tanto, nuestro diseño no puede suponer ninguno de los aspectos siguientes:

  1. Cuando se iniciará el proceso
  2. Cuanto durará el proceso
  3. Cuando estarán disponibles los resultados de la ejecución

Ejecución de Apex Asíncrono basado en colas

Existen diferentes tipos de Jobs Apex Async, seguro que has visto algún método con la anotación @Future, pero siendo muy útil y práctico, ese es el hermano menor de todos.

Existen 3 mecanismos adicionales, implementados mediante Interfaces (no asustarse es muy simple):

  1. @Queueable
  2. @Schedulable
  3. @Batchable

Pero como viste en la imagen anterior, se gestionan mediante colas. Por tanto, aquí empieza el Rock&Roll, veamos los estados de un proceso y como la plataforma gestiona los Jobs asíncronos.

Salesforce Queues para Apex Async

3. Estados de un Job Apex asíncrono

Los estados de un proceso (Job) Apex Async, transcurre por los siguientes estados:

Estado que reporta la plataforma Descripción y Cola en la que reside el Proceso Es un estado finalista?
Holding El proceso Batch se ha enviado correctamente, pero queda pendiente de ser ejecutado, cuando hay recursos disponibles, que permitan su ejecución. El proceso reside en la cola Flex No
Queued La ejecución es inminente. El proceso se transfiere de la cola Flex a la cola Jobs, y se mantendrá en esta cola hasta la finalización No
Preparing El método start es ejecutado, ha empezado el Rock&Roll No
Processing Se ejecuta la lógica completa del proceso No
Aborted Es un estado finalista, al que se llega si se decide abortar la ejecución de manera voluntaria Si
Completed El proceso ha finalizado, pueden existir errores o finalización totalmente correcta Si
Failed Estado que indica que algo salió mal a nivel de plataforma, y el proceso no fue finalizado correctamente  Si

Veamos como se relaciona la ejecución de un Job con las colas de la plataforma.

4. Apex Flex Queue(s) y la Apex Jobs Queue

La plataforma Salesforce, ofrece 3 colas, para la gestión de los procesos asíncronos:

  1. Apex Flex Queue (Flex por Flexible)
  2. Su homóloga para testing la Test-Context Queue
  3. Apex Jobs Queue

Nota: cuando Salesforce liberó la funcionalidad de la cola Apex Jobs en 2015, se hablaba de la Batch Queue, actualmente este término está deprecado.

4.1. Apex Flex Queue

Al crear un Job de Apex Async Batch, su ejecución no se inicia hasta confirmar que hay recursos disponibles para su ejecución. Por tanto, el proceso es:

  1. Crear el Job, serializarlo para ubicarlo en las colas de sistema
  2. Si se pudo crear el Job (límites, etc.) el sistema retorna un ID identificando el Job (este ID permite inspeccionar las características del Job)
  3. Si el Job es Batch, se coloca en la cola Flex Queue, en estado Holding – esto implica que no se está ejecutando – ninguna de sus métodos ha sido invocado excepto el constructor de la clase (esto es importante)
  4. Si el Job no es Batch, queda encolado en la cola de proceso Job Apex para su procesamiento cuando haya recursos

  5. En cuanto la plataforma tenga recursos disponibles, ejecutará el Job y lo moverá de la cola Flex a la cola Apex Jobs.

En esta cola, el proceso tiene todos los atributos (15) de ejecución: Job Type, Summitted By, Apex Class, Apex Method, etc.

Campos Descriptivos Job Flex Queue

4.1.1. Orden de inserción en la Flex Queue y reordenación de prioridades

El orden de inserción en la cola es fundamental, ya que indicará como el sistema iniciará la ejecución de los Jobs. Por tanto, el orden de inserción marcará el lanzamiento de la ejecución del Job.

Un error común, es considerar que los procesos Batch se ejecutarán uno detrás de otro, y puede no ser así, dado que la plataforma puede ejecutar hasta 5 procesos concurrentes simultáneamente. Por tanto el diseñador debe tener en consideración que:

  1. Los Jobs se iniciarán en orden de inserción en la cola Flex (salvo errores en su creación)
  2. Los Jobs pueden ejecutarse simultáneamente y se desconoce el orden de finalización, dado que son procesos asíncronos usando recursos disponibles. Suponer que la dependencia funcional, que 2 Jobs deben ser ejecutados en modo serie, será satisfecha por haber insertado uno detrás de otro, es un error de diseño.

Mientras el Job Batch está en la cola Flex, tanto el administrador como el programador tienen la posibilidad de reubicar los procesos.

El Administrador dispone de una interfaz de Monitorización de la cola:

Detalle de la Flex Queue y Opciones disponibles en la interfaz de usuario.

Por su parte, el programador tiene acceso a los 4 métodos de la clase FlexQueue:

  1. moveAfterJob(jobToMoveId, jobInQueueId)
  2. moveBeforeJob(jobToMoveId, jobInQueueId)
  3. moveJobToEnd(jobId)
  4. moveJobToFront(jobId)

4.2. Test-Context Queue (la otra Flex Queue)

La plataforma proporciona una cola adicional, para que los programadores puedan realiza Test del encolamiento en la Flex Queue. Estos métodos pertenecientes a la clase Test son:

  1. enqueueBatchJobs(numberOfJobs)que permite enviar a la cola el número indicado de jobs
  2. getFlexQueueOrder()que devuelve la lista de los identificadores de los Jobs presentes en la cola

Un ejemplo:

Ejemplo de uso de la Test Flex Queue

4.3. Apex Jobs Queue

Alberga todos los Jobs del sistema, tanto en estados intermedios como no finalistas (ver apartado anterior), y tanto Jobs internos de Salesforce como los creados por el programador. Estos son:

Jobs creados por un programador para procesamiento Apex asíncrono:

  1. Future
  2. Queueable
  3. ScheduledApex
  4. BatchApex

Jobs creados por Salesforce para la gestión interna del sistema:

  1. SharingRecalculation
  2. BatchApexWorker
  3. TestRequest
  4. TestWorker
  5. ApexToken

Aunque no documentado por Salesforce (como comenta Pedro Espada en la Success Comunity) los procesos Future se ejecutan prioritariamente, por delante de Queueable y Batchable. Quizás la razón, es porque este tipo de procesos están pensados inicialmente para fragmentos asíncronos sin una gran carga, llamadas a Web Services, etc.

5. Límites de las colas

Es imprescindible conocer los límites sobre las colas y Jobs, de los que considero más importantes son:

Límites Apex Async
  1. Pueden existir hasta 100 Jobs Batch en estado Holding. Por tanto la profundidad máxima de la cola Flex, es 100 Jobs.
  2. Solo pueden existir 5 Jobs Activos: *Queued, Preparing, Processing
Error al superar el límite de 100 Procesos
  1. Hasta 50 Jobs pueden enviarse a la cola Apex Job con la sentencia System.enqueueJob
Si tratamos de insertar +50 Jobs mediante System.Enqueue en la cola de ejecución Apex Job, obtendremos una excepción
  1. Análogamente para procesos Future también tenemos la limitación de 50 Jobs como máximo

Cualquier inserción en las colas que pretenda superar estos límites, recibe una excepción del sistema, y se rechaza.

6. Monitorización de las colas

6.1. Mediante Interfaz de usuario

La interfaz de Salesforce proporciona acceso a los procesos cronificados,  la Flex Queue y a la Apex Jobs.

Acceso a los interfaces de Monitorización de las colas

En el caso de la cola Flex además permite la reordenación de los Jobs y acceder a sus características. La reordenación se realiza indicando en qué posición se desea colocar el Job.

6.2. Mediante el objeto AsyncApexJob

Además de la interfaz, la plataforma proporciona un objeto, AsyncApexJob, donde cada registro describe un Job, con todos sus atributos. Este registro se actualiza a medida que el Job va transcurriendo por su ciclo de vida.

Este objeto es accesible vía SOQL, lo que nos permite obtener información sobre cuantos Jobs tenemos, cuantos son de cada tipo, cuantos están en un determinado estado, duración de los finalizados, ver las características de un Job concreto, etc.

Los procesos que residen en la cola Flex, también están presentes en AsyncApexJob, ya que son Jobs asíncronos como el resto, aunque en un estado determinado.

Consulta del objeto ApexJobAsync para mostrar los Jobs en Proceso y Completados

6.3. Mediante CronTrigger y CronJobDetail para los Jobs Scheduled

Para los Jobs de tipo Scheduled, la plataforma además nos proporciona los objetos CronTrigger y CronJobDetail. Existe mucha documentación en Trailhead y la API donde encontrar ejemplos de uso

  1. CronTrigger contiene varios campos como PreviousFireTime, TimesTriggered, State, NextFireTime, etc., que contienen la información del Job respecto a sus ejecuciones
  2. CronJobDetail contiene 2 miembros: JobType y Name

7. Retos no cubiertos por la plataforma

Casos de uso que requieren adaptaciones de la plataforma

Reto 1: Tengo procesos dependientes funcional que deben ejecutarse en serie

Conociendo el ciclo de vida de un Job y las colas empleadas para su gestión, podemos encontrar una limitación muy rápidamente: ¿Cómo asegurar que un Job se ejecute y complete previamente a otro, dado que existe una dependencia funcional de negocio entre ellos?

Si consideramos al Job inicial como “Job padre” y el dependiente como “Job hijo”, podemos traducir el caso de uso a la inserción del Job Hijo en la Flex Queue no debe realizarse hasta haber concluido la ejecución del proceso Padre.

Para ello tenemos varias alternativas:

  1. Si tenemos Jobs de tipo Queueable podemos utilizar Job Chaining
  1. Si tenemos Jobs de tipo Batchable, en el finish() del padre, podemos lanzar el Job hijo
  1. Sincronizamos la ejecución de los Jobs vía Platform Events: cuando el Job Padre finaliza, lanza un evento para que el Job hijo sea insertado en la Job Queue.

Los 3 esquemas anteriores, sufren de un defecto, ¿qué sucede si el hijo tiene varias dependencias, por ejemplo padre y madre, ó un padre y pero no iniciarme antes de las 22.00?

  1. Construir un planificador dinámico, que veremos en la siguiente entrada.

Reto 2: Tengo Jobs Scheduled que deben ejecutarse a una hora concreta o periódicamente de forma garantizada

Este caso es más complejo, dado que su traducción es **Cuando llegue el momento de ejecución de ese proceso, no debe haber más de 4 procesos ejecutándose, para tener las máximas garantías (no la seguridad total) de que ese proceso podrá ejecutarse.

Para ello, debemos tener un control de los procesos que están activos en la cola Apex Jobs y de los procesos en la cola Flex.

Este caso de uso, requiere nuevamente de un planificador dinámico que controle de forma adecuada ambas colas.

Enlaces interesantes

  1. Asynchronous Processing in Force com – Lectura y comprensión obligatoria
  2. Asynchronous Processing Basics
  3. Monitor Asynchronous Apex
  4. Monitoring the Apex Flex Queue
  5. Monitoring the Apex Job Queue
  6. SOAP API Developer Guide for AsyncApexJob
  7. Differences between job types for ‘AsyncApexJob’ object
  8. Trailhead – Async Apex
  9. Trailhead – Control Processes with Queueable Apex

Introducción a la Arquitectura de Eventos en Salesforce

“Four years from now, ‘mere mortals’ Will begin to adopt an event-driven architecture (EDA) for the sort of complex event processing that has been attempted only by software gurus [until now]’
—Roy Schulte (Gartner), 2003

En esta primera entrada de una serie, intento situar, cuales son los mecanismos existentes en Salesforce, cuyo core es el uso de Eventos, e intento compararlos y ubicarlos en sus casos de uso.

Podría decirse que esta es una entrada 101 en Eventos de Salesforce.

En mi experiencia, no es trivial entender los “productos/mecanismos” que ofrece y ofrecerá Salesforce sobre eventos (Streaming API, Platform Events, etc.), y las tecnologías (Kafka, Bayeaux, Long Polling, etc.)  asociadas y los casos de uso a que dan respuesta.

Por ejemplo, el título de esta entrada es incorrecto, ya que debería ser algo así como: Introducción a los mecanismos de la Salesforce Enterprise Messaging Platform (pero con ese nombre …), espero pues, que el resto del artículo no sea como el título ;-).

Introducción a la Arquitectura de Eventos

No voy a extenderme mucho en las ventajas que puede suponer una arquitectura basada en eventos, frente a un patrón tradicional de integraciones.

Creo que la imagen de una “Arquitectura Spaguetti ” lo describe bien:

Arquitectura Spaghetti
Arquitectura Spaghetti tradicional en un entorno empresarial – Fuente: Gartner

En una Event Driven Architecture (EDA en adelante), idealmente la imagen se simplifica:

Event Bus Architecture – Fuente: Dzone

En muchos casos, cada vez más (especialmente cuando aparecen numerosos receptores de un mismo mensaje – IoT), este tipo de Arquitectura simplifica el diseño y da respuesta a casos de uso, a los que una arquitectura tradicional no daba una solución escalable.

Las ventajas de una EDA son:

  1. Publicación Real-Time de los eventos en el Producer (emisor)
    1. Una derivada de esto, implica que deja de producirse pooling por parte de los Consumers
  2. Desacople entre sistemas: el emisor y el receptor no se conocen
    1. Incluso la cadencia de emisión y consumo son distintos
    2. Se enfatiza si el BUS implementa Durabilidad de los mensajes (Retención de histórico recuperable)
  3. Simplificación del Patrón, usando Fire&Forget
  4. Arquitectura altamente escalable cuando el volumen de Consumers se dispara

Pero también tiene desventajas:

  1. Requiere de tecnologías no disponibles en todos los sistemas existentes
  2. Requiere de un mediador que permita la recepción y mediación de los eventos (y si se requieren funcionalidades avanzadas, es necesario un Event Bus cualificado)
  3. El número de comunicaciones entre los sistemas tiende a aumentar, especialmente si se implementa el patrón CallBack (el evento no contiene datos, solo los identificadores de los objetos de los que recuperar datos – por tanto para la recuperación se requieren invocaciones adicionales)
  4. El emisor no tiene garantía, ni pretende saber, que los destinatarios hayan tratado los eventos, ya que el patrón usado es Fire&Forget (no hay garantía de que todos los clientes consuman sus eventos)
  5. La gestión de errores se complica o no existe
  6. Los receptores mantienen la conexión abierta con el servidor, lo que se denomina Long Polling

El modelo de integración cambia entre ambos modelos de arquitectura, en la siguiente imagen se comparan:

Comparación Arquitecturas API y EDA
Comparación Arquitecturas Request-Response (enfoque tradicional) y EDA (basada en eventos) – Fuente: Hackernoon

Y el flujo de comunicación también, como por ejemplo mediante una conversación entre 2 sistemas con API y Streaming API:

Integración Tradicional via API
Integración Tradicional vía API
Integración vía Eventos, por ejemplo con la Streaming API

Veamos a continuación los diferentes productos que Salesforce ha ido proporcionando.

Productos de Salesforce basados en Eventos

Los productos que actualmente podemos usar los clientes de Salesforce son:

  1. Streaming API
  2. Streaming API con Generic Streaming (diós que nombre)
  3. Platform Events
  4. Change Data Capture (en Beta únicamente)

Y otros como  Event Monitoring, External Services Async, etc., que a corto/medio plazo incorporarán nuevas funcionalidades utilizando Eventos.

Los Productos de Salesforce orientados a Eventos han ido apareciendo paulatinamente

Como veremos estos productos han ido creciendo en el tiempo.

Descripción y casos de uso de cada unos de los productos

Producto DESCRIPCIÓN y casos de uso
Streaming API
  • Fue el primer producto orientado a Eventos para uso de clientes que ofreció Salesforce.
  • Completamente orientado a cambios en los datos para que la interfaz del usuario, reaccionara a esos cambios proporcionando así una experiencia muy rica.
  • Es decir, al mostrarse una página VF, se suscribe a ciertos mensajes que permitían actualizar los datos o avisar al usuario de cambios en los datos visualizados
Streaming API con Generic Streaming
  • Permite enviar una notificación para un evento en cualquier momento con un contenido de datos  personalizado  pero muy limitado (Payload al uso) sin necesidad de estar ligado a un cambio de datos.
  • El Payload está limitado un array de Strings y opcionalmente la lista de IDs de los receptores, lo que permite restringir a quien debe llegar el String de información
  • Orientado a casos de uso, para envío de una simple notificación ad-hoc, basada en String a un conjuntos de clientes, los cuales pueden ser conocidos (por eso la opción de lista de IDs en el envío de la notificación)
Platform Events
  • Basado en Streaming API (según comenta Jay Hurst – Responsable del equipo de Platform Events), aparece  este mecanismo mucho más versátil.
  • Permite enviar una notificación para un evento en cualquier momento con un contenido de datos completamente personalizado (Payload al uso) sin necesidad de estar ligado a un cambio de datos.
  • El Payload se define mediante campos, como si de un Custom Object se tratara, sin limitaciones y con las capacidades de gestión y utilización de campos de un objeto.
  • Su orientación está claramente enfocada a la integración de sistemas, donde aparecen escenarios de IOT, integración de sistemas heterogénos en Tiempo real, y con Pacing distintos (velocidad de emisión y consumo pueden ser completamente diferentes).
Change Data Capture
  • Basado en Platform Events, ofrecerá (en fase beta restringida y limitado en funcionalidad) un mecanismo que nativamente, ofrecerá el envío de un notificación para cualquier cambio, en cualquier objeto de Salesforce, tanto sea de datos, como de acciones del usuario, del sistema, etc.,
  • No es necesaria su emisión, simplificando así su consumo y proporcionando un mecanismo de consumo de eventos de la plataforma muy potente

En los siguientes apartados se analizan los productos actualmente disponibles (desafortunadamente en el momento de escribir esta entrada no tengo acceso a Change Data Capture).

Conceptos usados en cada uno de los productos

Cada producto usa conceptos que deben conocerse para su correcta comprensión y  utilización.

Producto DESCRIPCIÓN
Streaming API
  • Push Topic / Generic Topic: es la definición de cuando se generará un evento y que información contendrá la notificación
  • Notification: es el mensaje que se genera al producirse un evento
  • Channel: la notificación es enviada a un canal, para que los clientes la puedan consumir
  • Client: son los que se suscriben a N canales, para recibir las notificaciones
Streaming API con Generic Streaming
  • Streaming Channel:  lo que entendimos como el Channel, ahora se define mediante un objeto Standard
  • Streaming Channel Push: término utilizado para el envío de la notification
Platform Events
  • Platform Event: es la definición del contenido que tendrá el evento, sus campos de datos
  • Event message: es el mensaje, lo que en Streaming API es la Notification, por eso también se denomina Event Notification.
  • Channel: sin cambios, tiene el mismo significado
  • Event Producer y Event Consumer: aunque cambian los nombres siguen siendo el Emisor y el Cliente del Evento

Creación del Canal y Generación del Evento

Veamos pues, como se realizan la creación del canal y la generación del evento en cada uno de los productos:

Producto  DESCRIPCIón
Streaming API
  • La creación del canal consiste en la creación del Topic, que consiste en la definición de una SOQL. Esta query indica qué campos de un objeto deben verse alterados (Insert, Update, Delete, Undelete) para que se lance el evento.
  • La SOQL SELECT Id, Name, Phone FROM Account WHERE BillingCity=\'San Francisco\' provocará un evento cada vez que en Account se produzca una Creación, Actualización , Delete y/o Undelete (que afecte a estos campos) de un registro cuya BillingCity sea San Francisco.
  • No todas las queries son posibles, no se permiten cláusulas AVG, MAX, MIN, SUM, COUNT, LIMIT, etc., ni agrupaciones, ordenaciones, etc y xisten restricciones a cumplir (Id debe formar parte del Select, por ejemplo)
  • El canal para la suscripción de los clientes, se crea automáticamente en el recurso /topics/nombre_Topic
  • El Payload de la notificación enviada está formado exclusivamente por los campos que  se indican en la definición de la Query, y no es ampliable
  • La SOQL de definición puede usar cualquier objeto Custom y  los siguientes estándar: Account, Campaign, Case, Contact, Lead, Opportunity, Task, y bajo petición ContractLineItem, Entitlement, LiveChatTranscript, Quote, QuoteLineItem, ServiceContract
Streaming API con Generic Streaming
  • La creación del canal consiste en la creación de un registro en el objeto Streaming Channel, cuyo campo más importante es el Channel Name que debe tener el formato: /u/notifications/ExampleUserChannel
  • Es posible crear este Channel a través de APEX y APIs (REST y SOAP)
  • La generación de un evento se realiza mediante un POST al recurso /services/data/v/sobjects/StreamingChannel/ID/push donde el cuerpo del mensaje contiene un array de parejas un String con el mensaje a enviar y un array de identificadores de receptores si es que se desea restringir a quien quiere enviarse el mensaje
  • Esta versión de la Streaming API, soporta Dynamic Streaming Channel Creation, es decir, la creación automática del canal durante la primera invocación de la primera suscripción de un cliente
Platform Events
  •  El primer paso requiere la definición de un Platform Event, que es casi idéntico a un Custom Object (tiene como campos estándar: Fecha Creación, Creador y Replay ID) y podemos añadir campos de los tipos: Checkbox, Date, Date/Time, Number, Text y Text Area (Long)
  • La publicación de un Platform Event puede ser vía:
    • Visual Flow ó Process Builder de forma declarativa
    • Codificación en APEX mediante la clase Database
    • Invocación via API (SOAP/REST). En el caso de REST el es recurso /services/data/v41.0/sobjects/ Event_Name __e/ y proporcionado el Payload definido en la creación del Platform Event

Suscripción al canal

Análogamente para la suscripción:

Producto DESCRIPCIÓN
Streaming API (también Generic)
  • Subscripción: requiere de implementación de un cliente de Bayeaux, típicamente CometD en javascript, del cual hay muchos ejemplos en la documentación y en la comunidad (por supuesto disponible para otros lenguajes)
    • No es posible hacerlo de forma declarativa, ni por otro mecanismo de configuración
    • Además es posible la Bulk Subscription: en lugar de indicar un solo Channel y Topic, se realiza la petición de un array de Channels y Topics
  • De-suscripción: es una de las 5 funcionalidades básicas del protocolo Bayeaux: Connect, Disconnect, Handshake, Subscribe y Unsubscribe
  • Desactivar temporalmente Push Topic: es posible desactivar un Push Topic temporalmente, sin necesidad de eliminar y re-crearlo
Platform Events
  •  Podemos suscribirnos a la recepción de Eventos vía:
    • Usando Visual Flow ó Process Builder de forma declarativa
    • Mediante Triggers con la operación after insert. Adicionalmente es posible re-procesar un evento con la operacion EventBus.RetryableException
  • Y también podemos suscribirnos con un cliente CometD, donde el canal de suscripción es sobre /event/ Event_Name __e

Destacar que los suscriptores APEX, se ejecutan en el proceso denominado “Automated Process”, lo que por ejemplo obliga a la creación de un Log ad-hoc, para visualizarlos (existen otras implicaciones que deben comprobarse).

La de-suscripción es equivalente.

Aquí podemos ver un esquema resumen de Platform Events donde es posible observar todos los mecanismos comentados:

Esquema de uso de Platform Events – Fuente: Salesforce

Características únicas de cada Producto

Cada uno de estos productos, posee ciertas características que vale la pena conocer, no se ahonda en cada una de ellas, solo trato de enumerarlas.

Versionado de Schema en Platform Events

El Schema es un concepto que Salesforce introduce para identificar la versión de los metadatos del mensaje.

Así, en Platform Events, podemos modificar arbitrariamente el contenido del Objeto creado, que conformará el contenido de la estructura. Por tanto, si se modifica la definición del Platform Eevnt, y el sistema consumidor, no puede detectar que la estructura ha cambiado, puede suceder un problema de pérdida de datos del evento.

    • El Schema está versionado y cada mensaje contiene un identificador de la versión del esquema.
    • El esquema está accesible para ser consultado via API en los recursos siguientes:
      • /vXX.X/event/eventSchema/Schema_ID
      • /vXX.X/sobjects y /Platform_Event_Name__e/eventSchema

Topic Filtering en Streaming API

Filtrar la suscripción aporta la capacidad de recibir solo algunas de las notificaciones/mensajes sin modificar el canal establecido, filtrando la recepción durante la suscripción.

  • Tan solo requiere la modificación del String de suscripción: topic/ChannelName?<expression>, donde expression es fieldA=valueA&fieldB=valueB&…

Estará disponible para Platform Events supuestamente en Spring 18, según la información actual.

Ver la lista de suscriptores en Platform Events

Platform Events permite mostrar tanto vía la interfaz de usuario como obtener vía API, la lista de suscriptores Triggers o Processos (sólo vía API) asociados a cada evento definido.

Message Durability (Conservación del histórico de mensajes para su Recuperación)

Indica la capacidad de un cliente para recuperar notificaciones pasadas durante lo que se denomina la ventana de retención. Esto implica un total desacople entre emisores y receptores, y un pacing posiblemente desalineado.

Message Durability explicada por Salesforce - Fuente: Salesforce
Message Durability explicada por Salesforce – Fuente: Salesforce
Producto DESCRIPCIÓN
Streaming API (incluye Generic)
  • Soportado a partir de la v37, con una ventana de recepción de 24h
Platform Events
  • Soportado con una ventana de recepción de 24h como en Streaming API, pero sólo para los clientes CometD, no via Trigger

Consideraciones de Seguridad

Streaming API

  • FLS se aplica tanto a los campos del SELECT como del WHERE:
    • Si el cliente tiene un Profile, cuyo acceso a datos restringe a algunos de ls campos del WHERE de la definición del Topic, el cliente no recibe la notificación
    • Análogamente, si el Profile no permite acceso a alguno de los campos del SELECT, el cliente SI recibe la notificación, pero no recibirá ese campo informado
  • Puede restringirse el acceso sobre el Objeto utilizado en la Query
  • Puede restringirse el acceso sobre el propio PushTopic
  • Puede restringiste el acceso sobre el Push Streaming Channel

Platform Events

  • FLS no aplica: Todos los campos son read-only por defecto, y no es posible restringir el acceso a los campos individualmente. Dado que los campos de un evento no son visible en la interfaz de usuario, FLS no aplica.
  • La utilización de Platform Encription no aplica, con lo que debe tenerse en consideración.

Límites

A continuación se detallan los límites según la documentación en el momento de escribir la entrada:

Streaming API

De los siguientes límites, es importante notar las restricciones sobre:

  • Número máximo de Topics por Org
  • Número máximo de clientes sobre un Topic
Limits sobre la Streaming API
Límites sobre la Streaming API – Fuente: Salesforce

Platform Events

Para este producto hay que tener en cuenta el número máximo de Eventos definidos por Org.

Límites en Platfom Events – Fuente: Salesforce

Limitaciones adicionales existentes

Producto DESCRIPCIÓN
Streaming API
  • La SOQL de definición 1300 characters
Platform Events
  • No son transaccionales y por tanto no existe Rollback
Change Data Capture
  • Actualmente en beta, y solo se existe soporte para algunos objetos

Palabros que suenan alrededor de Eventos pero que despistan

Durante el aprendizaje de la arquitectura de Eventos, aparecen otros conceptos y palabrOs, que a menudo descolocan.

  1. Kafka: es una plataforma distribuida de eventos, originalmente construida por Linkedin y actualmente de Apache. Su capacidad de altos volúmenes y clustering, parece ser la idónea para que Salesforce la utilice dentro de sus sistemas internos para dar respuesta a clientes con Altos volúmenes. No es necesario conocer Kafka para entender y usar la arquitectura de Eventos Salesforce.
  2. Salesforce Connect: es un mecanismo basado en oData para el acceso a datos externos a Salesforce como si de objetos locales se tratara. Nada tiene que ver con la Arquitectura de Eventos de Salesforce.
  3. Heroku Connect: es un mecanismo de replicación contínua entre Salesforce y el servicio PaSS Heroku. Aunque ambas se puedan comunicar por Eventos (?), nada tiene que ver tampoco con la Arquitectura de Eventos de Salesforce.
  4. External Services: como hemos visto anteriormente, si que se pone como ejemplo, que la siguiente versión de este servicio, podría utilizar la tecnología de eventos, para proporcionar asincronía, pero como en los otros PalabrOs, no es necesario conocerlo para entender la Arquitectura de Salesforce.
  5. EMP Connector: es un ejemplo de cliente CometD que ofrece Salesforce para mostrar como realizar las operaciones sobre la plataforma y simplificar nuestro código utilizando sus funciones (enlace en la parte final del artículo)

Conclusiones

Como hemos visto la plataforma de Eventos de Salesforce ha ido creciendo y aportando nuevos productos, donde cada uno de ellos satisface ciertos casos de uso y necesidades.

Actualmente, Platform Events parece el más flexible, el más potente, y un paso adelante para Salesforce (aunque, aún no soporta grandes volúmenes de Eventos).

Pero hasta la publicación de Change Data Capture, debemos valorar y conocer las capacidades de la Streaming API en sus 2 modalidades.

Por otro lado, algunas entradas en blogs y comentarios, demonizan la arquitectura de interfaces tradicional, pero en mi opinión será la combinación de una Arquitectura SOA + Arquitectura de Eventos permitirá abordar proyectos más complejos que los actuales con garantías de éxito en entornos empresariales con heterogeneidad de sistemas.

Para saber más sobre Platform Events, recomiendo estos artículos:

Finalmente con la posible aparición de Change Data Capture, obtendremos funcionalidades muy potentes para dar respuesta a una gran cantidad de casos de uso actuales.

Enlaces interesantes

Para saber más acerca de estos productos, las guías de ambos servicios creo que son muy adecuadas así como los ejemplos que proporciona la documentación oficial y todo el material (vídeos, presentaciones, etc.) que se pueda encontrar de Jay Hurst (Product Manager de la Plataforma de Eventos en Salesforce)

BULK API v2: 2 veces más rápida con la mitad de código

Una de las novedades que quizás pasaron inadvertidas en la última release de Winter ’18, fue la nueva versión de la BULK API, denominada BULK API v2, disponible en v41.0.

Esta nueva versión, sigue siendo una API REST, que utiliza los verbos HTTP para crear Jobs, cerrar/abortar, eliminar y obtener información al respecto, aportando novedades para el programador y una mejora del rendimiento para el usuario final.

En esta entrada, se muestran las diferencias entre ambas versiones y se compara el rendimiento.

Comparación entre versiones

Las novedades de esta nueva versión están orientadas al uso de la API:

  1. Ya no es necesaria la gestión de Batches dentro de1 Job.
    1. Dicho así parece simple, pero aquellos que hemos programado en este esquema, veremos simplificado el código necesario en un % elevado
  2. Los límites para el uso de esta API, se simplifican:
    1. 100 millones de registros/día
    2. Contenido de mensaje que no superen los 150MB codificados en B64 al llegar a Salesforce (lo que significa a ojo de buen cubero, como máximo mensajes con payload de 100 MB en origen)
  3. La velocidad de ejecución:
    1. Como se observa en las mediciones realizadas llega a ser x2

De menor importancia, pero muy útil:

  • En la v2 se ofrece un nuevo servicio, accesible con el verbo GET, para consultar el estado de los Jobs, pudiendo solicitar todos aquellos Jobs que cumplen ciertas condiciones
  • Además la v2 soporta 6 tipos de separadores de campos distintos (backquote, caret, comma, pipe, semicolon, y tab) lo que evita tener que modificar nuestros ficheros origen (mayor flexibilidad lo que comporta menos código)

Comparación entre ambas APIs

Simplificación del proceso

En la V1 la creación de trabajos requería:

  1. Autenticación
  2. Creación del Job
  3. Gestión de los Batches
    1. Creación individual de cada Batches
    2. Empaquetar cada Batch en el límite
    3. Envío de los datos del Batch
    4. Gestión individual del estado de las cargas
    5. Confirmación/Retry en caso de incidencias
  4. Cierre del Batch (para inicio de ejecución)
  5. Pooling del estado del Job
  6. Gestión de los resultados (obteniendo la información de los registros ejecutados/correctos/error)

En la V2, este proceso se simplifica:

  1. Autenticación
  2. Creación del Job (simple o multipart)
  3. Gestión de los Batches
    1. Creación individual de cada Batche
    2. Empaquetar cada Batch en el límite
    3. Envío de los datos del Batch Job
    4. Gestión individual del estado de las cargas
    5. Confirmación/Retry en caso de incidencias
  4. Cierre del Batch Job (para iniciar ejecución)
  5. Pooling del estado del Job, mediante invocación del servicio de intención de información del Job
  6. Gestión de los resultados (obteniendo la información referente a los registros ejecutados/correctos/error)

Es decir:

  • Salesforce ahora libera al desarrollador de la segmentación y tratamiento de los Batches, y únicamente requiere la creación del Job, Upload de los datos (si no utilizamos Multipart), y chequeo de estado con obtención de resultados
  • La segmentación de los datos se realiza ahora de forma que cada segmento, contiene 10.000 registros, como podemos ver en la página estado del Job, lo que disminuye el número de Batches que gestiona Salesforce internamente.
  • Se sigue la regla del 10×10: si el proceso tardara más de 10′, Salesforce lo marcaría como a Reintentar, hasta un máximo de 10 veces (en esta circunstancia el Job se da por Failed).

Detalle de un Job con la BULK API v2

Por tanto, la parte más compleja queda eliminada del proceso, simplificándolo en gran medida.

Operaciones disponibles en v2 y como usarlas

Las operaciones y los verbos utilizados en la API, son intuitivos, pero se recomienda estar muy atento al uso de las cabeceras que se indican en la documentación oficial de Salesforce, para evitar errores inesperados.

El proyecto Java, construido para esta entrada, disponible como Repositorio público, puede ser una opción,  para observar como son los valores, tanto para las cabeceras, como los Payload y respuestas, y así evitar problemas inesperados.

Autenticación

Sin cambios, la autenticación se realiza obteniendo el token oAuth como se realiza en v1.

Creación de un Job Simple

Existen 2 posibilidades para crear un Job. La opción, que denominamos Simple, consta de varios pasos: Creación, Upload de datos,  y Cierre del Job (inicio del procesamiento en Salesforce) y opcionalmente obtener información y estado final de los registros gestionados.

Para la creación tan solo se requiere,  el envío de una petición POST al endpoint  /services/data/vXX.X/jobs/ingest/. En el cuerpo del mensaje se indica:

  • El objeto destino, por ejemplo Persona__c, Account, etc.
  • La operación bulk a realizar: insert, update, delete, etc.
  • Los parámetros adicionales que caracterizan la lectura de los datos, o la naturaleza del Job (paralelismo, concurrencia, etc.).

Es imprescindible leer la documentación (al final del artículo todos los enlaces disponibles) para entender las posibilidades y restricciones que impone la API.

Ejemplo llamada Java Creación Job para la BULK API v2

Upload de Datos en un Job Simple creado

El Upload de datos, requiere de haber realizado la llamada anterior con éxito, dado que en la respuesta, se obtiene el endpoint de datos, donde deben enviarse los datos (100 MB como máximo aproximadamente – ver la sección de límites).

Obtenido el endpoint, solo se requiere un PUT a esa URL, pero debemos ser cuidadosos con la construcción de las cabeceras, y de los encodings (siguiendo el ejemplo del código disponible en el REPO, se obtiene como hacerlo correctamente).

Ejemplo llamada Java para el envío de datos al Job creado para la BULK API v2

Cerrar el Job

Con todos los datos enviados, se requiere de una llamada con el verbo PATCH, sobre el endpoint /services/data/vXX.X/jobs/ingest/jobID, indicando a Salesforce que todos los datos han sido enviados, y debe iniciar el procesamiento (construcción de los batches internos y toma de resultados).

Ejemplo llamada Java para el cierre del Job creado para la BULK API v2

Creación de un Job Multipart

Alternativamente a los pasos anteriores, es posible usar una única invocación para la creación, upload y cierre.

Para ello se requiere la construcción de un mensaje Multipart, siguiendo el formato indicado en la documentación, con el verbo POST hacía el endpoint /services/data/vXX.X/jobs/ingest/.

Ejemplo llamada Java Creación Job Multipart para la BULK API v2

Obtener estado del Job

Los estados del Job son: Open, UploadComplete. InProgress, JobComplete, Failed, Aborted. Existen ciertas restricciones,  como por ejemplo: para eliminar un Job, no puede estar en estado inProgress, o aparece el siguiente mensaje:

[{"errorCode":"API_ERROR","message":"Error encountered when deleting the job because the job is not terminated"}]

Consultar su estado requiere una invocación con el verbo GET al endpoint /services/data/vXX.X/jobs/ingest/jobID.

Ejemplo llamada Java para la consulta del estado de un Job para la BULK API v2

Información que se obtiene de un Job

La información que se obtiene de un Job, es completa, fácil de obtener y consumir. El objeto JSON retornado es:

{
"id": "7501r0000097DEBAA2",
"operation": "insert",
"object": "Contact",
"createdById": "005w000000484LsAAI",
"createdDate": "2017-12-17T09:29:10.000+0000",
"systemModstamp": "2017-12-17T09:29:10.000+0000",
"state": "Open",
"concurrencyMode": "Parallel",
"contentType": "CSV",
"apiVersion": 41.0,
"jobType": "V2Ingest",
"contentUrl": "services/data/v41.0/jobs/ingest/7501r0000097DEBAA2/batches",
"lineEnding": "LF",
"columnDelimiter": "COMMA",
"retries": 0,
"totalProcessingTime": 0,
"apiActiveProcessingTime": 0,
"apexProcessingTime": 0
}

Rendimiento comparado entre versiones

Hasta aquí todo son bondades para los programadores que trabajen con la API, pero poca repercusión tiene para los usuarios finales que la utilizan mediante herramientas de terceros, como ETLs, Data Loader, etc.

Para comparar tiempos, se ha construido un cliente Java sencillo con Web Service Connector, (enlace al repositorio) y se ha ejecutado una batida de pruebas tomando tiempos de ejecución de ambas versiones de la API (durante fin de semana previo a Navidad, cuando las instancias supuestamente estarán con baja ocupación).

Los resultados han sido:

OPERACIÓN y volumen Tiempo MEDIO empleado por la BULK API v1 Tiempo MEDIO empleado por la BULK API v2 Diferencial porcentual
INSERT 250K 131” 41” -220%
INSERT 500K 251” 138” -82%
INSERT 1M 442” 263” -68%
SOFT DELETE 500K 160” 148” -8%
UPDATE 250K 31” 22” -41%
UPDATE 500K 142” 123” -15%
UPSERT 500K 178” 110” -62%
  • Los tiempos se expresan en segundos
  • El volumen de registros se expresa en miles (k), es decir 250k indican 250.000 registros
  • Un diferencial negativo, implica una mejora del rendimiento
  • La operación Hard Delete no está actualmente disponible en la API V2
Resumen de Resultados porcentuales obtenidos

Conclusiones

Esta nueva versión v2, mejora la anterior tanto en uso, simplificándolo, como en rendimiento, mejorándolo, lo que supone que todos los usuarios, tanto técnicos como finales, se verán beneficiados.

Más sencillo y más rápido comporta más barato

Enlaces interesantes

Backup en Salesforce: Opciones disponibles y Alternativas

58% of downtime incidents are caused by human error alone (Boston Computing Network)

Every Minute 3,535 data Records are lost (breachlevelindex)

En este artículo, se enumeran los mecanismos nativos en Salesforce para la realización del Backup de datos, y su recuperación. También se analizan los puntos débiles de estas mecanismos ante los casos de uso más habituales de pérdida de datos.

Continue reading “Backup en Salesforce: Opciones disponibles y Alternativas”

Las Named Credentials simplifican el código Apex de Callouts mediante configuración estándar

La mayoría de los proyectos de Salesforce requieren Callouts para integrarse e invocar servicios en sistemas externos. Habitualmente estos Callouts, requieren de código Apex, el cual, puede volverse costoso, voluminoso y engorroso de mantener si desconocemos las Named Credentials.

Continue reading “Las Named Credentials simplifican el código Apex de Callouts mediante configuración estándar”

Replicar cambios en Salesforce hacia sistemas externos – Opciones y alternativas

No creo que sea casualidad que, en cada nueva versión, Salesforce introduzca mejoras sustanciales, a la permeabilización de sus datos y en especial, intentar hacerlo de forma eficiente, estándar y cada vez más simple.

Hasta hace relativamente pocos años, la integración entre Salesforce y sistemas externos, estaba limitada a unos escenarios concretos y a unas APIs reducidas.

Continue reading “Replicar cambios en Salesforce hacia sistemas externos – Opciones y alternativas”

Big Objects: Contenedores de Datos – un quiero y quizás puedo de almacenamiento masivo en Salesforce

En la entrada anterior, describía el caso de uso de cómo acceder a una gran volumen de datos desde nuestra ORG via External Objects, y dejaba la puerta abierta a la alternativa a la funcionalidad nativa de Big Objects en Salesforce.

Esta entrada describe qué son, en qué casos de uso pueden aplicarse, cómo crearlos, insertar datos (con Data Loader que parece ser un caso poco documentado) y describir sus características y restricciones, que no son pocas.

Continue reading “Big Objects: Contenedores de Datos – un quiero y quizás puedo de almacenamiento masivo en Salesforce”

Reporting sobre una Arquitectura Híbrida: Amazon-Salesforce usando Salesforce Connect

Una de las limitaciones que existian en referencia al uso de External Objects, era su limitada capacidad de Reporting.

En un artículo de Mark Kovacevich, Salesforce Connect Reporting, explicaba un workaround mediante programación en APEX:

  • Mostrando una List View con un Controller básico
  • VisualForce que con un Custom Controller muestra los registros y pinta un par de diagramas.

Continue reading “Reporting sobre una Arquitectura Híbrida: Amazon-Salesforce usando Salesforce Connect”

Salesforce Connect para acceder a datos en Amazon RDS via oData

Supongamos el siguiente caso de uso:

  • Queremos acceder a una gran cantidad de datos, que están fuera de nuestra ORG de Salesforce (presumiblemente en una base de datos en nuestro CPD)
  • Queremos acceder a estos datos, sin interfaces ni APIs
  • Queremos realizar reporting y análisis, cruzando esta base de datos con nuestros objetos declarados en nuestra ORG

Continue reading “Salesforce Connect para acceder a datos en Amazon RDS via oData”

Integración Continua en Salesforce (5): Conclusiones Finales

Partimos inicialmente con el deseo y con la convicción de que la Integración Contínua en Salesforce es completamente necesaria, y esa convicción, a pesar de los retos y condicionantes observados,  sigue intacta.

Lo que ha cambiado completamente, es la simplificación con la que se habla y se predica la adopción de este proceso en modo DIY (Do it Yourself).

Continue reading “Integración Continua en Salesforce (5): Conclusiones Finales”

Integración Continua en Salesforce (3): proceso y uso de la herramienta de despliegue

El proceso

Despliegue por diferencias

El proceso de despliegue en Salesforce, a diferencia de, por ejemplo, en el mundo Java, no se realiza desplegando un fichero .ear/.war que contiene todos los componentes y sustituye de forma completa al anterior , sinó que se realiza mediante el despliegue de los componentes añadidos/modificados y listando aquellos que queremos eliminar, lo que se suele llamar incremental, por diferencias (en adelante usaré este último término).

Continue reading “Integración Continua en Salesforce (3): proceso y uso de la herramienta de despliegue”

Una posible adopción de gitFlow en proyectos Salesforce

Vincent Driessen en su blog GitFlow- A successfull Branching Model, describe el casi proceso de facto que aplican muchos equipos de desarrollo para la gestión de ramas (aunque prefiero la explicación y gráficos de AtlassiangitFlow Workflow.)-.

En esta entrada, intento explicar por qué, al menos en mi caso, no es directa su aplicación en un proyecto de Salesforce y las consideraciones adicionales y conclusiones a las que he llegado.

Continue reading “Una posible adopción de gitFlow en proyectos Salesforce”

Skinny Tables para la mejora de rendimiento Salesforce

Supongamos que después de haber seguido las buenas prácticas de diseño, programación, aplicado índices donde era necesario, seguimos teniendo problemas de rendimiento de un Report/Dashboard o SOQL concreta.

Como almacena Salesforce la información internamente

Continue reading “Skinny Tables para la mejora de rendimiento Salesforce”

Mi lista de Limitaciones en Integraciones de Salesforce

Creo que todos lo hemos sufrido -> “Salesforce no soporta FTP nativo” -> Mala cara.

Integración de Salesforce

De mi background como arquitecto de Integración esa afirmación sorprende, pero cuando conoces las capacidades de Integración de Salesforce y otros aspectos como su Seguridad, Fiabilidad, Documentación, Comunidad, etc., se te pasa el susto.

Mantengo una lista de las limitaciones (no en el aspecto negativo) que comparto por si pueden ser de ayuda a alguien y ahorrar algo de tiempo. Por favor, si hay alguna incorrecta (lo siento de antemano) o me faltara alguna, pido por favor mencionarlo, para tener una lista mejor.

  1. Salesforce no tiene un BUS de Integración propio (aunque con Platform Events, Lightning Connect, Streaming API, etc., se da respuesta a muchos casos de uso)
  2. Salesforce no soporta transacciones ACID
  3. Salesforce no soporta WS-Security (https://en.wikipe
  4. dia.org/wiki/WS-Security)
  5. Salesforce no implementa WS-ReliableMessaging (https://en.wikipedia.org/wiki/WS-ReliableMessaging) – que utilizando Outboung Messaging queda mitigado por la lógica de los reintentos cada 10” durante 24h
  6. Salesforce no soporta WS-Addressing, lo que complica el enrutamiento dinámico, en un escenario de Orquestacion empresarial con BUS de Integración disponible
  7. Con Outbound Messaging, no podemos invocar servicios REST (pero hy abierta Idea 08730000000DhyEAAS)
  8. Con Outbound Messaging si al cabo de 10” no hay respuesta se reenvia la petición (hay que certificar Idempotencia en el diálogo)
  9. Con Outbound Messaging solo es posible enviar datos de un objeto, aunque puede recibirse del objeto y de sus objetos relacionados
  10. Las Workflow Rules no son aplicables el borrado de un registro, por lo tanto, no podemos invocar a un servicio externo directamente (existe Workaround mediante trigger)
  11.  Entornos con grandes volúmenes de datos, típicos de un Patrón de Batch, que requieran el uso de BULK API tanto en modo Serial como Parallel, con o sin Chunking, son difíciles de abordar sin herramientas ETL de terceros (que habitualmente tienen un CTO elevado). Nosotros utilizamos Informatica Cloud, aunque ODI y estoy seguro que otras facilitan el uso de BULK API.
  12. Los certificados para comunicación segura con Salesforce deben renovarse anualmente (un poco tedioso para los compañeros de sistemas)
  13. No hay una versión oficial de Data Loader para Linux (es una herramienta de escritorio para Windows y Mac, pero la posibilidad de usarlo como carga masiva usando la BULK API en servidores empresariales Linux es siempre muy tentador y podría…)
  14. Salesforce no proporciona una herramienta de escritorio de ETL simple para que el equipo de negocio pueda cargar datos transformándolos mínimamente (Mass Loader/Update y herramientas como Jitterbit y Dataloader.io, pueden suplir en parte esta carencia)
  15. El Force.com Excel Connector dejó de soportarse hace mucho tiempo, y muchos usuarios preguntan por funcionalidad similar

No menciono los Governor Limits, pq creo que son protecciones necesarias en un entorno Multi-tenant, y en muchos casos, romperlos implica que la solución adoptada no es la adecuada.

Seguramente tenemos otras de muy bajo nivel técnico, pero mi intención es solo compartir mi lista y si es posible mejorarla.

*Si perteneces a Salesforce y lees este artículo, no fruncir el ceño por favor, no hay mejor elogio para un fabricante, que sus clientes utilicen sus herramietnas y la conozcan bien.

Crédito de la imagen para: elearningindustry.com

Data Loader en CLI en Linux/Unix/Mac OS

Data Loader es una herramienta creada en Java, con su código disponible en gitHub, lo que nos permite descargar su código, y montar sus artefactos mediante maven.

 

Todos conocemos la interfaz gráfica, pero como se explica en la documentación del mismo Repositorio de gitHub, también ofrece una clase (com.salesforce.dataloader.process.ProcessRunner) para la invocación por línea de comandos  (CLI – Command Line Interface) en cualquier sistema operativo que disponga de una máquina virtual Java instalada.

Esto permite, por ejemplo, planificar (mediante CRON) cargas/descargas desde servidores empresariales Linux/Unix, y haciendo uso de Bulk API (hay otros muchos casos de uso ).

Utilizar Data Loader via CLI es muy senzillo y se describe en la documentación de Salesforce. Resumiendo son 3 pasos:

  1. Generar nuestro password encritpado en 2 pasos
  2. Crear el mapeo de los campos entre el fichero que cargaremos y el objeto destino
  3. Crear el fichero process-conf.xml q contiene el detalle del proceso a ejecutar (Operación, uso de BULK API, etc.)

Pero si además, estos 3 pasos nos parecen complejos/tediosos existe una herramienta llamada CLIq, que nos automatiza esta generació. Esta herramienta también está disponible en gitHub.

En la imagen adjunto, se observa la ejecución que realizo en el Linux más raro que he tenido nunca, Bash de Ubuntu en Windows, gracias al Windows Linux Subsystem, lo que demuestra que mientras haya disponible una máquina virtual de Java instalada, podemos ejecutar Data Loader y conseguir una nueva herramienta en nuestro arsenal de Integración.

Ejecución de Data Loader en Bash Ubuntu Windows Linux Subsystem
Ejecución de Data Loader en Bash Ubuntu Windows Linux Subsystem

Documentación para profundizar: