@future
La forma más sencilla de asíncrono: una anotación encima de un método static void. Se ejecuta después, en su propia transacción, y con callout=true puede llamar a otros sistemas.
✓ En esta sub-lección
- 01Escribir un método @future con sus tres reglas: static, void y parámetros simples.
- 02Explicar por qué se le pasan Ids y no registros.
- 03Llamar a @future una vez por lote, no una vez por registro.
La nutria: ¿Te acuerdas? · Repaso de la lección 1
¿Puede un trigger llamar al ERP por HTTP en mitad del guardado?
Cada renovación nueva que se crea en Salesforce tiene que llegar al ERP. El primer intento del equipo fue llamar al ERP desde el trigger, y Salesforce lo rechazó con «Callout from triggers are currently not supported». La solución más corta es una palabra: @future.
Una anotación y tres reglas
public class ErpNotifier {
@future(callout=true) // sin callout=true, no puede llamar fuera
public static void notifyRenewals(Set<Id> renewalIds) {
// … se ejecuta más tarde, en su propia transacción
}
}- static: no pertenece a ningún objeto, porque cuando se ejecute, el objeto que lo llamó ya no existirá.
- void: no devuelve nada, porque quien lo llamó ya terminó y no puede esperar la respuesta.
- Parámetros simples: tipos primitivos (Id, String, Integer…) o colecciones de ellos. Nunca sObjects.
for (Opportunity o : Trigger.new) {
ErpNotifier.notifyRenewals(new Set<Id>{ o.Id });
}Renovaciones en la carga: 3
llamadas @future (máx. 50)
3
peticiones al ERP
3
3 llamadas y 3 peticiones. Funciona… hasta la renovación 51.
Por qué Ids y no registros
Entre la llamada y la ejecución pasan segundos, a veces minutos. Si le pasaras la oportunidad entera, trabajaría con una foto vieja: alguien pudo cambiar el importe mientras tanto. Por eso Salesforce solo acepta Ids y valores simples, y el método consulta los registros al empezar. Así el ERP recibe los datos como están cuando se envían.
La nutria: ¿Y por qué no un Flow? Aquí Flow también llega