Callouts en asíncrono
Un callout desde un trigger tiene que ir en un trabajo asíncrono. Y ahí puedes hacer algo que en el guardado no cabría: si el otro sistema falla, volver a intentarlo más tarde, un número limitado de veces.
✓ En esta sub-lección
- 01Sacar un callout de un trigger a un Queueable con Database.AllowsCallouts.
- 02Reintentar con un contador de intentos y un tope.
- 03Decidir qué hacer cuando se agotan los intentos.
La nutria: ¿Te acuerdas? · Repaso de la lección 5
¿Qué lanza port.createInvoice(…) si el sistema de facturación no responde?
Al cerrarse una renovación hay que pedir su factura. El primer intento fue llamar a InvoiceClient desde el trigger: «Callout from triggers are currently not supported». El segundo, un Queueable: funciona, hasta la noche en que el sistema de facturación se cae diez minutos para una actualización y veinte facturas se quedan sin pedir.
Las reglas, juntas
- Desde un trigger, el callout va en un @future(callout=true) o en un Queueable con Database.AllowsCallouts (Módulo 9).
- Dentro del trabajo, primero el callout y después el DML, nunca al revés.
- Un trabajo asíncrono tiene los mismos límites de callouts: 100 por transacción y 120 segundos entre todos.
- Un Queueable puede encolar un hijo: es la pieza que permite reintentar.
Reintentar, con tope
} catch (ErpApiException e) {
if (attempt < MAX_ATTEMPTS) {
System.enqueueJob(new InvoiceRetryJob(erpCode, amount, attempt + 1)); // otra vez, más tarde
} else {
System.debug(LoggingLevel.ERROR, 'Sin factura tras ' + attempt + ' intentos'); // se acabó: avisar
}
}EL SISTEMA DE FACTURACIÓN VUELVE…
- InvoiceRetryJob(…, 1)
- InvoiceRetryJob(…, 2)
- InvoiceRetryJob(…, 3)
Paso 1 de 4
La renovación se cierra y el handler encola el intento 1. Pulsa Reproducir.
La nutria: ¿Y por qué no un Flow? Porque un flow no vuelve a intentarlo