Presentación al Barcelona Salesforce Developer Group de las capacidades de creación y gestión de procesos asíncronos en Salesforce.

1. Salesforce Async
Esteve Graells
esteve.graells@gmail.com
forcegraells.com

2. ¿Por qué procesos asíncronos?
Bloqueo del Thread principal síncrono
Límites superiores y nuevas tipologías de procesamiento (Batc
Creación de procesos cronificados
(Schedulable)
Encadenamiento de
procesos
Ejecución en su propio thread, con inicio de ejecución garantizado de
recursos, ya que no se inician hasta confirmar que hay recursos
disponibles
Ejecución de cargas pesadas que excederían los límites habituales
Planificación de procesos mediante expresiones CRON
Planificación de procesos mediante expresiones CRON

3. Consideraciones importantes
El proceso se inicia de
inmediato o cuando está
planificado
Será más rápido, siempre
hay recursos disponibles
para su ejecución
No se garantiza el inicio, no se
garantizar ni en procesos
Cronificados.
El carácter Multi-Tenant de la
plataforma se ve acentuado en la
compartición de recursos (por
experiencia – Pick Hours).
Mi experiencia: generalmente si se inician de forma inmediata para
@Future/@Queueable/@Batchable y sin retardos en el inicio para
@Schedulable. Pero no podemos confiar que si en un Sandbox funciona,
también lo hará en PRO. Hay que probarlo en las horas “de más
concurrencia” -> Pick Hours.
Sólo se inician los procesos, cuando
hay recursos disponibles

4. Alternativa: heroku
Procesamiento garantizado
Intercambio de datos en Near Real
Time
Código en el lenguaje adecuado, no
APEX
Release Management
independiente

5. Future
Queueable
Schedulabl
.
Batch
Accesibles
via API/UI
Tipología de procesos
Batch Apex
Worker
Test Request
Test Worker
Sharing
Recalculat.
Apex Token
Internos
Plataforma
...

6. Estado Descripción y Cola en la que reside el Proceso
Es
estado
finalista?
Holding
El proceso Batch se ha creado correctamente, y
proceso reside en la cola Flex.
No
Queued
El proceso reside en la cola Apex Jobs. Su ejecución
depende de la disponibilidad de recursos.
No
Preparin
g
(Batch) El método start es ejecutado. No
Processi
ng
(Todos) El método execute es ejecutado. Sólo para
Batch, al finalizar se ejecuta el método finish.
No
Aborted
Es un estado finalista, al que se llega si se decide
abortar la ejecución de manera voluntaria.
Si
Complet
ed
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
Estados de los procesos

7. Batch
Batch
Batch
Batch
Batch
Batch
Batch
@Future
@Queueable
@Schedulable
Batch
Apex Jobs
Colas asíncronas de procesamiento
:1
:2
:3
:4
:5
:100
Apex Flex
Queue
…
:100
Cola para
procesos Batch
en estado
Holding
Cola para
todos los
procesos
asíncronos en
cualquier
estado:
Holding
Queued
Preparing
Processing
Aborted
Completed
Failed

8. Visualización proprocionada por la plataforma
Apex Flex Queue
• Batch Jobs are processed “first-in, first-out” up to 100 jobs and can be reordered by code
or UI
• Cuando cambian de estado a “Queued” solo son visibles en la Apex Jobs
Apex Jobs
• Apex Jobs page shows all asynchronous Apex jobs submitted for execution in all
possible Statuses: Holding, Queued, Preparing, Processing, Aborted, Completed, Failed
• Consultable via objeto estándar AsynApexJob
Background Jobs
• Background jobs in your Org, such as parallel sharing recalculation is running
• Process examples: IoT Explorer Runtime Log Cleanup, Chatter Unified Digest, Picklist
Delete, etc.
Bulk Data Load Jobs
• Show status of bulk data load jobs in progress or completed
• The job detail page includes a related list of all the batches for the job and the related
list provides View Request and View Response links for each batch
Scheduled Jobs
• Cronified Apex classes or to run a batch Apex job using the Salesforce UI up to 100
• Actual execution may be delayed based on service availability

9. ¿Cuáles son los mecanismos asíncronos?
@Future
• Permite transformar un método a asíncrono mediante una anotación
• El caso de uso por excelencia es la invocación de Web Service
@Queueable
• Mediante la implementación de una interfaz
• Se le otorgan Limites superiores a Future
• Empezando desde 0, siempre es preferible Queueable a Future
• Famoso por el “Chaining”
@Batchable
• Mediante la implementación de una interfaz
• Tiene los límites máximos disponibles
• Su “Chaining” no es famoso, pero igual de factible
@Schedulable
• Mediante la implementación de una interfaz
• Permite la cronificación de procesos (cuidado, no garantizado)
+ Info detallada en los Anexos pero muy aburrida

10. Stop xerrameca, let’s code
https://bitbucket.org/estevegraells/meetup-salesforce-asincrono

11. Roleplay
1. Se requiere que un método de una clase se transforme en
asíncrono y que reciba como argumentos sObjects
2. Se requiere que un método de una clase se transforme en
asíncrono y devuelva X o no sea estático
3. Se requiere un proceso a una hora concreta
4. Se requiere un proceso a una hora concreta recurrentemente
5. Se requiere concatenar procesos, ejecutar uno detrás de otro
6. Se requiere la ejecución de un proceso al cabo de 6 horas de su
finalización
7. Se requiere procesar 49.999.999 registros
8. Se requieren procesar 99.999.999 registros
9. Se requiere ejecutar un proceso solo cuando 2 procesos padres
hayan finalizado
1. Garantizar el inicio de un proceso cronificado en una ORG muy
cargada de procesos asícnronos
2. Ejecutar el proceso C no debe ejecutarse antes de las 3.00 y solo si
los procesos A y B han finalizado
3. La fecha de ejecución de un proceso la marcan ciertas condiciones
que se crean en sistemas externos

12. Escenario Real
Supongamos que tenemos una ORG con las siguientes características:
1.Cada 2 horas se requieren ejecutar 2 procesos de reconciliación de datos de cliente
2.Durante el horario nocturno se ejecutan diversos procesos pesados Batch que pueden ejecutarse
cuando se prefiera
3.También durante el horario nocturno, deben ejecutarse procesos, que tienen dependencias
funcionales entre sí y dependencias horarias:
• el proceso C no puede ejecutarse hasta que haya ejecutado el A y el B
• el proceso C no puede ejecutarse antes de las 5.00 de la madrugada
4.Finalmente, también durante el horario nocturno, tenemos procesos que deben ejecutarse solo
cuando lo haya notificado un evento de un sistema externo
5.De forma no programable el usuario final ejecuta un proceso que desencadena la ejecución de un
proceso asíncrono que se desea resolver lo antes posible

13. Planificador Dinámico
https://bitbucket.org/estevegraells/dynamic_planner/

14. ...y a partir de mañana?
 Entender bien el artículo: Asynchronous Processing
in Force.com
 Realizar el Módulo de Trailhead Asynchronous Apex
 Mirar la infame página de Governos Limits
 Conocer el Piloto para aumentar los límites en
@Future
 Clonar el repo del Planificador Dinámico, ampliarlo,
mejorarlo que sea un KungFu Panda Planificador

15. Gràcies per venir

16. Tipo Características
Future
• Must be static methods, and can only return a void type
• The specified parameters must be primitive data types, arrays of primitive data types, or
collections of primitive data types future methods can’t take objects as arguments
• Future methods won’t necessarily execute in the same order they are called
• It’s possible that 2 future methods could run concurrently, which could result in record locking if
the two methods were updating the same record
• You can’t call a future method from a future method
• You can’t invoke a trigger that calls a future method while running a future method
• You’re limited to 50 future calls per Apex invocation, and there’s an additional limit on a 24-hour
period (Consider using batch Apex instead). Existe piloto para duplicar límites
(https://developer.salesforce.com/docs/atlas.en-
us.212.0.apexcode.meta/apexcode/apex_enhanced_future_overview.htm)
Queueable
(La
traducción
de Trailhead,
Procesos
para Meter
en Cola lo
dice todo)
• Because queueable methods are functionally equivalent to future methods, most of the time you’ll
probably want to use queueable instead of future methods -> NO ESTOY DE ACUERDO: Queueable
es una interfaz para clases, mientras que @Future es una Annotation para métodos
• When you submit your job, the job ID is returned (AsyncApexJob record) -> Monitor its progress.
NOTA: como podemos hacer con Future igualmente (ver query ejemplo)
• La ventaja principal es que se trata como un Job, y tienes las faciliades de gestión de estos y el uso
de parámetros no tan restringdo:
• Can contain member variables of non-primitive data types, such as sObjects or custom Apex
types. Those objects can be accessed when the job executes
• Chaining jobs: You can chain by starting a second job from a running job:
System.enqueueJob(new SecondJob());
Anexo - Mecanismos

17. anexo - Mecanismos
Comentarios sobre Chaining
• NO limit is enforced on the depth of chained jobs, which means that you can chain one job to
another job and repeat this process with each new child job to link it to a new child job.
• For Developer Edition and Trial organizations, the maximum stack depth for chained jobs is 5,
which means that you can chain jobs four times and the maximum number of jobs in the
chain is 5, including the initial parent queueable job.
• When chaining jobs, you can add only one job from an executing job with System.enqueueJob,
which means that only one child job can exist for each parent queueable job. Starting multiple
child jobs from the same queueable job isn’t supported.

18. Tipo Características
Batchable
(siginificando
Apex por
Lotes)
• Each execution of a batch Apex job is considered a discrete transaction. A batch Apex job that
contains 1000 records and is executed without the optional scope parameter is considered 5
transactions of 200 records each. The Apex governor limits are reset for each transaction
• The execution logic of the batch class is called once for each batch of records you are processing.
• Each time you invoke a batch class, the job is placed on the Apex job queue and is executed as a
discrete transaction. This functionality has two awesome advantages:
• Every transaction starts with a new set of governor limits, making it easier to ensure that your code
stays within the governor execution limits.
• If one batch fails to process successfully, all other successful batch transactions aren’t rolled back.
• Implementación de la interfaz Database.Batchable con 3 métodos especializados: start, execute,
finish (recolectar, ejecutar y housekeeping)
• Batches of records tend to execute in the order but the order of execution isn’t guaranteed
• Apex por lotes no suele tener ningún estado. Cada ejecución de un trabajo de Apex por lotes se
considera una transacción discreta. Añadiendo la interfaz Database.Stateful mantenemos el estado
en todas las transacciones.
• If the first transaction succeeds but the second fails, the database updates are not rolled back
• Para invocar Callouts hay que introducir otra nueva interfaz Database.AllowsCallouts
• Batch Chaining: a batch job by calling Database.executeBatch or System.scheduleBatch from the
finish method of the current batch class. The new batch job will start after the current batch job
finishes.
• En https://developer.salesforce.com/docs/atlas.en-
us.212.0.apexcode.meta/apexcode/apex_batch_interface.htm existen especificaciones detalladas
de Best Practices y Governor Limits
Anexo - Mecanismos

19. Tipo Características
Schedulable
• El scheduler de Apex permite retrasar la ejecución para que pueda ejecutar clases de Apex en un
momento especificado.
• Esta opción es ideal para tareas de mantenimiento diarias o semanales mediante Batch Apex.
• Como máximo 100 jobs programados simultáneamente y máximo de ejecuciones de Apex cada
periodo de 24 horas en ventana flotante.
• No podemos invocar Web Services síncronos, sino qué deben ser asincronos con
@Future(callout=true)
• Si el Scheduler invoca a un Batch, si se pueden incluir Web Services (síncronos).
Repasemos los mecanismos