Por qué existe el asíncrono
Hay trabajo que no cabe en el guardado del usuario: demasiadas filas, una llamada a otro sistema, un proceso nocturno. El código asíncrono se ejecuta más tarde, en su propia transacción y con límites más amplios.
✓ En esta sub-lección
- 01Explicar qué significa que un código sea asíncrono y cuándo hace falta.
- 02Comparar los límites síncronos y asíncronos.
- 03Saber en qué contexto se está ejecutando tu código.
La nutria: ¿Te acuerdas? · Repaso del Módulo 8
El importador del Módulo 8 revienta con una LimitException a mitad de la noche. ¿La puede capturar un catch?
El importador del Módulo 8 aguanta 300 filas. Pero el ERP de Northwind acaba de anunciar que la migración del año pasado entra este mes: 300.000 renovaciones. Ninguna bulkificación hace caber eso en una sola transacción. La salida no es hacer el código más rápido: es hacerlo en otro momento.
Síncrono y asíncrono
Todo lo que has escrito hasta ahora era síncrono: pasa mientras alguien espera, dentro del mismo guardado. El código se deja en una y Salesforce lo ejecuta cuando tiene recursos libres, normalmente segundos después. Corre en su propia transacción, con su propio presupuesto, y el usuario no espera por él.
EL USUARIO
LA COLA DE APEX
consultas por transacción
100
CPU por transacción
10 s
Paso 1 de 4
Todo va dentro del guardado. Pulsa Reproducir.
La nutria: Tu camino asíncrono de siempre
Por qué lo necesitarás
| Situación | Por qué no cabe en el guardado |
|---|---|
| Llamar a otro sistema (el ERP) | Un trigger no puede esperar a una respuesta externa: Salesforce no permite callouts en ese momento. |
| Procesar cientos de miles de filas | Ningún presupuesto de una transacción alcanza: hay que trocearlo. |
| Un proceso cada noche | Nadie está guardando nada a las 2:00: tiene que arrancar solo. |
| Un cálculo pesado tras guardar | El usuario no debería esperar diez segundos para ver su registro guardado. |
Más presupuesto, pero no infinito
| Límite por transacción | Síncrono | Asíncrono |
|---|---|---|
| Consultas SOQL | 100 | 200 |
| Tiempo de CPU | 10 s | 60 s |
| Memoria (heap) | 6 MB | 12 MB |
| Instrucciones DML | 150 | 150 |
Fíjate en la última fila: no todo sube. El asíncrono no te regala una transacción enorme; te regala muchas transacciones, cada una con su presupuesto. Por eso el Batch de la lección 4 no procesa 300.000 filas de golpe, sino en tandas de 200. Y tu código puede preguntar en cuál está: Limits.getLimitQueries() devuelve 100 o 200 según el contexto, y System.isBatch(), System.isFuture()… dicen quién lo está ejecutando.
La nutria: ¿Y por qué no un Flow? Aquí Flow también tiene su camino