L'elaborazione asincrona aumenta la scalabilità consentendo limiti più elevati per contesto. Le richieste asincrone vengono eseguite nei propri thread in background, quindi gli utenti possono continuare a lavorare sul lato client mentre le operazioni asincrone vengono eseguite in background.

Salesforce Lightning Platform offre una varietà di tecnologie asincrone che possono essere utilizzate per risolvere un determinato caso d'uso. Ogni tecnologia presenta vantaggi e limiti che sarà necessario considerare quando si seleziona un approccio per ogni caso d'uso.

Quando si sceglie una tecnologia per l'implementazione, tenere presenti tre considerazioni importanti:

1. L'elaborazione asincrona non è l'approccio migliore per ogni problema. Può essere allettante pensare a qualsiasi processo che non richieda direttamente l'interazione dell'utente come a un buon candidato per l'elaborazione asincrona, ma ci sono alcuni svantaggi. In primo luogo, i processi asincroni non hanno SLA, il che significa che non vi è alcuna garanzia che un processo asincrono venga completato entro un determinato periodo di tempo. In secondo luogo, non è garantita una latenza di risposta costante. Se un processo asincrono viene completato entro un determinato periodo di tempo, il completamento di un processo successivo può richiedere un periodo di tempo diverso. Pertanto, anche se un utente non è direttamente in attesa di una risposta, l'elaborazione asincrona potrebbe non essere adatta allo scenario se si hanno processi successivi che dipendono da una risposta o se si teme che tempi di risposta eccessivi possano causare la perdita di sincronizzazione dei dati con i dati di un sistema esterno.
2. Esistono diversi modi per elaborare le richieste asincrone in Salesforce Platform, quindi assicurarsi di scegliere l'approccio migliore. Le tecnologie che supportano l'elaborazione asincrona in Salesforce Platform funzionano in modo diverso e alcune sono state progettate per casi d'uso molto specifici.
3. Se una tecnologia è asincrona sul lato client, non significa necessariamente che tutta l'elaborazione end-to-end venga eseguita in parallelo. A seconda delle scelte effettuate, a volte i messaggi del client possono comunque essere serializzati sul lato server.

Se si utilizzano tecnologie sbagliate o combinazioni di tecnologie sbagliate per un processo, possono verificarsi conseguenze indesiderate che annullano i vantaggi dell'elaborazione asincrona. Questa guida fornisce spiegazioni e consigli, nonché potenziali inconvenienti e schemi contrari per vari casi d'uso asincroni, insieme alla motivazione di tali consigli. Offre inoltre informazioni sul funzionamento e la regolamentazione di varie tecniche di implementazione asincrona in Salesforce Platform.

Se si sta decidendo quale tecnologia utilizzare, è disponibile una Guida alle decisioni mirata che offre una mappatura rapida dei casi d'uso tipici alla tecnologia più adatta.

Salesforce Lightning Platform è una piattaforma completa basata sull'intelligenza artificiale che unifica dipendenti, agenti autonomi dell'intelligenza artificiale, dati aziendali e applicazioni in un unico sistema affidabile per migliorare la produttività e l'esperienza dei clienti. Consente la creazione di un'"azienda autentica" collegando le app Customer 360, Data Cloud e Slack per l'automazione end-to-end.

Questo documento non tratta le tecnologie in altri ecosistemi come MuleSoft, Informatica, Commerce Cloud, Tableau e Marketing Cloud.

Tenere presente che questa guida si concentra esclusivamente sull'elaborazione asincrona all'interno di Salesforce Lightning Platform. Se si cercano informazioni sugli schemi di integrazione asincrona, vedere Architettura basata sugli eventi.

• Prima di utilizzare l'elaborazione asincrona, assicurarsi che i casi d'uso corrispondano allo schema. Gli schemi asincroni non hanno SLA, sono soggetti a più meccanismi governor, possono avere limiti di capacità definiti in base alle licenze e possono causare ritardi di elaborazione a causa della natura finita delle risorse allocate all'infrastruttura asincrona all'interno di Salesforce Platform. Prendere in seria considerazione queste limitazioni quando si utilizza l'elaborazione asincrona in scenari in cui un utente richiede una risposta dal sistema prima di poter continuare il proprio lavoro.
• L'elaborazione asincrona con Salesforce non è una soluzione per esigenze di scalabilità infinite. Salesforce Platform non scala all'infinito e gli schemi asincroni sono ancora soggetti a limitazioni. L'elaborazione asincrona utilizza i thread, che contengono le informazioni contestuali necessarie a una CPU per eseguire un flusso di istruzioni. I thread possono essere eseguiti in parallelo. Poiché il numero di thread disponibili in qualsiasi CPU è limitato, la piattaforma dispone di meccanismi per garantire che i thread disponibili vengano utilizzati nel modo più efficiente possibile. Il meccanismo di controllo del flusso della piattaforma evita che le organizzazioni consumino troppi thread e influiscano negativamente sulle altre organizzazioni. L'algoritmo di fair use della piattaforma controlla il numero di thread disponibili per un'organizzazione per ogni tipo di messaggio specifico.
• Sapere quando le transazioni sono veramente asincrone. Alcuni modelli di architettura si comportano in modo asincrono end-to-end. Tuttavia, altri processi si comportano in modo asincrono sul lato client o browser, ma serializzano le richieste lato server, che sono quindi soggette ai limiti del governor sincrono.
• Per creare integrazioni in uscita su larga scala da Salesforce Platform, utilizzare eventi piattaforma e middleware efficaci anziché chiamate tramite Apex asincrono. Poiché nella piattaforma è disponibile un numero finito di thread asincroni, le integrazioni in uscita tramite Apex asincrono hanno una scalabilità limitata. Se l'organizzazione dispone di integrazioni in uscita che comportano volumi elevati di messaggi, superano il numero di thread disponibili e hanno tempi di elaborazione lunghi, l'utilizzo di Apex asincrono introdurrà inevitabilmente ritardi.
• Assicurarsi di incorporare il monitoraggio quando si utilizza l'elaborazione asincrona. Con il monitoraggio è possibile rilevare i problemi il prima possibile e correggerli prima che si verifichino incidenti di prestazioni gravi.
• Tenere conto degli eventi che possono causare carichi estremi. Quando si progettano processi asincroni, assicurarsi che siano in grado di gestire in modo prevedibile picchi e pause del carico di lavoro. Considerare il modo in cui l'implementazione gestisce gli eventi imprevisti, ad esempio le interruzioni di corrente, e progettare misure di protezione che riducono la perdita di dati o di funzionalità.

Quando si seleziona un approccio per l'elaborazione asincrona lato server, valutare innanzitutto i requisiti dell'organizzazione e le risorse disponibili. L'obiettivo è quello di selezionare un approccio che riduca al minimo i costi di implementazione e manutenzione, garantendo al contempo la scalabilità e riducendo al minimo la probabilità di violazioni dei limiti. Questo obiettivo dipende dalle considerazioni tecniche descritte nelle sezioni successive e dalla composizione del team. Si supponga ad esempio di avere sviluppatori Apex nel proprio team in grado di gestire la soluzione pro-code. In caso contrario, un approccio dichiarativo può avere più senso. Inoltre, tenere presente che diversi insiemi di limiti possono essere applicati a strumenti diversi.

Considerare il caso d'uso di un processo di ordinazione asincrono in Salesforce. Quando un ordine viene salvato, viene attivato un messaggio a un sistema di gestione del magazzino esterno con istruzioni speciali su come imballare e spedire un articolo. Poiché l'utente che effettua l'ordine non necessita di una risposta immediata dal sistema di gestione del magazzino, la richiesta può essere inviata in modo asincrono. L'elaborazione asincrona consente all'utente di continuare il lavoro senza ritardi.

Considerazioni sull'architettura:

• Quanti processi simultanei sono necessari?
• Come interagiranno tra loro i processi simultanei?
• Quante query SOQL verranno eseguite all'interno di ogni processo?
• Quante operazioni DML verranno eseguite all'interno di ogni processo?
• Quanto durerà l'esecuzione di ogni processo?
• In che misura i processi sono sensibili a tempistiche specifiche?

L'architettura multi-tenant di Salesforce Platform isola e supporta contemporaneamente le diverse esigenze di molti tenant (organizzazioni). Tutti i metodi Apex asincroni descritti in questa guida vengono eseguiti nella stessa infrastruttura asincrona in Salesforce Platform. Utilizzano un framework di inserimento in area di attesa dei messaggi gestito da due meccanismi di applicazione principali: il controllo del flusso e l'utilizzo corretto.

Il controllo del flusso e i meccanismi di utilizzo corretto evitano che un singolo tenant utilizzi troppe risorse del server e non lasci risorse sufficienti per i tenant rimanenti. Benché sia utile capire come funzionano questi meccanismi, la cosa più importante è che seguire le procedure consigliate per l'elaborazione asincrona, come quelle descritte nelle sezioni successive, riduce in modo significativo la probabilità di incorrere in problemi.

Il meccanismo di controllo del flusso della piattaforma impedisce a un'organizzazione di sovraccaricare un determinato tipo di messaggio, il che consuma troppi thread e influisce negativamente sulle altre organizzazioni. Prima di aggiungere nuove voci all'area di attesa associata a un tipo di messaggio, il framework controlla le prime diverse migliaia di voci esistenti nell'area di attesa. Se la maggior parte delle voci esistenti è associata alla stessa organizzazione e l'organizzazione ha già voci nei thread dei lavoratori, le voci appena aggiunte vengono spostate in fondo all'area di attesa. Questo processo è detto reinserimento in area di attesa. La riassegnazione dell'area di attesa avviene in genere per i processi Batch Apex e API in blocco poiché spesso inseriscono un numero elevato di voci nelle aree di attesa contemporaneamente.

Il meccanismo di utilizzo equo della piattaforma implementa un sistema basato su livelli. Il sistema garantisce che ogni organizzazione in Salesforce Platform riceva una giusta parte del tempo di elaborazione per un determinato tipo di messaggio, inclusi i tipi di messaggio Futuro, In area di attesa e Batch. Se un'organizzazione domina un determinato tipo di messaggio nello stesso periodo in cui altre organizzazioni sono in attesa di eseguire il lavoro sullo stesso tipo di messaggio, l'algoritmo di utilizzo equo riduce il numero di thread disponibili per quel particolare tipo di messaggio.

Un vantaggio dell'utilizzo dei metodi Apex asincroni è che alcuni limiti del governor, ad esempio i limiti delle query SOQL e delle dimensioni dell'heap, sono più elevati. Tuttavia, non affidarsi troppo a questi metodi. A causa delle risorse limitate allocate all'infrastruttura asincrona, l'utilizzo intensivo di Apex futuro, accodabile e batch può causare ritardi di elaborazione dovuti a limitazioni basate su un utilizzo equo e sul controllo del flusso.

Le chiamate in uscita che utilizzano Apex asincrono vengono conteggiate nel limite Apex asincrono. Il limite giornaliero è attualmente 250.000 o 200 volte il numero di licenze utente applicabili, a seconda di quale sia il valore maggiore. Questo limite può essere un problema per i casi d'uso a volume elevato. Se si supera il limite, i processi Apex asincroni e le chiamate in uscita associate avranno esito negativo.

Inoltre, poiché la piattaforma ha un numero finito di thread asincroni disponibili, le integrazioni in uscita tramite Apex asincrono hanno una scalabilità limitata. Qualsiasi integrazione in uscita a volume elevato che supera il numero di thread disponibili può richiedere lunghi tempi di elaborazione e causare ritardi.

Per i casi d'uso a volume elevato, considerare i seguenti approcci alternativi. Le chiamate API con questi approcci vengono conteggiate nel limite giornaliero di richieste API, che è significativamente superiore al limite Apex asincrono giornaliero. Pertanto, questi approcci sono più scalabili. Tenere presente, tuttavia, che esistono ancora limitazioni fisiche al numero di richieste simultanee che qualsiasi CPU può elaborare.

• Middleware Scheduled Pull. Evitare ritardi associati a processi di integrazione in uscita a volume elevato utilizzando middleware per estrarre i dati su base pianificata anziché inviarli tramite Apex asincrono. Il middleware, ad esempio MuleSoft Anypoint Platform, può utilizzare l'API SOAP nativa o l'API REST in modo sincrono in modo che vengano introdotti pochi ritardi. Middleware può anche utilizzare l'API in blocco nativa per volumi di dati elevati.

• Trascinamento middleware tramite notifica evento piattaforma. Anziché mettere in area di attesa Apex asincrono Future, Queueable o Batch per eseguire integrazioni in uscita, è possibile utilizzare gli eventi piattaforma. L'evento piattaforma può fornire da solo le informazioni in uscita o indicare a uno strumento middleware di estrarre le informazioni richieste tramite un'API nativa e consegnarle alla destinazione finale. Nessuno di questi approcci è soggetto ai ritardi a cui è soggetto Apex asincrono. Tuttavia, rimangono validi i limiti degli eventi piattaforma.

Con Queueable Apex è possibile eseguire processi Apex che comportano operazioni di database estese o chiamate a servizi Web esterni in modo asincrono. Per utilizzare Queueable Apex, implementare l'interfaccia Queueable e quindi aggiungere un processo all'area di attesa dei processi Apex. Questo approccio garantisce che il processo Apex asincrono venga eseguito in background nel proprio thread isolato e non ritardi l'esecuzione della logica Apex principale. Ogni processo in area di attesa viene eseguito quando le risorse di sistema diventano disponibili.

Queueable Apex rappresenta l'evoluzione di Apex asincrono. Offre funzioni che non sono disponibili per i metodi Apex futuri, tra cui:

• ID processo: Quando si invia un processo invocando il metodo System.enqueueJob, il metodo restituisce l'ID del nuovo processo. È possibile utilizzare questo ID per identificare il proprio lavoro. Per monitorarne l'avanzamento, visualizzare la pagina Processi Apex in Imposta in Salesforce o eseguire una query sull'oggetto AsyncApexJob.
• Supporto per i tipi non primitivi: Le classi in area di attesa possono contenere variabili membro di tipi di dati non primitivi, ad esempio sObject o tipi Apex personalizzati.
• Supporto per il job chaining: È possibile concatenare i processi In area di attesa avviando un secondo processo da un processo in esecuzione. Questa tecnica può essere utile per risolvere gli scenari che comportano dipendenze dei processi.
• Controllo della profondità massima: È possibile configurare i processi in area di attesa con una profondità massima dello stack per evitare che le catene di processi si concludano con una ricorsione imprevista.
• Firme della duplicazione: I processi in attesa forniscono una firma facoltativa per rilevare e rimuovere i processi duplicati.
• Ritardo configurabile: È possibile definire un ritardo fino a 10 minuti prima dell'esecuzione del processo In attesa.
• Finalizzatori delle transazioni: È possibile allegare una sequenza post-azione a un processo Area di attesa ed eseguire azioni pertinenti in base al risultato. Ad esempio, un finalizzatore di transazione può rimettere in area di attesa un processo In area di attesa che non è riuscito a causa di un'eccezione non gestita fino a cinque volte.

Salesforce utilizza un framework basato sull'area di attesa per gestire i processi asincroni. Questa area di attesa viene utilizzata per bilanciare i carichi di lavoro delle richieste tra le organizzazioni. Per assicurarsi che l'organizzazione utilizzi questa area di attesa nel modo più efficiente possibile:

• Evitare di mettere in area di attesa i metodi futuri o In area di attesa direttamente dalle azioni generate da volumi elevati di attività degli utenti finali o chiamate API di integrazione. Questo approccio può esaurire rapidamente i limiti Apex asincroni giornalieri, causando gravi impatti sul business.
• Evitare di mettere in area di attesa più di un'azione asincrona per azione sincrona. Quando più metodi asincroni sono inseriti in area di attesa da una singola azione sincrona, le attività asincrone spesso vengono eseguite contemporaneamente e contribuiscono a errori di blocco delle righe e/o timeout di blocco delle righe.
• Evitare di aggiungere un numero elevato di metodi futuri o in area di attesa all'area di attesa asincrona.
• Assicurarsi che i metodi future e Queueable vengano eseguiti il più rapidamente possibile. Più tempo richiede l'esecuzione di un metodo futuro, più è probabile che le richieste che lo riguardano nell'area di attesa subiscano ritardi. Per garantire un'esecuzione rapida dei processi batch, ridurre al minimo i tempi di chiamata ai servizi Web, perfezionare le query utilizzate nei metodi futuri e ottimizzare qualsiasi altra automazione degli oggetti, inclusi i processi di Process Builder, le regole di flusso di lavoro, i flussi e i trigger Apex.
• Testare i metodi asincroni su larga scala. Utilizzare un ambiente che generi il numero massimo di metodi che si prevede di gestire. Questo test consente di determinare se si verificano problemi di prestazioni o limiti nell'ambiente di produzione. Considerare anche l'impatto sui limiti giornalieri cumulativi.
• Utilizzare Batch Apex anziché metodi futuri o Area di attesa per elaborare un numero elevato di record. Batch Apex può gestire processi complessi e di lunga durata che vengono eseguiti su migliaia di record e può essere pianificato per l'esecuzione durante gli orari di attività quando sono disponibili più risorse.

Utilizzare Apex pianificato per l'esecuzione a un'ora specificata e a una frequenza ripetuta definita da un'espressione cron. Sebbene l'atto di pianificare Apex tramite l'espressione cron sia un processo asincrono, il codice sottostante viene eseguito in modo sincrono all'avvio del processo. Apex pianificato è ideale per le operazioni di manutenzione giornaliere o settimanali.

• È possibile avere solo 100 processi Apex pianificati contemporaneamente. Per evitare questa limitazione, valutare la possibilità di utilizzare un flusso attivato da pianificazione che invoca Apex Code anziché Apex pianificato.
• Prestare la massima attenzione se si prevede di pianificare una classe da un trigger. È necessario essere in grado di garantire che il trigger non aggiunga un numero di classi pianificate superiore al limite. In particolare, considerare gli aggiornamenti in blocco API, le procedure guidate di importazione, le modifiche globali dei record tramite l'interfaccia utente e tutti i casi in cui è possibile aggiornare più di un record alla volta.
• Per le operazioni una tantum che devono essere pianificate fino a 10 minuti dopo, utilizzare un processo Area di attesa ritardato. Questo approccio non viene conteggiato nel limite di 100 processi pianificati.
• Apex pianificato viene eseguito in un contesto sincrono con limiti sincroni.
• Considerare la durata dell'esecuzione del processo pianificato. Un processo di lunga durata può sovrapporsi all'inizio del successivo processo pianificato.
• Salesforce pianifica l'esecuzione della classe all'ora specificata. L'effettiva esecuzione può essere ritardata in base alla disponibilità del servizio. I processi pianificati per l'esecuzione durante il tempo di inattività della manutenzione del servizio verranno pianificati per l'esecuzione dopo la ripresa del servizio.
• Utilizzare System.scheduleBatch per pianificare processi batch anziché avere un processo pianificato con il solo scopo di mettere in area di attesa un processo batch.

Storicamente, le chiamate sincrone effettuate da un metodo Apex eseguito in un contesto di transazione Apex sincrona, ad esempio un controller Visualforce o un controller di componenti Lightning, erano soggette al limite di concomitanza Apex per le richieste di lunga durata. A partire dal rilascio Winter '19, le chiamate sincrone non vengono più conteggiate come di lunga durata. Benché le continuazioni Apex siano state inizialmente create come soluzione alle chiamate sincrone che hanno generato richieste di lunga durata, offrono anche alcuni vantaggi aggiuntivi.

• Una singola azione sincrona può eseguire fino a tre azioni di continuazione. La continuazione precedente deve essere completata prima che venga eseguita una nuova azione di continuazione.
• Ogni azione di continuazione può eseguire fino a un massimo di tre chiamate, che vengono eseguite in parallelo.
• Al termine di tutte le chiamate eseguite da un'azione di continuazione, la piattaforma invoca il metodo di richiamata della continuazione per gestire i risultati.

Sebbene le continuazioni vengano eseguite in modo asincrono rispetto all'azione sincrona di origine, esistono differenze chiave tra le continuazioni Apex e altre tecniche Apex asincrone come i metodi futuri, In area di attesa o Batch. Le differenze principali sono:

• Le continuazioni non vengono inserite in alcuna area di attesa.
• Le continuazioni non contribuiscono al limite giornaliero di esecuzione Apex asincrona.
• Le continuazioni trasformano il contesto del thread nel server delle applicazioni da un thread di piattaforma Apex pesante a un thread leggero che esegue solo chiamate. Ai fini dell'esecuzione di chiamate che possono durare fino a 120 secondi, le continuazioni offrono un notevole risparmio di memoria del server di applicazioni.
• In origine, le continuazioni potevano essere eseguite solo da una chiamata remota Visualforce JavaScript. Tuttavia, nel rilascio Summer '19, le continuazioni sono state ufficialmente aggiunte al framework Componente Lightning, eliminando la necessità di Visualforce.

Gli eventi piattaforma sono l'implementazione di Salesforce Platform di un'architettura basata esclusivamente sugli eventi. Per ulteriori dettagli sui componenti associati a questo tipo di architettura, vedere Architect’s Guide to Event-Driven Architecture.

Gli eventi piattaforma e i trigger/flussi di eventi piattaforma sono spesso ottime alternative all'esecuzione di Apex asincrono. Sono anche un ottimo modo per invocare l'elaborazione esterna alla piattaforma. Ad esempio, è possibile utilizzare una combinazione di relè eventi Amazon Web Services ed eventi piattaforma per invocare la funzionalità di elaborazione serverless in AWS Lambda. Il lavoro eseguito in modo relativamente rapido e senza chiamate (che non sono possibili da un trigger evento piattaforma o da un flusso) è un ottimo candidato per una combinazione evento piattaforma/trigger o evento/flusso.

Gli eventi pubblicati sul bus tramite publish after commit vengono consegnati in ordine e possono essere elaborati in blocco dal trigger o dal flusso in un contesto sincrono separato. Il contesto è sincrono e impone tutti i limiti del governor sincrono. Scegliere con attenzione il trigger evento piattaforma/la dimensione del batch di flusso per evitare di superare i limiti.

• Poiché gli eventi vengono pubblicati sul bus degli eventi, sono disponibili per i consumatori. Nel caso dei trigger di evento (Apex o flusso), questi eventi vengono inviati ai thread sincroni disponibili nel livello dell'app (un thread per trigger di evento/flusso). Tenere presente che questo processo non ha un contratto sul livello di servizio.
• Quando le operazioni di pubblicazione vengono aggiunte all'area di attesa, il risultato del processo di attesa viene memorizzato nell'oggetto Database.SaveResult. Queste voci indicano solo se l'operazione di attesa è riuscita o meno. Per ottenere il risultato finale di un evento pubblicato tramite il bus degli eventi, implementare una richiamata Apex publish. Con queste informazioni aggiuntive è possibile prendere decisioni su ulteriori azioni, ad esempio tentare di ripubblicare eventi non riusciti.
• Benché gli eventi piattaforma non siano soggetti agli stessi limiti dell'Apex asincrono, essi hanno i propri insiemi di limiti. Se si verificano problemi con i limiti, è possibile abilitare le metriche di utilizzo per determinare se eventi specifici stanno consumando più allocazioni di quanto previsto. Se si necessita di una maggiore produttività per i trigger di eventi, valutare la possibilità di utilizzare abbonamenti paralleli per elaborare gli eventi contemporaneamente anziché in un unico stream. Con gli abbonamenti paralleli, è possibile scalare i trigger di eventi piattaforma Apex per gestire volumi elevati di eventi. Gli abbonamenti paralleli sono disponibili per gli eventi piattaforma personalizzati a volume elevato ma non per gli eventi standard o gli eventi di modifica.
• Gli eventi piattaforma hanno due opzioni per il comportamento di pubblicazione:
  • Pubblica immediatamente: Gli eventi vengono pubblicati immediatamente durante la transazione, prima della conferma definitiva del database. Non è garantito che gli eventi pubblicati in questo modo vengano pubblicati in ordine.
  • Pubblica dopo l'impegno: Gli eventi vengono pubblicati nel momento in cui la transazione del database viene confermata correttamente. È garantito che gli eventi pubblicati in questo modo vengano pubblicati in ordine.

È utile utilizzare Pubblica immediatamente per i casi d'uso, ad esempio la registrazione, in cui si desidera pubblicare l'evento di registrazione indipendentemente dal fatto che la transazione abbia esito positivo e confermi o meno e venga ritirata. È possibile pubblicare immediatamente un evento piattaforma consumato da un trigger evento piattaforma. Il trigger evento piattaforma compete quindi per un blocco di riga del database con la transazione che lo ha pubblicato. Esaminare attentamente tutte le strutture prima di pubblicare immediatamente gli eventi piattaforma per assicurarsi di evitare questo scenario.

I flussi asincroni offrono alternative low-code ad Apex asincrono. Come per altre forme di elaborazione asincrona, vengono eseguite in background quando sono disponibili risorse. Anche i flussi asincroni non hanno SLA e possono avere tempi di attesa imprevedibili.

I percorsi pianificati sono basati su trigger cron da eseguire in un momento specifico. Vengono eseguiti quando i record vengono creati, aggiornati o eliminati e offrono un controllo granulare su quando eseguire l'automazione relativa alla modifica del record. (Esempio: inviare un'email a un utente un'ora prima della scadenza di un'operazione). A differenza dei metodi Apex futuri, che sono limitati a un massimo di 50 metodi inseriti in un'area di attesa in una transazione sincrona, le azioni di flusso pianificate non hanno attualmente un limite massimo di aree di attesa per transazione. Tuttavia, all'interno della definizione del percorso pianificato è presente una configurazione delle dimensioni del batch che consente un certo controllo sul numero di record gestiti dall'esecuzione del flusso del percorso pianificato.

I percorsi asincroni possono essere aggiunti ai flussi attivati da record. Vengono eseguiti in background e non ritardano l'esecuzione della transazione che ha attivato il flusso in origine. È possibile utilizzare un percorso asincrono per eseguire un'operazione di lunga durata o qualsiasi operazione che si desidera eseguire nel proprio tempo. I percorsi asincroni possono aiutare a evitare errori DML misti che si verificano quando è necessario aggiornare un valore di un record correlato che non fa parte del record che ha attivato il flusso.

Nota: La messaggistica in uscita è una funzione legacy e gli eventi piattaforma (descritti nella sezione precedente) sono un approccio più moderno e offrono maggiore flessibilità. Gli eventi piattaforma sono lo schema consigliato da Salesforce per l'integrazione basata sugli eventi.

I messaggi in uscita forniscono un mezzo di comunicazione in uscita asincrona tramite l'API SOAP. Se configurata in Salesforce, la definizione del messaggio in uscita genera un WSDL SOAP che può essere utilizzato da un fornitore di servizi Web esterno. I messaggi in uscita possono essere attivati da regole di flusso di lavoro, processi di Process Builder o trigger di flusso Lightning dopo il salvataggio. Un messaggio SOAP in uscita può contenere fino a 100 notifiche. Ogni notifica contiene l'ID oggetto e un riferimento ai dati sObject associati. Se le informazioni nell'oggetto sottostante cambiano dopo l'area di attesa della notifica ma prima dell'invio, vengono consegnati solo i dati più recenti e non le modifiche intermedie.

Quando un listener di messaggi in uscita (il servizio Web configurato con il WSDL generato) riceve un messaggio, utilizza le informazioni dell'ID sessione incluse per chiamare l'API Lightning Platform per aggiornare il record in Salesforce che ha attivato il messaggio in uscita.

• I messaggi in uscita non vengono gestiti tramite l'infrastruttura asincrona basata sull'area di attesa in Salesforce che esegue attività come metodi futuri, Queueable Apex, Batch Apex, API in blocco e così via. I record vengono invece memorizzati localmente nell'oggetto OutboundMessage. I messaggi vengono inviati e riprovati tramite un processo in background pianificato locale.
• I messaggi non vengono inviati in modo sincronizzato quando l'azione del messaggio in uscita viene eseguita dall'automazione di avvio (ad esempio, un trigger di flusso dopo il salvataggio). Rimangono invece nell'oggetto OutboundMessage fino a quando non vengono inviati correttamente o fino a quando non vengono eliminati dopo 24 ore dalla consegna non riuscita.
• Per evitare un loop infinito di messaggi in uscita, assicurarsi che l'utente che aggiorna gli oggetti non disponga dell'autorizzazione Invia messaggi in uscita.

Email a caso funziona normalmente in modo sincrono. Esiste un limite di quattro thread sincroni per gestire le richieste Email a caso in entrata. Il modulo sincrono dell'handler mantiene una connessione al server di posta Salesforce (MTA) in entrata che riceve il messaggio email. Tuttavia, esistono diversi motivi per cui Email a caso può essere gestito in modo asincrono:

• Email a caso è soggetto a limiti di thread, in particolare 10 thread handler totali per server di app: quattro thread per l'elaborazione sincrona e sei thread per l'elaborazione asincrona.
• Se un handler di email sincrono supera i 15 secondi di tempo di esecuzione, quel particolare indirizzo del servizio di email viene contrassegnato come asincrono per un periodo di 30 minuti. Le successive richieste dell'handler per quell'indirizzo di servizio restituiscono un messaggio che viene inserito nell'area di attesa per MessageTypeName = MAILCATCHER_EMAIL_TO_CASE, insieme a un riferimento al contenuto dell'email.
• Se un thread sincrono è già in uso per una determinata organizzazione e indirizzo di servizio, le richieste aggiuntive per quell'indirizzo di servizio vengono inserite in area di attesa in modo asincrono.
• Se un messaggio email gestito in modo sincrono rileva un errore, ad esempio un timeout di blocco delle righe, la richiesta viene salvata e inserita in area di attesa in modo asincrono.
• Se non sono disponibili thread di handler sincroni, la richiesta viene inserita in area di attesa in modo asincrono.

• Quando si configura Email a caso è disponibile un'opzione di deduplica, ma gli allegati vengono duplicati solo dopo l'elaborazione dell'email. Questa duplicazione consente di risparmiare spazio nel database, ma non riduce i tempi di elaborazione delle email. È tuttavia possibile migliorare le prestazioni implementando un handler Apex Email a caso personalizzato per l'elaborazione dei messaggi. Questa implementazione non influisce su alcun limite del governor, ma concede all'handler l'accesso al messaggio email e a tutti i relativi allegati prima che venga eseguito il commit nel database. Questo accesso consente di calcolare i checksum per tutti gli allegati inclusi e di scartare quelli che si ritengono non necessari, inclusi i duplicati, le immagini delle firme note o i tipi di file indesiderati.
• La conferma degli allegati email in Salesforce Files è responsabile della maggior parte del tempo di elaborazione dei messaggi email. Man mano che le risposte al referente o da esso provenienti aumentano e la catena di email aumenta, aumenta anche il tempo di elaborazione di ogni email. Se l'opzione email "Rispondi solo con nuovo contenuto" non è selezionata, le catene di email cresceranno con ogni risposta. Pertanto, si consiglia di utilizzare un handler Email a caso Apex con una logica che implementa la deduplica degli allegati al momento dell'elaborazione.
• Nonostante l'invocazione di trigger Apex come parte della gestione, gli handler Email a caso sono esenti dal limite Apex simultaneo.

Per elaborare grandi volumi di record in modo asincrono, valutare la possibilità di utilizzare uno dei seguenti approcci.

È possibile utilizzare Batch Apex per creare processi complessi e di lunga durata che coinvolgono migliaia di record. Batch Apex opera suddividendo l'insieme di record ed elaborandolo in blocchi gestibili. Ad esempio, è possibile creare una soluzione di archiviazione che viene eseguita ogni notte e aggiunge record più vecchi di una determinata data a un archivio. Oppure è possibile creare un'operazione di pulitura dei dati che esamina tutti gli account e le opportunità ogni notte ed esegue gli eventuali aggiornamenti necessari in base a una serie di criteri predefiniti.

• Batch Apex è più adatto per l'elaborazione di grandi quantità di dati perché Apex asincrono ha limiti più elevati rispetto ad Apex sincrono. Batch Apex funziona anche in modo più efficiente quando elabora più elementi per batch perché utilizza operazioni in blocco che comportano meno sovraccarico dalla gestione dell'area di attesa. Pertanto, per evitare di attivare il meccanismo di controllo del flusso tramite l'allagamento dell'area di attesa ed evitare di esaurire il limite Apex asincrono giornaliero, non creare batch di piccole dimensioni o con tempi di elaborazione rapidi.
• Evitare di mettere in area di attesa i processi batch direttamente dalle azioni generate da volumi elevati di attività degli utenti finali o chiamate API di integrazione. Questo approccio può esaurire rapidamente l'area di attesa Flex. Se si prevede di invocare un processo batch da un trigger, è necessario garantire che il trigger non aggiunga altri processi batch oltre al limite.
• Batch Apex è limitato a un massimo di cinque thread simultanei, il che limita la sua produttività molto di più rispetto ai metodi futuri o Queueable Apex.
• L'ideale sarebbe pianificare l'esecuzione di processi batch che coinvolgono grandi volumi di dati durante gli orari di attività ridotta, in modo da liberare risorse per i processi che richiedono risposte in tempo reale o quasi in tempo reale.
• Quando si chiama System.scheduleBatch, la piattaforma pianifica l'esecuzione del processo nel momento specificato. L'effettiva esecuzione avviene in corrispondenza o dopo tale orario, a seconda della disponibilità del servizio.
• Lo strumento di pianificazione viene eseguito nel contesto di sistema. Tutte le classi vengono eseguite, indipendentemente dal fatto che l'utente che ha pianificato l'esecuzione disponga o meno dell'autorizzazione per eseguire la classe.
• Tutti i limiti Apex pianificati si applicano ai processi batch pianificati utilizzando System.scheduleBatch. Dopo che il processo batch è stato inserito in area di attesa (con stato In attesa o In attesa), vengono applicati tutti i limiti del processo batch e il processo non viene più conteggiato nei limiti Apex pianificati.
• Per un processo batch con una pianificazione ricorrente, considerare il comportamento corretto se il processo precedente è ancora in esecuzione quando inizia l'esecuzione del nuovo processo.
• I processi batch accodati da transazioni Apex sincrone utilizzano l'area Flex. L'area di attesa Flex è limitata a un massimo di 100 voci in qualsiasi punto. Se una transazione tenta di aggiungere altre voci, la piattaforma genera errori e non invia il processo batch.
• Le chiamate e altre operazioni non transazionali dei processi batch devono seguire considerazioni di progettazione idempotenti. I processi batch in attesa prima di un tempo di inattività di manutenzione del servizio Salesforce rimangono nell'area di attesa. Al termine del tempo di inattività del servizio e quando le risorse di sistema sono disponibili, vengono eseguiti i processi batch in area di attesa. Se un processo batch è in esecuzione quando si verifica un tempo di inattività, l'esecuzione del batch viene ritirata e riavviata dopo il ripristino del servizio. Poiché i metodi execute possono quindi essere eseguiti più volte, tutte le operazioni non transazionali, ad esempio le chiamate, possono essere riprovate.
• Valutare la possibilità di configurare il processo batch in modo che elevi gli eventi BatchApexErrorEvent per gestire gli scenari di errori ed eccezioni.

Un flusso attivato da pianificazione è un flusso pianificato per l'esecuzione a un'ora specifica e con una frequenza ripetuta (giornaliera, settimanale o una volta) per eseguire azioni su un batch di record. (Esempio: aggiornare un campo in tutti i casi con stato "Aperto" ogni notte alle 2:00). I flussi pianificati vengono eseguiti tramite il meccanismo di trigger cron e vengono elaborati in blocco.

• Un flusso attivato da pianificazione esegue 200 record per chiamata, ma verrà eseguito con più thread simultanei se sono presenti più di 200 record.
• I flussi attivati da pianificazione vengono eseguiti in un contesto sincrono con limiti sincroni.
• Attualmente non è possibile controllare il numero di record elaborati per ogni chiamata di flusso pianificata. Se l'esecuzione avviene per più di 200 record, esiste un reale pericolo di errori Apex simultanei.

L'API in blocco è basata sui principi REST ed è ottimizzata per l'utilizzo di serie di dati di grandi dimensioni. È possibile utilizzarlo per inserire, aggiornare, inserire con aggiornamento, eseguire query o eliminare molti record in modo asincrono ed elaborare i risultati in un secondo momento. Salesforce Platform elabora la richiesta in background. Al contrario, l'API SOAP e l'API REST utilizzano richieste sincrone e sono ottimizzate per le applicazioni client in tempo reale che aggiornano pochi record alla volta. È possibile utilizzare entrambe queste API per l'elaborazione di molti record, ma quando le serie di dati contengono centinaia di migliaia di record sono meno pratiche. Il framework asincrono dell'API in blocco è progettato per rendere semplice ed efficiente l'elaborazione di dati da poche migliaia a milioni di record.

Il modo più semplice per utilizzare l'API in blocco è abilitarla per l'elaborazione dei record in Data Loader utilizzando file CSV. Con Data Loader non è necessario scrivere la propria app client. A volte, tuttavia, requisiti specifici richiedono la scrittura di un'app personalizzata.

Sono disponibili due API in blocco in Salesforce Platform.

• L'API in blocco 2.0 è l'API più recente. Fornisce un flusso di lavoro semplificato e più facile da usare ed è al centro delle ottimizzazioni.
• L'API in blocco originale è ancora completamente supportata, ma non viene più ottimizzata. Si consiglia di utilizzare l'API in blocco 2.0 dove possibile.

Per ulteriori informazioni sui limiti API, vedere Limite API in blocco e Limite API 2.0 in blocco.

Fare riferimento a questa guida quando si crea o si considera l'elaborazione asincrona in Salesforce Platform. È sempre consigliabile comprendere l'intera gamma di opzioni disponibili e il modo in cui possono adattarsi al proprio caso d'uso specifico. Assicurarsi di valutare a fondo il panorama attuale prima di apportare modifiche alle architetture esistenti, soprattutto se la soluzione corrente funziona bene.