Asynkron bearbetning ökar skalbarheten genom att tillåta högre gränser per sammanhang. Asynkrona begäranden körs i sina egna trådar bakom kulisserna, så användare kan fortsätta att utföra arbete på klientsidan medan de asynkrona uppgifterna körs i bakgrunden.

Salesforce Lightning Platform erbjuder en mängd olika asynkrona tekniker som kan användas för att lösa ett givet användningsfall. Varje teknik har fördelar och gränser som du måste överväga när du väljer ett tillvägagångssätt för varje användningsfall.

När du väljer en teknik för implementering är tre viktiga saker att tänka på:

1. Asynkron bearbetning är inte den bästa metoden för varje problem. Det kan vara frestande att tänka på en process som inte direkt kräver användarinteraktion som en bra kandidat för asynkron bearbetning, men det finns några nackdelar. För det första har asynkrona processer inget servicenivåavtal, vilket innebär att det inte finns någon garanti för att en asynkron process kommer att slutföras inom en viss tid. För det andra finns det ingen garanti för enhetlig svarslatens. Om en asynkron process slutförs inom en viss tid kan en efterföljande process ta olika lång tid att slutföra. Även om en användare inte väntar direkt på ett svar kanske asynkron bearbetning inte är rätt för ditt scenario om du har efterföljande processer som är beroende av ett svar, eller om du är orolig att överdrivna svarstider kan göra att dina data inte synkroniseras med data i ett externt system.
2. Det finns olika sätt att bearbeta asynkrona begäranden på Salesforce Platform, så se till att du väljer den bästa metoden. Tekniker som har stöd för asynkron bearbetning på Salesforce Platform fungerar annorlunda ”under ytan” och vissa har utformats för mycket specifika användningsfall.
3. Om en teknik är asynkron på klientsidan betyder det inte nödvändigtvis att all end-to-end-bearbetning utförs parallellt. Beroende på de val du gör kan klientens meddelanden ibland fortfarande serialiseras på serversidan.

Om du använder fel tekniker eller fel kombinationer av tekniker för ett jobb kan oavsiktliga konsekvenser uppstå som upphäver fördelarna med asynkron bearbetning. Denna guide ger förklaringar och rekommendationer, samt potentiella nackdelar och antimönster för olika asynkrona användningsfall, tillsammans med motiveringen för dessa rekommendationer. Den ger även insikt i hur olika asynkrona implementeringstekniker fungerar och regleras på Salesforce Platform.

Om du bestämmer vilken teknik du vill använda finns en fokuserad beslutsguide för asynkron bearbetning som ger en snabb mappning av typiska användningsfall till den teknik som passar bäst.

Salesforce Lightning Platform är en omfattande, AI-driven plattform som samlar anställda, autonoma AI-agenter, företagsdata och program i ett enda, tillförlitligt system för att förbättra produktiviteten och kundupplevelsen. Det gör det möjligt att skapa ett "agentföretag" genom att ansluta Customer 360 appar, Data Cloud och Slack för automatisering från början till slut.

Detta dokument täcker inte tekniker i andra ekosystem som MuleSoft, Informatica, Commerce Cloud, Tableau och Marketing Cloud.

Observera att denna guide endast fokuserar på asynkron bearbetning inom Salesforce Lightning Platform. Om du letar efter information om asynkrona integreringsmönster, se Händelsedriven arkitektur.

• Innan du använder asynkron bearbetning, se till att dina användningsfall passar mönstret. Asynkrona mönster har inga servicenivåavtal, är föremål för flera styrande mekanismer, kan ha kapacitetsgränser definierade baserat på licensiering och kan orsaka bearbetningsfördröjningar på grund av den ändliga karaktären hos resurserna som allokeras till asynkron infrastruktur inom Salesforce Platform. Tänk på dessa begränsningar noggrant när du använder asynkron bearbetning i scenarion där en användare behöver ett svar från systemet innan de kan fortsätta med sitt arbete.
• Asynkron bearbetning med Salesforce är inte en lösning för gränslösa skalbehov. Salesforce Platform skalar inte oändligt och asynkrona mönster är fortfarande föremål för begränsningar. Asynkron bearbetning använder trådar, som innehåller den sammanhangsinformation som en CPU behöver för att utföra en ström av instruktioner. Trådar kan köras parallellt. Antalet tillgängliga trådar i någon CPU är begränsat, så plattformen har mekanismer på plats för att säkerställa att dess tillgängliga trådar används så effektivt som möjligt. Plattformens flödeskontrollmekanism förhindrar organisationer från att konsumera för många trådar och påverka andra organisationer negativt. Plattformens algoritm för rättvis användning styr antalet trådar som en organisation har tillgängliga för varje specifik meddelandetyp.
• Känn till när transaktioner verkligen är asynkrona. Vissa arkitekturmönster beter sig asynkront från början till slut. Andra processer beter sig dock asynkront på klient- eller webbläsarsidan, men serialiserar begäranden på serversidan, som sedan är föremål för synkrona styrande begränsningar.
• För att bygga storskaliga utgående integreringar från Salesforce Platform, använd plattformshändelser och robust mellanprogramvara istället för anrop via asynkrona Apex. Eftersom det finns ett begränsat antal asynkrona trådar tillgängliga i plattformen har utgående integreringar via asynkrona Apex begränsad skalbarhet. Om din organisation har utgående integreringar som involverar stora mängder meddelanden, överskrider antalet tillgängliga trådar och har långa bearbetningstider kommer användning av asynkrona Apex oundvikligen att medföra förseningar.
• Se till att införliva övervakning vid användning av asynkron bearbetning. Med övervakning kan du upptäcka problem så tidigt som möjligt och åtgärda dem innan större prestandaincidenter inträffar.
• Ta hänsyn till händelser som kan orsaka extrem belastning. När du utformar asynkrona processer, se till att de på ett förutsägbart sätt kan hantera arbetsbelastningstoppar och -lullar. Tänk på hur din implementering hanterar oväntade händelser, som strömavbrott, och designskydd som minskar dataförlust eller funktionsförlust.

När du väljer ett tillvägagångssätt för asynkron bearbetning på serversidan, utvärdera först din organisations krav och tillgängliga resurser. Ditt mål är att välja ett tillvägagångssätt som minimerar implementerings- och underhållskostnader samtidigt som du säkerställer skalbarhet och minimerar sannolikheten för gränsbrott. Detta mål beror på de tekniska överväganden som beskrivs i nästa avsnitt, samt ditt teams sammansättning. Tänk till exempel på om du har Apex utvecklare i ditt team som kan underhålla din prokodlösning. Annars kan ett deklarativt tillvägagångssätt vara mer meningsfullt. Kom även ihåg att olika gränser kan gälla för olika verktyg.

Tänk på användningsfallet för en asynkron orderprocess i Salesforce. När en order sparas utlöses ett meddelande till ett externt lagerhanteringssystem med särskilda instruktioner för hur ett objekt ska paketeras och skickas. Användaren som placerar ordern behöver inte ett omedelbart svar från lagerhanteringssystemet, så begäran kan skickas asynkront. Den asynkrona bearbetningen låter användaren fortsätta sitt arbete utan fördröjningar.

Att tänka på vad gäller din arkitektur:

• Hur många samtidiga processer behövs?
• Hur kommer den samtidiga processen att interagera med varandra?
• Hur många SOQL-frågor kommer att köras inom varje process?
• Hur många DML-operationer kommer att utföras inom varje process?
• Hur länge kommer varje process att köras?
• Hur känsliga är processer för specifik timing?

Salesforce Platforms multitenantarkitektur isolerar och har samtidigt stöd för de varierande kraven hos många arrendatorer (organisationer). Alla asynkrona Apex metoder som täcks i denna guide körs inom samma asynkrona infrastruktur i Salesforce Platform. De använder ett ramverk för meddelandeköer som styrs av två primära tillämpningsmekanismer: flödeskontroll och rättvis användning.

Flödeskontrollen och mekanismerna för rättvis användning förhindrar att en enskild arrendator använder för många serverresurser och inte lämnar tillräckligt med resurser för de återstående arrendatorerna. Även om det är bra att förstå hur dessa mekanismer fungerar, bör din nyckelåtgärd vara att följa rekommenderade metoder för asynkron bearbetning, som de som beskrivs i nästa avsnitt, avsevärt minskar din sannolikhet att stöta på problem med dem.

Plattformens flödeskontrollmekanism förhindrar en organisation från att översvämma en given meddelandetyp, vilket konsumerar för många trådar och påverkar andra organisationer negativt. Innan ramverket lägger till nya poster i kön som är associerad med en meddelandetyp kontrollerar det de första flera tusen befintliga posterna i kön. Om majoriteten av befintliga poster är associerade med samma organisation och den organisationen redan har poster i medarbetartrådar flyttas de nyligen tillagda posterna längst bak i kön. Denna process kallas återkö. Omköer händer vanligtvis med API-processerna Batch Apex och Bulk eftersom de ofta infogar ett stort antal poster i sina köer samtidigt.

Plattformens mekanism för rättvis användning implementerar ett nivåbaserat system. Systemet säkerställer att varje organisation på Salesforce Platform får en rättvis del av bearbetningstiden för en given meddelandetyp, inklusive meddelandetyperna Framtida, Köbar och Batch. Om en organisation dominerar en given meddelandetyp under samma tid som andra organisationer väntar på att utföra arbete med samma meddelandetyp minskar algoritmen för rättvis användning antalet trådar som organisationen har tillgängliga för den specifika meddelandetypen.

En fördel med att använda asynkrona Apex metoder är att vissa styrande gränser, som till exempel gränser för SOQL-frågor och heapstorlek, är högre. Lita dock inte för mycket på dessa metoder. På grund av de begränsade resurser som allokeras till asynkron infrastruktur kan tung användning av Apex Future, Queueable och Batch orsaka bearbetningsfördröjningar som beror på begränsningar baserade på rättvis användning och flödeskontroll.

Utgående anrop som använder asynkrona Apex räknas mot gränsen för asynkrona Apex. Den dagliga gränsen är för närvarande 250 000 eller 200 gånger antalet tillämpliga användarlicenser, beroende på vilket som är störst. Denna gräns kan vara ett problem för användningsfall med hög volym. Om du överskrider gränsen kommer dina asynkrona Apex jobb och deras associerade utgående anrop att misslyckas.

Eftersom plattformen har ett begränsat antal tillgängliga asynkrona trådar har utgående integreringar via asynkrona Apex begränsad skalbarhet. Utgående integreringar med hög volym som överskrider antalet tillgängliga trådar kan ha långa bearbetningstider och leda till fördröjningar.

För användningsfall med hög volym, överväg dessa alternativa metoder. API-anrop med dessa metoder räknas mot den dagliga API-begärangränsen, som är betydligt högre än den dagliga asynkrona Apex. Dessa metoder är därför mer skalbara. Observera dock att det fortfarande finns fysiska begränsningar för antalet samtidiga begäranden som en CPU kan bearbeta.

• Schemalagd hämtning av mellanprogram. Undvik fördröjningar associerade med utgående integreringsjobb med hög volym genom att använda middleware för att hämta data schemalagt istället för att pusha dem via asynkron Apex. Middleware, som MuleSoft Anypoint Platform, kan använda inbyggd SOAP API eller REST API på ett synkront sätt så att få, om några, fördröjningar introduceras. Middleware kan även använda inbyggd Bulk API för stora datavolymer.

• Middleware Pull via Platform Event Notification. Istället för att placera asynkrona Apex i köerna Future, Queueable eller Batch för att utföra utgående integreringar kan du använda plattformshändelser. Plattformshändelsen kan antingen leverera den utgående informationen själv eller instruera ett middleware-verktyg att hämta den information som behövs via en inbyggd API och leverera den till sin slutdestination. Ingen av dessa metoder är föremål för de fördröjningar som asynkrona Apex är föremål för. Plattformshändelsegränser gäller dock fortfarande.

Med Queueable Apex kan du köra Apex processer som involverar omfattande databasoperationer eller externa webbtjänstanrop asynkront. För att använda Queueable Apex, implementera gränssnittet Köbar och lägg sedan till ett jobb i Apex jobbkö. Detta tillvägagångssätt säkerställer att det asynkrona Apex jobbet körs i bakgrunden i sin egen isolerade tråd och inte försenar utförandet av din huvudsakliga Apex logik. Varje köjobb körs när systemresurser blir tillgängliga.

Köbara Apex representerar utvecklingen av asynkrona Apex. Den erbjuder funktioner som inte är tillgängliga för Apex framtida metoder, inklusive:

• Job-ID: När du skickar in ett jobb genom att åberopa metoden System.enqueueJob returnerar metoden ID för det nya jobbet. Du kan använda detta ID för att identifiera ditt jobb. För att bevaka dess förlopp, se sidan Apex jobb i Salesforces inställningar eller fråga objektet AsyncApexJob.
• Stöd för icke-primitiva typer: Köbara klasser kan innehålla medlemsvariabler av icke-primitiva datatyper, som sObjects eller egna Apex typer.
• Stöd för jobbkedja: Du kan kedja ihop köjobb genom att starta ett andra jobb från ett pågående jobb. Denna teknik kan hjälpa dig hantera scenarion som involverar processberoenden.
• Maximal djupkontroll: Du kan konfigurera köjobb med ett maximalt stackdjup för att säkerställa att jobbkedjor inte får oväntad rekursion.
• Dedupliceringssignaturer: Köjobb ger en valfri signatur för att upptäcka och ta bort dubbletter av jobb.
• Konfigurerbar fördröjning: Du kan definiera en fördröjning på upp till 10 minuter innan det köbara jobbet körs.
• Transaktionsavslutare: Du kan bifoga en efteråtgärdssekvens till ett köbart jobb och vidta relevanta åtgärder baserat på dess resultat. Till exempel kan en transaktionsavslutare placera ett jobb i kö som misslyckades på grund av ett ohanterat undantag upp till fem gånger.

Salesforce använder ett köbaserat ramverk för att hantera asynkrona processer. Denna kö används för att balansera arbetsbelastningar för begäranden mellan organisationer. För att säkerställa att din organisation använder denna kö så effektivt som möjligt:

• Undvik att placera framtida metoder eller kömetoder direkt från åtgärder som skapas av stora volymer slutanvändares aktivitet eller integrerings-API-anrop. Detta tillvägagångssätt kan snabbt uttömma dagliga asynkrona Apex, vilket resulterar i allvarlig påverkan på verksamheten.
• Undvik att placera mer än en asynkron åtgärd i kö per synkron åtgärd. När flera asynkrona metoder placeras i kö från en enskild synkron åtgärd körs de asynkrona aktiviteterna ofta samtidigt och bidrar till radlåskonflikter och/eller timeoutfel för radlås.
• Undvik att lägga till ett stort antal framtida eller köbara metoder i den asynkrona kön.
• Se till att framtida och köbara metoder körs så snabbt som möjligt. Ju längre tid det tar att köra en framtida metod, desto troligare kommer begäranden bakom den i kön att försenas. För att säkerställa snabbt utförande av batchjobb, minimera anropstider för webbtjänster, finjustera sökfrågor som används i dina framtida metoder och optimera andra objektautomatiseringar, inklusive Processbyggarprocesser, arbetsflödesregler, flöden och Apex.
• Testa dina asynkrona metoder i stor skala. Använd en miljö som skapar det högsta antalet metoder som du förväntar dig att hantera. Detta test hjälper till att avgöra om du stöter på problem med prestanda eller gränser i din produktionsmiljö. Tänk även på påverkan på kumulativa dagliga gränser.
• Använd Batch Apex istället för framtida eller köbara metoder för att bearbeta ett stort antal poster. Batch Apex kan hantera komplexa, tidskrävande processer som körs mot tusentals poster och kan schemaläggas att köras utanför arbetstid när fler resurser är tillgängliga.

Använd schemalagd Apex för att köra vid en specificerad tidpunkt och med en upprepad frekvens som definieras av ett cronuttryck. Även om åtgärden att schemalägga Apex via cron-uttrycket är en asynkron process körs den underliggande koden synkront när jobbet startar. Schemalagd Apex är perfekt för dagliga eller veckovisa underhållsuppgifter.

• Du kan endast ha 100 schemalagda Apex jobb åt gången. För att undvika denna begränsning, överväg att använda ett schemautlöst flöde som åberopar Apex kod istället för att använda schemalagd Apex.
• Var extremt försiktig om du planerar att schemalägga en klass från en utlösare. Du måste kunna garantera att utlösaren inte lägger till fler schemalagda klasser än gränsen. Tänk särskilt på massuppdateringar av API, importguider, masspoständringar genom användargränssnittet och alla fall där mer än en post kan uppdateras åt gången.
• För engångsuppgifter som behöver schemaläggas upp till 10 minuter i framtiden, använd ett försenat köjobb. Detta tillvägagångssätt räknas inte mot gränsen på 100 schemalagda jobb.
• Schemalagd Apex körs i ett synkront sammanhang med synkrona gränser.
• Tänk på hur länge det schemalagda jobbet kommer att köras. Ett jobb som körs länge kan överlappa med starten av nästa schemalagda jobb.
• Salesforce schemalägger klassen för utförande vid den specificerade tidpunkten. Faktisk körning kan försenas baserat på tjänstens tillgänglighet. Jobb som är schemalagda att köras under nedtid för serviceunderhåll kommer att schemaläggas att köras efter att tjänsten kommer upp igen.
• Använd System.scheduleBatch för att schemalägga batchjobb istället för att ha ett schemalagt jobb med det enda syftet att köa ett batchjobb.

Historiskt sett har synkrona anrop som görs från en Apex metod som körs i ett synkront Apex transaktionssammanhang, som en Visualforce- eller Lightning-komponentkontroll, varit föremål för Apex samtidighetsgräns för begäranden som körts länge. Från och med utgåvan Winter ’19 räknas inte längre synkrona anrop som långa anrop. Även om Apex fortsättningar ursprungligen skapades som en lösning på synkrona anrop som resulterade i långa begäranden, ger de även några ytterligare fördelar.

• En enskild synkron åtgärd kan utföra upp till tre fortsättningsåtgärder. Den tidigare fortsättningen måste slutföras innan en ny fortsättningsåtgärd utförs.
• Varje fortsättningsåtgärd kan utföra upp till högst tre anrop, som utförs parallellt.
• När alla anrop som utförs av en fortsättningsåtgärd är slutförda åberopar plattformen fortsättningsanropsmetoden för att hantera resultaten.

Även om fortsättningar körs asynkront med avseende på den ursprungliga synkrona åtgärden finns det viktiga skillnader mellan Apex Continuations och andra asynkrona Apex tekniker som framtida metoder, Queueable eller Batch. Viktiga skillnader är:

• Fortsättningar köas inte på något sätt.
• Fortsättningar bidrar inte till den dagliga asynkrona Apex.
• Fortsättningar byter trådsammanhang på programservern från en tung Apex plattformstråd till en lätt tråd som endast utför anrop. För att utföra anrop som kan köras upp till 120 sekunder erbjuder fortsättningar betydande besparingar på programserverns minne.
• Ursprungligen kunde fortsättningar endast utföras från ett Visualforce JavaScript-motanrop. I utgåvan Summer '19 lades dock fortsättningar officiellt till i Lightning Component-ramverket, vilket eliminerade behovet av Visualforce.

Plattformshändelser är Salesforce Platforms implementering av en rent händelsedriven arkitektur. Mer information om komponenterna som är associerade med denna typ av arkitektur finns i Arkitektens guide till händelsedriven arkitektur.

Plattformshändelser och plattformshändelseutlösare/flöden är ofta bra alternativ till att köra asynkrona Apex. De är även ett bra sätt att åberopa bearbetning utanför plattformen. Du kan till exempel använda en kombination av händelsereläer för Amazon Web Services (AWS) och plattformshändelser för att åberopa serverlös beräkningsfunktionalitet i AWS Lambda. Arbete som utförs relativt snabbt och utan några anrop (vilket inte är möjligt från en plattformshändelseutlösare eller flöde) är en bra kandidat för en plattformshändelse/utlösare eller händelse/flödeskombination.

Händelserna som publiceras till bussen via publicering efter överlämnande levereras i ordning och kan massbearbetas av utlösaren eller flödet i ett separat synkront sammanhang. Sammanhanget är synkront och tillämpar alla synkrona styrande gränser. Välj plattformshändelseutlösare/flödessatsstorlek noggrant för att undvika att överskrida gränser.

• När händelser publiceras i händelsebussen är de tillgängliga för konsumenter. I händelseutlösare (Apex eller flöde) skickas dessa händelser till tillgängliga synkrona trådar på appnivån (en tråd per händelseutlösare/flöde). Observera att denna process inte har ett servicenivåavtal.
• När publiceringsåtgärder läggs till i kön lagras resultatet av köprocessen i objektet Database.SaveResult. Dessa poster indikerar endast om köoperationen lyckades eller inte. För att få slutresultatet av en händelse som publicerats via händelsebussen, implementera en Apex-publiceringscallback. Med denna ytterligare information kan du fatta beslut om ytterligare åtgärder, som att försöka publicera misslyckade händelser igen.
• Plattformshändelser har inte samma gränser som asynkrona Apex, men har sina egna guvernörsgränser. Om du stöter på problem med gränser kan du aktivera utökade händelseanvändningsmått för att avgöra om specifika händelser använder upp mer av dina allokeringar än du avsett. Om du behöver större genomströmning för händelseutlösare, överväg att använda parallella prenumerationer för att bearbeta händelser samtidigt istället för i en enda ström. Med parallella prenumerationer kan du skala Apex plattformshändelseutlösare för att hantera stora volymer händelser. Parallella prenumerationer är tillgängliga för egna plattformshändelser med hög volym men inte för standardhändelser eller ändringshändelser.
• Plattformshändelser har två alternativ för publiceringsbeteende:
  • Publicera direkt: Händelser publiceras omedelbart under transaktionen, innan den slutgiltiga databasen överlämnas. Händelser som publiceras på detta sätt garanteras inte att publiceras i ordning.
  • Publicera efter åtagande: Händelser publiceras när databastransaktionen har utförts. Händelser som publiceras på detta sätt garanteras att publiceras i ordning.

Det är bra att använda Publicera direkt för användningsfall som loggning, där du vill publicera loggningshändelsen oavsett om transaktionen lyckas och överlämnas, eller misslyckas och dras tillbaka. Det är möjligt att omedelbart publicera en plattformshändelse som konsumeras av en plattformshändelseutlösare. Plattformshändelseutlösaren tävlar sedan om ett radlås för databas med transaktionen som publicerade den. Gå igenom alla designer noggrant innan du publicerar plattformshändelser direkt för att säkerställa att du undviker detta scenario.

Asynkrona flöden ger alternativ med låg kod till asynkrona Apex. Precis som med andra typer av asynkron bearbetning körs de i bakgrunden när resurser är tillgängliga. Asynkrona flöden har inte heller några servicenivåavtal och kan ha oförutsägbara väntetider.

Schemalagda vägar är cron-utlösarbaserade för att köras vid en specifik tidpunkt. De körs när poster skapas, uppdateras eller tas bort och ger dig detaljerad kontroll över när automatiseringen ska köras i förhållande till poständringen. (Exempel: skicka ett e-postmeddelande till en användare en timme innan en uppgift ska utföras.) Till skillnad från Apex framtida metoder, som är begränsade till högst 50 metoder i kö i en synkron transaktion, har schemalagda flödesåtgärder för närvarande inte en högsta kögräns per transaktion. Det finns dock en konfiguration för batchstorlek inom definitionen av den schemalagda vägen som tillåter viss kontroll över hur många poster som hanteras av flödet för den schemalagda vägen.

Asynkrona vägar kan läggas till i postutlösta flöden. De körs i bakgrunden och försenar inte utförandet av transaktionen som ursprungligen utlöste flödet. Du kan använda en asynkron sökväg för att utföra en långvarig operation eller en operation som du vill köra på sin egen tid. Asynkrona vägar kan hjälpa till att undvika blandade DML-fel som uppstår när du behöver uppdatera ett värde på en relaterad post som inte är en del av posten som utlöste flödet.

Obs! Utgående meddelanden är en äldre funktion och plattformshändelser (som beskrivs i föregående avsnitt) är ett modernare tillvägagångssätt och erbjuder större flexibilitet. Plattformshändelser är Salesforces rekommenderade mönster för händelsedriven integrering.

Utgående meddelanden ger ett sätt att asynkront kommunicera utgående via SOAP API. När den konfigureras i Salesforce skapar definitionen av utgående meddelande en SOAP WSDL som kan konsumeras av en extern webbtjänstleverantör. Utgående meddelanden kan utlösas från arbetsflödesregler, processer i Processbyggaren eller flödesutlösare i Lightning efter sparande. Ett utgående SOAP-meddelande kan innehålla upp till 100 notiser. Varje notis innehåller objekt-ID och en referens till associerade sObject-data. Om informationen i det underliggande objektet ändras efter att notisen har köats men innan den skickas levereras endast de senaste data och inte de mellanliggande ändringarna.

När en lyssnare av utgående meddelande (webbtjänsten som du konfigurerade med den genererade WSDL) får ett meddelande använder den den inkluderade sessions-ID-informationen för att anropa Lightning Platform API för att uppdatera posten i Salesforce som utlöste det utgående meddelandet.

• Utgående meddelanden hanteras inte via den köbaserade asynkrona infrastrukturen i Salesforce som kör aktiviteter som framtida metoder, Queueable Apex, Batch Apex, Bulk API och så vidare. Istället lagras poster lokalt i objektet OutboundMessage. Meddelanden skickas ut och försöks igen via en lokal schemalagd bakgrundsprocess.
• Meddelanden skickas inte synkront när åtgärden för utgående meddelande utförs av den inledande automatiseringen (till exempel en flödesutlösare efter sparande). Istället stannar de i objektet OutboundMessage tills de har skickats eller tills de släpps efter 24 timmar av misslyckad leverans.
• För att undvika en oändlig loop av utgående meddelanden, se till att användaren som uppdaterar objekten inte har behörigheten Skicka utgående meddelanden.

E-post-till-kundcase fungerar normalt på ett synkront sätt. Det finns en gräns på fyra synkrona trådar för att hantera inkommande e-post-till-kundcase-förfrågningar. Hanterarens synkrona form upprätthåller en anslutning till den inkommande Salesforce-e-postserver (MTA) som tar emot e-postmeddelandet. Det finns dock orsaker till att E-post-till-kundcase kan hanteras asynkront:

• E-post-till-kundcase är föremål för trådgränser, specifikt 10 totala hanterartrådar per appserver: fyra trådar för synkron bearbetning och sex trådar för asynkron bearbetning.
• Om en synkron e-posthanterare överskrider 15 sekunders körningstid markeras den specifika e-posttjänstadressen som asynkron under en period på 30 minuter. Efterföljande hanterarbegäranden för den serviceadressen resulterar i ett meddelande som placeras i kö för MessageTypeName = MAILCATCHER_EMAIL_TO_CASE, tillsammans med en hänvisning till e-postmeddelandets innehåll.
• Om en synkron tråd redan används för en specifik organisation och serviceadress placeras ytterligare begäranden för den serviceadressen i asynkron kö.
• Om ett synkront hanterat e-postmeddelande stöter på ett fel, till exempel en timeout för radlås, sparas begäran och placeras i asynkron kö.
• Om inga synkrona hanterartrådar är tillgängliga placeras begäran i asynkron kö.

• Det finns ett dedupliceringsalternativ när du konfigurerar E-post-till-kundcase, men det avduplicerar inte bilagor förrän e-postmeddelandet har bearbetats. Denna deduplicering sparar utrymme i databasen, men minskar inte bearbetningstider för e-postmeddelanden. Du kan dock förbättra prestandan genom att implementera en egen Apex E-post-till-kundcase-hanterare för meddelandebearbetning. Denna implementering påverkar inga styrande gränser, men ger hanteraren åtkomst till e-postmeddelandet och alla dess bilagor innan något skickas till databasen. Denna åtkomst låter dig beräkna kontrollsummor för alla inkluderade bilagor och ignorera alla som du tycker är onödiga, inklusive dubbletter, välkända signaturbilder eller oönskade filtyper.
• Att skicka e-postbilagor till Salesforce Files ansvarar för den största delen av bearbetningstiden för e-postmeddelanden. När svar till eller från kontakten ökar och e-postkedjan blir större blir bearbetningstiden för varje e-postmeddelande också större. Om e-postalternativet "Svara med endast nytt innehåll" inte väljs kommer e-postkedjor att växa med varje svar. Därför rekommenderar vi att du använder en Apex E-post-till-kundcase-hanterare med logik som implementerar deduplicering av bilagor vid tiden för bearbetningen.
• Trots att Apex åberopas som en del av hanteringen undantas E-post-till-kundcase-hanterare från den samtidiga Apex.

För att bearbeta stora mängder poster asynkront, överväg att använda en av dessa metoder.

Du kan använda Batch Apex för att bygga komplexa processer som tar lång tid att köra och som involverar tusentals poster. Batch Apex fungerar genom att dela upp din postuppsättning och bearbeta den i hanterbara delar. Som ett exempel kan du bygga en arkiveringslösning som körs varje natt och lägger till poster som är äldre än ett visst datum i ett arkiv. Eller så kan du bygga en datarensning som tittar på alla konton och säljprojekt varje natt och utför nödvändiga uppdateringar baserat på en uppsättning fördefinierade kriterier.

• Batch Apex är bäst på att bearbeta stora mängder data eftersom asynkrona Apex har högre gränser än synkrona Apex. Batch Apex presterar även mer effektivt när det bearbetar fler objekt per sats eftersom det använder massoperationer som medför mindre overhead från köhantering. För att undvika att utlösa flödeskontrollmekanismen via kööversvämning och undvika att uttömma den dagliga asynkrona Apex, skapa därför inte satser med små omfång eller som har snabba bearbetningstider.
• Undvik att köa batchjobb direkt från åtgärder som skapas av stora volymer slutanvändares aktivitet eller integrerings-API-anrop. Detta tillvägagångssätt kan snabbt uttömma flexkön. Om du planerar att åberopa ett batchjobb från en utlösare måste du garantera att utlösaren inte lägger till fler batchjobb än gränsen.
• Batch Apex är begränsat till högst fem samtidiga trådar, vilket begränsar dess genomströmning mycket mer än framtida metoder eller Queueable Apex.
• Batchjobb som involverar stora mängder data bör helst schemaläggas för körning utanför kontorstid för att frigöra resurser för processer som kräver svar i realtid eller nästan i realtid.
• När du anropar System.scheduleBatch schemalägger plattformen ditt jobb för utförande vid den tidpunkt du specificerar. Faktisk körning inträffar på eller efter denna tidpunkt, beroende på tjänstens tillgänglighet.
• Schemaläggaren körs i systemsammanhang. Alla klasser körs, oavsett om användaren som schemalade utförandet har behörighet att köra klassen eller inte.
• Alla schemalagda Apex gränser gäller för batchjobb som schemaläggs med System.scheduleBatch. Efter att batchjobbet har placerats i kö (med status Väntande eller Köad) gäller alla gränser för batchjobb och jobbet räknas inte längre mot schemalagda Apex.
• För ett batchjobb med ett återkommande schema, tänk på det korrekta beteendet om det tidigare jobbet fortfarande körs när det nya jobbet börjar köras.
• Batchjobb i kö från synkrona Apex transaktioner använder flexkön. Flexkön är begränsad till högst 100 objekt åt gången. Om en transaktion försöker lägga till fler poster skapar plattformen fel och skickar inte in batchjobbet.
• Anrop och andra icke-transaktionella operationer från batchjobb måste följa idempotenta designöverväganden. Batchjobb som köas innan en nedtid för Salesforces serviceunderhåll kvarstår i kön. Efter att servicenedtid har upphört och systemresurser är tillgängliga utförs de köade batchjobben. Om ett batchjobb körs när nedtid inträffar dras batchkörningen tillbaka och startas om efter att tjänsten har återställts. Eftersom utförandemetoder därför kan köras flera gånger kan alla icke-transaktionella operationer, som anrop, testas igen.
• Överväg att konfigurera batchjobbet för att höja BatchApexErrorEvent-händelser till att hantera fel- och undantagsscenarion.

Ett schemautlöst flöde är ett flöde som är schemalagt att köras vid en specificerad tidpunkt och med upprepad frekvens (dagligen, veckovis eller en gång) för att utföra åtgärder för en sats med poster. (Exempel: uppdatera ett fält i samtliga fall med statusen "Öppen" klockan 02:00 varje natt.) Schemalagda flöden körs via cron-utlösarmekanismen och massbehandlas.

• Ett schemautlöst flöde kör 200 poster per åberopning, men kommer att köras med flera samtidiga trådar om fler än 200 poster finns.
• Schemautlösta flöden utförs i ett synkront sammanhang med synkrona gränser.
• Det finns för närvarande inget sätt att styra antalet poster som bearbetas per schemalagd flödesåberopning. Om körningen är för mer än 200 poster finns det en verklig risk för samtidiga Apex.

Bulk API baseras på REST-principer och är optimerat för att arbeta med stora datauppsättningar. Du kan använda den för att infoga, uppdatera, infoga, fråga eller ta bort många poster asynkront och bearbeta resultaten senare. Salesforce Platform bearbetar begäran i bakgrunden. SOAP API och REST API använder istället synkrona begäranden och är optimerade för klientprogram i realtid som uppdaterar några poster åt gången. Du kan använda båda dessa API:n för att bearbeta många poster, men när datauppsättningarna innehåller hundratusentals poster är de mindre praktiska. Bulk API:s asynkrona ramverk är utformat för att göra det enkelt och effektivt att bearbeta data från några tusen till miljoner poster.

Det enklaste sättet att använda Bulk API är att aktivera det för bearbetning av poster i Data Loader med hjälp av CSV-filer. Med Data Loader behöver du inte skriva din egen klientapp. Ibland kräver dock unika krav att man skriver en egen app.

Det finns två Bulk API:n tillgängliga inom Salesforce Platform.

• Bulk API 2.0 är den nyare API. Det ger ett effektivt och enklare arbetsflöde och är fokus för förbättringar.
• Det ursprungliga Bulk API stöds fortfarande fullt ut, men utökas inte längre. Vi rekommenderar att du använder Bulk API 2.0 där det är möjligt.

Mer information om API-gränser finns i Bulk API-gränser och Bulk API 2.0-gränser.

Se denna guide när du bygger eller överväger asynkron bearbetning på Salesforce Platform. Det är alltid en bra idé att förstå hela omfattningen av alternativ som är tillgängliga för dig, och hur de kan passa med ditt specifika användningsfall. Se till att noggrant utvärdera ditt nuvarande landskap innan du gör ändringar av någon av dina befintliga arkitekturer, särskilt om din nuvarande lösning fungerar bra.