Asynkron behandling øger skalerbarheden ved at tillade højere grænser pr. kontekst. Asynkrone anmodninger udføres i deres egne tråde i baggrunden, så brugere kan fortsætte med at udføre arbejde på klientsiden, når de asynkrone opgaver udføres i baggrunden.

Salesforce Lightning Platform tilbyder en række asynkrone teknologier, der kan bruges til at løse en given anvendelsessituation. Hver teknologi har fordele og begrænsninger, som du skal overveje, når du vælger en tilgang for hver anvendelsessituation.

Når du vælger en teknologi til implementering, er der tre vigtige overvejelser, du skal huske på:

1. Asynkron behandling er ikke den bedste tilgang til alle problemer. Det kan være fristende at tænke på enhver proces, der ikke direkte kræver brugerinteraktion som en god kandidat til asynkron behandling, men der er nogle ulemper. Først har asynkrone processer ingen SLA, hvilket betyder, at der ikke er nogen garanti for, at en asynkron proces fuldføres inden for en angivet mængde tid. For det andet er der ingen garanti for ensartet svarforsinkelse. Hvis en asynkron proces fuldføres inden for en bestemt mængde tid, kan det tage en anden mængde tid at fuldføre en efterfølgende proces. Derfor, selv hvis en bruger ikke venter direkte på et svar, er asynkron behandling muligvis ikke korrekt for dit scenarie, hvis du har efterfølgende processer, der afhænger af et svar, eller hvis du er bekymret for, at overdreven svartider kan medføre, at dine data bliver ude af synkronisering med dataene i et eksternt system.
2. Der er forskellige måder at behandle asynkrone anmodninger på Salesforce Platform, så sørg for at vælge den bedste tilgang. Teknologier, der understøtter asynkron behandling på Salesforce Platform, fungerer anderledes "under skærmen", og nogle er designet til meget specifikke anvendelsessituationer.
3. Hvis en teknologi er asynkron på klientsiden, betyder det ikke nødvendigvis, at al end-to-end-behandling udføres parallelt. Afhængig af de valg, du foretager, kan klientens meddelelser nogle gange stadig blive serialiseret på serversiden.

Hvis du bruger de forkerte teknologier eller de forkerte kombinationer af teknologier til et job, kan der forekomme utilsigtede konsekvenser, der annullerer fordelene ved asynkron behandling. Denne vejledning indeholder forklaringer og anbefalinger samt potentielle ulemper og anti-mønstre for forskellige asynkrone anvendelsessituationer sammen med grundlaget for disse anbefalinger. Den giver også indsigt i, hvordan forskellige asynkrone implementeringsteknikker fungerer og er reguleret på Salesforce Platform.

Hvis du beslutter, hvilken teknologi du vil bruge, findes der en fokuseret Asynkron behandlingsbeslutningsvejledning, der giver en hurtig tilknytning af typiske anvendelsessituationer til den bedst egnede teknologi.

Salesforce Lightning Platform er en omfattende, AI-drevet platform, der forener medarbejdere, autonome AI-agenter, firmadata og applikationer i et enkelt, betroet system for at forbedre produktiviteten og kundeoplevelsen. Den aktiverer oprettelsen af en "agentvirksomhed" ved at tilslutte Customer 360, Data Cloud og Slack til end-to-end-automatisering.

Dette dokument dækker ikke teknologier i andre økosystemer, f.eks. MuleSoft, Informatica, Commerce Cloud, Tableau og Marketing Cloud.

Bemærk, at denne vejledning udelukkende fokuserer på asynkron behandling i Salesforce Lightning Platform. Hvis du leder efter oplysninger om asynkrone integrationsmønstre, kan du se begivenhedsstyret arkitektur.

• Før du bruger asynkron behandling, skal du sørge for, at dine anvendelsessituationer passer til mønsteret. Asynkrone mønstre har ingen servicelaftale, er underlagt flere styringsmekanismer, kan have kapacitetsgrænser defineret baseret på licens og kan forårsage behandlingsforsinkelser på grund af den begrænsede karakter af de ressourcer, der er tildelt til asynkron infrastruktur i Salesforce Platform. Tag disse begrænsninger alvorligt i betragtning, når du bruger asynkron behandling i scenarier, hvor en bruger kræver et svar fra systemet, før vedkommende kan fortsætte med sit arbejde.
• Asynkron behandling med Salesforce er ikke en løsning på grænseløse skaleringsbehov. Salesforce Platform skaleres ikke uendeligt, og asynkrone mønstre er stadig underlagt begrænsninger. Asynkron behandling bruger tråde, som indeholder de kontekstoplysninger, som en CPU har brug for for at køre en stream af instruktioner. Tråde kan køre parallelt. Antallet af tilgængelige tråde i enhver CPU er begrænset, så platformen har mekanismer til at sikre, at dens tilgængelige tråde bruges så effektivt som muligt. Platformens forløbskontrolmekanisme forhindrer organisationer i at forbruge for mange tråde og påvirke andre organisationer negativt. Platformens fair-use algoritme styrer antallet af tråde, som en organisation har tilgængelige for hver bestemt meddelelsestype.
• Ved, hvornår transaktioner er virkelig asynkrone. Nogle arkitektoniske mønstre optræder asynkront end-to-end. Men andre processer optræder asynkront på klientsiden eller browser-siden, men serialiserer anmodninger på serversiden, som derefter er underlagt synkrone styringsbegrænsninger.
• Hvis du vil opbygge udgående integrationer i stor skala fra Salesforce Platform, skal du bruge platformsbegivenheder og robust middleware i stedet for udkald via asynkron Apex. Da der er et begrænset antal asynkrone tråde tilgængelige på platformen, har udgående integrationer via asynkron Apex begrænset skalerbarhed. Hvis din organisation har udgående integrationer, der involverer store mængder meddelelser, overstiger antallet af tilgængelige tråde og har lange behandlingstider, vil brug af asynkron Apex uundgåeligt indføre forsinkelser.
• Sørg for at indarbejde overvågning, når der bruges asynkron behandling. Med overvågning kan du registrere problemer så tidligt som muligt og rette dem, før der forekommer større ydeevnehændelser.
• Tag højde for begivenheder, der kan forårsage ekstreme belastninger. Når du designer asynkrone processer, skal du sørge for, at de forudsigeligt kan håndtere spidsbelastning og udløb. Overvej, hvordan din implementering håndterer uventede begivenheder, f.eks. strømafbrydelser, og design sikkerhedsforanstaltninger, der reducerer tab af data eller tab af funktionalitet.

Når du vælger en tilgang til asynkron behandling på serversiden, skal du først evaluere din organisations krav og tilgængelige ressourcer. Dit mål er at vælge en tilgang, der minimerer implementerings- og vedligeholdelsesomkostninger, mens du stadig sikrer skalerbarhed og minimerer din sandsynlighed for grænseovertrædelser. Dette mål afhænger af de tekniske overvejelser, der er skitseret i de næste afsnit, samt udformningen af dit team. Overvej f.eks., om du har Apex i dit team, der kan vedligeholde din pro-code-løsning. Ellers kan en deklarativ tilgang give mere mening. Husk også på, at forskellige sæt af grænser kan gælde for forskellige værktøjer.

Overvej anvendelsessituationen for en asynkron bestillingsproces i Salesforce. Når en bestilling gemmes, udløser den en meddelelse til et eksternt lagerstyringssystem med særlige instruktioner om, hvordan en vare pakkes og sendes. Den bruger, der afgiver bestillingen, behøver ikke et øjeblikkeligt svar fra lagerstyringssystemet, så anmodningen kan sendes asynkront. Den asynkrone behandling gør det muligt for brugeren at fortsætte sit arbejde uden forsinkelser.

Overvejelser i forbindelse med din arkitektur:

• Hvor mange samtidige processer er der brug for?
• Hvordan vil den samtidige proces interagere med hinanden?
• Hvor mange SOQL-forespørgsler, der skal afvikles i hver proces?
• Hvor mange DML-handlinger, der skal udføres i hver proces?
• Hvor længe skal hver proces køre?
• Hvor følsomme er processer til specifikke tidsangivelser?

Salesforce Platforms flertællerarkitektur isolerer og understøtter samtidig de forskellige krav hos mange lejere (organisationer). Alle asynkrone Apex, der er dækket i denne vejledning, køres i den samme asynkrone infrastruktur i Salesforce Platform. De bruger en meddelelseskøstruktur, der styres af to primære håndhævelsesmekanismer: forløbskontrol og rimelig anvendelse.

Forløbskontrollen og mekanismerne for rimelig anvendelse forhindrer en enkelt lejer i at bruge for mange serviceressourcer og ikke efterlade nok ressourcer til de resterende lejere. Selvom det er nyttigt at forstå, hvordan disse mekanismer fungerer, bør dit nøgleemne være, at det at følge de bedste fremgangsmåder for asynkron behandling, f.eks. dem, der er skitseret i de næste afsnit, reducerer din sandsynlighed for at løbe ind i problemer med dem betydeligt.

Platformens forløbskontrolmekanisme forhindrer en organisation i at oversvømme en bestemt meddelelsestype, hvilket forbruger for mange tråde og påvirker andre organisationer negativt. Før strukturen føjer nye poster til den kø, der er tilknyttet en meddelelsestype, kontrollerer den de første flere tusinde eksisterende poster i køen. Hvis størstedelen af eksisterende poster er tilknyttet den samme organisation, og denne organisation allerede har også poster i medarbejdertråde, flyttes de netop tilføjede poster til bunden af køen. Denne proces kaldes genopfyldning. Genoprettelse sker typisk for Apex og masse-API-processer, da de ofte indsætter et stort antal poster i deres køer samtidigt.

Platformens rimelige anvendelsesmekanisme implementerer et niveaubaseret system. Systemet sikrer, at hver organisation på Salesforce Platform får en rimelig del af behandlingstiden for en angivet meddelelsestype, herunder meddelelsestyperne Fremtid, Kø og Batch. Hvis en organisation dominerer en given meddelelsestype på samme tid, som andre organisationer venter på at udføre arbejde på den samme meddelelsestype, reducerer algoritmen for rimelig anvendelse antallet af tråde, som organisationen har tilgængelige for den pågældende meddelelsestype.

En fordel ved at bruge asynkrone Apex er, at nogle styringsbegrænsninger, f.eks. SOQL-forespørgselsgrænser og begrænsninger for heapstørrelse, er højere. Men afhæng ikke for meget af disse metoder. På grund af de begrænsede ressourcer, der er tildelt til asynkron infrastruktur, kan kraftig brug af Future, Kø og Batch Apex medføre forsinkelser i behandlingen, der skyldes begrænsninger baseret på rimelig anvendelse og forløbskontrol.

Udgående udkald, der bruger asynkron Apex, tæller med i den asynkrone Apex. Den daglige grænse er aktuelt 250.000 eller 200 gange antallet af gældende brugerlicenser, afhængig af hvad der er størst. Denne grænse kan være et problem for højvolumen anvendelsessituationer. Hvis du overskrider grænsen, vil dine asynkrone Apex og deres tilknyttede udgående udkald mislykkes.

Desuden har udgående integrationer via asynkron Apex begrænset skalerbarhed, da platformen har et begrænset antal asynkrone tråde til rådighed. Alle højvolumen udgående integrationer, der overstiger antallet af tilgængelige tråde, kan have lange behandlingstider og føre til forsinkelser.

For højvolumen anvendelsessituationer kan du overveje disse alternative tilgange. API-kald med disse tilgange tæller med i den daglige API-anmodningsgrænse, som er væsentligt højere end den daglige asynkrone Apex. Således er disse tilgange mere skalerbare. Bemærk dog, at der stadig er fysiske begrænsninger på antallet af samtidige anmodninger, som enhver CPU kan behandle.

• Middleware Planlagt Pull. Undgå forsinkelser i forbindelse med højvolumen udgående integrationsjob ved at bruge middleware til at hente data på en planlagt basis i stedet for at overføre dem via asynkron Apex. Mellemware, f.eks. MuleSoft Anypoint Platform, kan bruge indbygget SOAP API eller REST API på en synkron måde, så der introduceres få, hvis nogen, forsinkelser. Mellemware kan også bruge den oprindelige Bulk API til store datamængder.

• Middleware Pull via platformsbegivenhedsadvisering. I stedet for at indsamle Asynkron Apex Future, Queueable eller Batch for at udføre udgående integrationer, kan du bruge platformsbegivenheder. Platformsbegivenheden kan enten levere de udgående oplysninger i sig selv eller instruere et middleware-værktøj i at hente de krævede oplysninger via en oprindelig API og levere dem til dens endelige destination. Ingen af disse tilgange er underlagt de forsinkelser, som asynkron Apex er underlagt. Men platformsbegivenhedsgrænser gælder stadig.

Med Apex, der kan sættes i kø, kan du køre Apex, der involverer omfattende databasehandlinger eller eksterne webtjenesteudkald asynkront. Hvis du vil bruge Apex, der kan køres, skal du implementere køgrænsefladen og derefter føje et job til Apex-jobkøen. Denne tilgang sikrer, at det asynkrone Apex kører i baggrunden i sin egen isolerede tråd og ikke forsinker kørslen af din Apex. Hvert job i kø kø køres, når der bliver tilgængelige systemressourcer.

Apex i kø repræsenterer udviklingen af asynkron Apex. Den tilbyder funktioner, der ikke er tilgængelige for Apex fremtidige metoder, herunder:

• Job-id'er: Når du indsender et job ved at kalde System.enqueueJob-metoden, returnerer metoden id'et for det nye job. Du kan bruge dette id til at identificere dit job. Hvis du vil overvåge statussen, kan du se siden Apex i Opsætning i Salesforce eller forespørge på objektet AsyncApexJob.
• Støtte til ikke-primitive typer: Køklasser kan indeholde medlemsvariabler af ikke-primitive datatyper, f.eks. sObjects eller tilpassede Apex
• Støtte til jobkædning: Du kan sammenkæde job, der kan sættes i kø, ved at starte et andet job fra et kørende job. Denne teknik kan hjælpe dig med at håndtere scenarier, der involverer procesafhængigheder.
• Maksimal dybde kontrol: Du kan konfigurere job, der kan sættes i kø med en maksimal stakdybde for at sikre, at kæder af job ikke ender med uventet rekursion.
• Deduplikeringssignaturer: Job, der kan sættes i kø, giver en valgfri signatur til at registrere og fjerne dubletjob.
• Konfigurerbar forsinkelse: Du kan definere en forsinkelse på op til 10 minutter, før jobbet i kø udføres.
• Transaktionsfinalister: Du kan vedhæfte en efterhandlingssekvens til et job, der kan sættes i kø, og udføre relevante handlinger baseret på dets resultat. En transaktionsafslutter kan f.eks. sætte et job i kø, der mislykkedes på grund af en ikke-håndteret undtagelse, i kø op til fem gange.

Salesforce bruger en købaseret struktur til at håndtere asynkrone processer. Denne kø bruges til at afbalancere anmodningsarbejdsbelastninger på tværs af organisationer. Hvis du vil sikre, at din organisation bruger denne kø så effektivt som muligt:

• Undgå at sætte fremtidige eller i kø-metoder i kø direkte fra handlinger, der er genereret af store mængder slutbrugeraktivitet eller integrations-API-kald. Denne tilgang kan hurtigt udnytte daglige asynkrone Apex, hvilket resulterer i alvorlige forretningseffekter.
• Undgå at sætte mere end en asynkron handling i kø pr. synkron handling. Når flere asynkrone metoder sættes sammen fra en enkelt synkron handling, udføres de asynkrone aktiviteter ofte på samme tid og bidrager til tidsudløbsfejl for rækkespærring og/eller rækkespærring.
• Undgå at føje et stort antal fremtidige eller i kø-metoder til den asynkrone kø.
• Sørg for, at fremtidige metoder og metoder, der kan køres, køres så hurtigt som muligt. Jo længere tid det tager at eksekvere en fremtidig metode, desto mere sandsynligt vil anmodninger bag den i køen blive forsinket. Hvis du vil sikre hurtig kørsel af batchjob, skal du minimere webserviceudkaldstider, justere forespørgsler, der bruges i dine fremtidige metoder, og optimere eventuelle andre objektautomatiseringer, herunder Proceskonstruktør-processer, arbejdsflowregler, forløb og Apex.
• Test dine asynkrone metoder på skala. Brug et miljø, der genererer det maksimale antal metoder, som du forventer at håndtere. Denne test hjælper med at bestemme, om du vil støde på problemer med ydeevne eller begrænsninger i dit produktionsmiljø. Overvej også påvirkningen af akkumulerede daglige grænser.
• Brug Batch Apex i stedet for fremtidige metoder eller Kø-metoder til at behandle et stort antal registreringer. Batch Apex kan håndtere komplekse, langvarige processer, der køres mod tusindvis af registreringer, og kan planlægges til at køre på fridage, når der er flere ressourcer tilgængelige.

Brug planlagt Apex til at køre på et angivet tidspunkt og med en gentaget frekvens som defineret af et Cron-udtryk. Selvom planlægning af Apex via Cron-udtrykket er en asynkron proces, udføres den underliggende kode synkront, når jobbet starter. Planlagt Apex er ideel til daglige eller ugentlige vedligeholdelsesopgaver.

• Du kan kun have 100 planlagte Apex ad gangen. Hvis du vil undgå denne begrænsning, kan du overveje at bruge et planlægningsudløst forløb, der kalder Apex i stedet for at bruge planlagt Apex
• Brug ekstrem forsigtighed, hvis du planlægger at planlægge en klasse fra en udløser. Du skal kunne garantere, at udløseren ikke tilføjer flere planlagte klasser end grænsen. Overvej især API-masseopdateringer, importguider, masseregistreringsændringer gennem brugergrænsefladen og alle situationer, hvor der kan opdateres mere end en registrering ad gangen.
• For engangsopgaver, der skal planlægges op til 10 minutter i fremtiden, skal du bruge et forsinket job, der kan sættes i kø. Denne tilgang tæller ikke med i grænsen på 100 planlagte job.
• Planlagt Apex udføres i en synkron kontekst med synkrone grænser.
• Overvej, hvor længe det planlagte job skal udføres. Et langt kørende job kan overlappe starten af det næste planlagte job.
• Salesforce planlægger klassen til kørsel på det angivne tidspunkt. Faktisk kørsel kan blive forsinket baseret på tilgængelighed af tjenester. Job, der er planlagt til at køre under nedetid for vedligeholdelse, vil blive planlagt til at køre, når tjenesten er tilbage.
• Brug System.scheduleBatch til at planlægge batchjob i stedet for at have et planlagt job med det eneste formål at oprette et batchjob.

Historisk har synkrone udkald, der er foretaget fra en Apex-metode, der kører i en synkron Apex-transaktionskontekst, f.eks. en Visualforce-controller eller en Lightning-komponentcontroller, været underlagt Apex-samtidighedsgrænsen for langvarige anmodninger. Fra og med Winter '19 tælles synkrone udkald ikke længere som kørende længe. Selvom Apex til en start blev oprettet som en løsning på synkrone udkald, der resulterede i længe kørende anmodninger, giver de også nogle yderligere fordele.

• En enkelt synkron handling kan udføre op til tre fortsættelseshandlinger. Den foregående fortsættelse skal være fuldført, før der udføres en ny fortsættelseshandling.
• Hver fortsættelseshandling kan maksimalt udføre tre udkald, som udføres parallelt.
• Når alle udkald, der er udført af en fortsættelseshandling, er fuldført, kalder platformen fortsættelsestilbagekaldsmetoden for at håndtere resultaterne.

Selvom fortsættelser udføres asynkront i forhold til den oprindelige synkrone handling, er der vigtige forskelle mellem Apex og andre asynkrone Apex, f.eks. fremtidige metoder, Kø eller Batch. Nøgleforskelle er:

• Fortsætninger sættes ikke i kø på nogen måde.
• Fortsættelser bidrager ikke til den daglige grænse for asynkron Apex.
• Fortsætninger skifter trådkontekst på applikationsserveren fra en tung Apex Platform-tråd til en lettråd, der kun udfører udkald. Med henblik på udførelse af udkald, der kan køre op til 120 sekunder, giver fortsættelser betydelige besparelser på applikationsserverhukommelsen.
• Oprindeligt kunne fortsættelser kun udføres fra et Visualforce JavaScript-fjernkald. I Summer ’19 blev der dog officielt tilføjet fortsættelser til Lightning Component-strukturen, hvilket eliminerede behovet for Visualforce.

Platformsbegivenheder er Salesforce Platforms implementering af en rent begivenhedsstyret arkitektur. Du kan finde flere detaljer om de komponenter, der er tilknyttet denne type arkitektur i Arkitektens vejledning til begivenhedsstyret arkitektur.

Platformsbegivenheder og platformsbegivenhedsudløsere/forløb er ofte gode alternativer til kørsel af asynkron Apex. De er også en god måde til at kalde off-platform-behandling. Du kan f.eks. bruge en kombination af Amazon Web Services-begivenhedsrelæer og platformsbegivenheder til at kalde serverløs beregningsfunktionalitet i AWS Lambda. Arbejde, der udføres relativt hurtigt og uden nogen udkald (som ikke er muligt fra en platformsbegivenhedsudløser eller et forløb), er en god kandidat til en platformsbegivenheds-/udløser- eller begivenheds-/forløbskombination.

Begivenhederne udgivet til bussen via udgiv efter commit leveres i rækkefølge og kan massebehandles af udløseren eller forløbet i en separat synkron kontekst. Konteksten er synkron og håndhæver alle synkrone styringsbegrænsninger. Vælg omhyggeligt størrelsen på platformsbegivenhedsudløseren/forløbets batch for at undgå at nå grænserne.

• Når begivenheder udgives på begivenhedsbussen, er de tilgængelige for forbrugere. I tilfælde af begivenhedsudløsere (Apex eller forløb) sendes disse begivenheder til tilgængelige synkrone tråde på appniveauet (en tråd pr. begivenhedsudløser/forløb). Bemærk, at denne proces ikke har en SLA.
• Når udgivelseshandlinger føjes til køen, gemmes resultatet af køprocessen i Database.SaveResult-objektet. Disse oplysninger angiver kun, om køhandlingen lykkedes eller ej. Hvis du ønsker at få det endelige resultat af en begivenhed, der er udgivet gennem begivenhedsbussen, skal du implementere et Apex-udgivelseskald tilbage. Med disse yderligere oplysninger kan du træffe beslutninger om yderligere handlinger, f.eks. forsøg på at udgive mislykkede begivenheder igen.
• Selvom platformsbegivenheder ikke er underlagt de samme begrænsninger som asynkron Apex, har de deres egne sæt af styringsbegrænsninger. Hvis du støder på problemer med begrænsninger, kan du aktivere forbedrede begivenhedsanvendelsesmetrikker for at bestemme, om specifikke begivenheder bruger mere af dine tildelinger end forventet. Hvis du har brug for større kapacitet på begivenhedsudløsere, kan du overveje at bruge parallelle abonnementer til at behandle begivenheder samtidigt i stedet for i en enkelt stream. Med parallelle abonnementer kan du skalere Apex platformsbegivenhedsudløsere til at håndtere store mængder af begivenheder. Parallelle abonnementer er tilgængelige for tilpassede højvolumen platformsbegivenheder, men ikke for standardbegivenheder eller ændringsbegivenheder.
• Platformsbegivenheder har to muligheder for udgivelsesadfærd:
  • Udgiv straks: Begivenheder udgives straks under transaktionen, før den endelige databasebekræftelse. Begivenheder, der udgives på denne måde, er ikke garanteret at blive udgivet i rækkefølge.
  • Udgiv efter bekræftelse: Begivenheder udgives på det tidspunkt, hvor databasetransaktionen er bekræftet. Begivenheder, der udgives på denne måde, er garanteret udgivet i rækkefølge.

Det er nyttigt at bruge Udgiv straks til anvendelsessituationer som logføring, hvor du ønsker at udgive logføringsbegivenheden, uanset om transaktionen lykkes og bekræftes eller mislykkes og ruller tilbage. Det er muligt straks at udgive en platformsbegivenhed, der forbruges af en platformsbegivenhedsudløser. Platformsbegivenhedsudløseren konkurrerer derefter om en databaserække lås med den transaktion, der udgav den. Gennemse alle designs grundigt, før du straks udgiver platformsbegivenheder for at sikre, at du undgår dette scenarie.

Asynkrone forløb giver lav kode-alternativer til asynkrone Apex. Som med andre former for asynkron behandling, udføres de i baggrunden, når der er ressourcer tilgængelige. Asynkrone forløb har heller ingen SLA'er og kan have uforudsigelige ventetider.

Planlagte stier er cron-udløserbaserede til at blive afviklet på et bestemt tidspunkt. De udføres, når registreringer oprettes, opdateres eller slettes, og giver dig detaljeret kontrol over, hvornår du skal køre automatiseringen i forhold til registreringsændringen. (Eksempel: Send en mail til en bruger en time, før en opgave er forfalden). I modsætning til Apex future-metoder, som er begrænset til maksimalt 50 metoder, der er inddelt i en synkron transaktion, har planlagte forløbshandlinger i øjeblikket ikke en maksimal køgrænse pr. transaktion. Der er dog en batchstørrelseskonfiguration i definitionen af den planlagte sti, der giver mulighed for en vis kontrol over, hvor mange registreringer der håndteres af den planlagte stiforløbskørsel.

Asynkrone stier kan føjes til registreringsudløste forløb. De kører i baggrunden og forsinker ikke kørslen af den transaktion, der oprindeligt udløste forløbet. Du kan bruge en asynkron sti til at udføre en lang kørende handling eller enhver handling, som du ønsker at køre på sin egen tid. Asynkrone stier kan hjælpe med at undgå blandede DML-fejl, der forekommer, når du har brug for at opdatere en værdi på en relateret registrering, der ikke er del af den registrering, der udløste forløbet.

Bemærk: Udgående meddelelser er en forældet funktion, og platformsbegivenheder (beskrevet i det foregående afsnit) er en mere moderne tilgang og tilbyder større fleksibilitet. Platformsbegivenheder er Salesforces anbefalede mønster for begivenhedsstyret integration.

Udgående meddelelser giver en metode til asynkron udgående kommunikation via SOAP API. Når den er konfigureret i Salesforce, opretter definitionen af den udgående meddelelse en SOAP WSDL, der kan forbruges af en ekstern webtjenesteudbyder. Udgående meddelelser kan udløses fra arbejdsflowregler, proceskonstruktørprocesser eller Lightning efter lagring-forløbsudløsere. En udgående SOAP-meddelelse kan indeholde op til 100 adviseringer. Hver advisering indeholder objekt-id'et og en reference til de tilknyttede sObject-data. Hvis oplysningerne i det underliggende objekt ændres, efter adviseringen er sat i kø, men før den sendes, er det kun de seneste data, der leveres, og ikke de mellemliggende ændringer.

Når en udgående meddelelseslytter (den webtjeneste, du konfigurerede med den genererede WSDL) modtager en meddelelse, bruger den de inkluderede sessions-id-oplysninger til at kalde Lightning Platform API for at opdatere den registrering i Salesforce, der udløste den udgående meddelelse.

• Udgående meddelelser håndteres ikke via den købaserede asynkrone infrastruktur i Salesforce, der kører aktiviteter som fremtidige metoder, Apex, Batch Apex, Bulk API osv. I stedet lagres registreringer lokalt i OutboundMessage-objektet. Meddelelser udsendes og prøves igen via en lokal planlagt baggrundsproces.
• Meddelelser sendes ikke synkront, når den udgående meddelelseshandling udføres af initieringsautomatiseringen (f.eks. en efter lagring-forløbsudløser). I stedet for forbliver de i OutboundMessage-objektet, indtil de er sendt korrekt, eller indtil de droppes efter 24 timer med mislykket levering.
• Hvis du vil undgå en uendelig løkke med udgående meddelelser, skal du sørge for, at den bruger, der opdaterer objekterne, ikke har tilladelsen Send udgående meddelelser.

Mail-til-Sag fungerer normalt på en synkron måde. Der er en grænse på fire synkrone tråde til at håndtere indgående Mail-til-Sag-anmodninger. Den synkrone form af handleren bevarer en forbindelse til den indgående Salesforce-mailserver (MTA), der modtager mailen. Der er dog årsager til, at Mail-til-Sag kan håndteres asynkront:

• Mail-til-Sag er underlagt trådbegrænsninger, specifikt 10 i alt-handlertråde pr. appserver: fire tråde til synkron behandling og seks tråde til asynkron behandling.
• Hvis en synkron mail-handler overskrider 15 sekunder af kørselstiden, markeres den pågældende mailtjenesteadresse som asynkron i en periode på 30 minutter. Efterfølgende håndteringsanmodninger for denne tjenesteadresse resulterer i en meddelelse, der er oprettet for MessageTypeName = MAILCATCHER_EMAIL_TO_CASE sammen med en reference til mailindholdet.
• Hvis en synkron tråd allerede er i brug for en bestemt organisation og tjenesteadresse, sættes yderligere anmodninger for denne tjenesteadresse i kø asynkront.
• Hvis en synkront håndteret mail støder på en fejl, f.eks. en rækkespærringstimeout, gemmes og sættes anmodningen i kø asynkront.
• Hvis der ikke er nogen synkrone handlertråde tilgængelige, sættes anmodningen i kø asynkront.

• Der er en fjernelsesindstilling, når du konfigurerer Mail-til-Sag, men den fjerner ikke dubletvedhæftninger, før mailen er behandlet. Denne fjernelse af dubletter sparer plads i databasen, men det reducerer ikke mailbehandlingstider. Du kan dog forbedre ydeevnen ved at implementere en tilpasset Apex til meddelelsesbehandling. Denne implementering påvirker ikke nogen styringsbegrænsninger, men den giver handleren adgang til mailmeddelelsen og alle dens vedhæftede filer, før noget bekræftes til databasen. Denne adgang giver dig mulighed for at beregne kontrolsummer for alle de inkluderede vedhæftninger og kassere alle, som du beslutter er unødvendige, herunder dubletter, velkendte signaturbilleder eller uønskede filtyper.
• Bekræftelse af vedhæftede filer til Salesforce Files er ansvarlig for det meste af mailbehandlingstiden. Efterhånden som svar-svar til eller fra kontakten øges, og mailkæden bliver større, bliver behandlingstiden for hver mail også større. Hvis mailindstillingen "Svar kun med nyt indhold" ikke er valgt, så vil mailkæderne vokse med hvert svar. Derfor anbefaler vi, at du bruger en Apex Email-til-Sag-handler med logik, der implementerer fjernelse af dublettegn på behandlingstidspunktet.
• På trods af kald af Apex som en del af håndteringen er Mail-til-Sag-handler fritaget fra den samtidige Apex.

Hvis du vil behandle store mængder af registreringer asynkront, kan du overveje at bruge en af disse tilgange.

Du kan bruge Batch Apex til at opbygge komplekse, langvarige processer, der involverer tusindvis af registreringer. Batch Apex fungerer ved at opdele dit registreringssæt og behandle det i administrerbare segmenter. Som et eksempel kan du opbygge en arkiveringsløsning, der kører på natbasis og føjer registreringer, der er ældre end en bestemt dato, til et arkiv. Eller du kan opbygge en datarensningshandling, der ser på alle konti og salgsmuligheder på natbasis og udfører eventuelle nødvendige opdateringer baseret på et sæt foruddefinerede kriterier.

• Batch Apex er bedst til behandling af store mængder data, fordi asynkron Apex har højere grænser end synkron Apex. Batch Apex klarer sig også mere effektivt, når det behandler flere elementer pr. batch, fordi det bruger massehandlinger, der kræver mindre overhead fra køstyring. Hvis du derfor vil undgå at udløse forløbskontrolmekanismen via køforløb og undgå at udnytte den daglige asynkrone Apex, skal du ikke oprette batches med små omfangsstørrelser eller som har hurtige behandlingstider.
• Undgå at sætte batchjob i kø direkte fra handlinger, der er genereret af store mængder slutbrugeraktivitet eller integrations-API-kald. Denne tilgang kan hurtigt opbruge flexkøen. Hvis du planlægger at kalde et batchjob fra en udløser, skal du garantere, at udløseren ikke tilføjer flere batchjob end grænsen.
• Batch Apex er begrænset til maksimalt fem samtidige tråde, hvilket begrænser dens gennemsnit meget mere end fremtidige metoder eller Apex i kø.
• Batchjob, der involverer store mængder data, skal ideelt planlægges til at køre uden for spidsbelastningstider for at frigøre ressourcer til processer, der kræver svar i realtid eller næsten i realtid.
• Når du kalder System.scheduleBatch, planlægger platformen dit job til kørsel på det tidspunkt, som du angiver. Faktisk kørsel forekommer på eller efter dette tidspunkt, afhængigt af tilgængelighed af tjenester.
• Planlægningen kører i systemkontekst. Alle klasser køres, uanset om den bruger, der planlagde kørslen, har tilladelse til at køre klassen.
• Alle planlagte Apex gælder for batchjob, der er planlagt ved brug af System.scheduleBatch. Når batchjobbet er sat i kø (med statussen Holding eller Kø), gælder alle batchjobgrænser, og jobbet tæller ikke længere med i planlagte Apex
• For et batchjob med en tilbagevendende tidsplan skal du overveje den korrekte adfærd, hvis det tidligere job stadig køres, når det nye job starter.
• Batchjob, der er oprettet fra synkrone Apex-transaktioner, bruger flexkøen. Flexkøen er begrænset til maksimalt 100 elementer på ethvert tidspunkt. Hvis en transaktion forsøger at tilføje flere poster, genererer platformen fejl og sender ikke batchjobbet.
• Udkald og andre ikke-transaktionsmæssige handlinger fra batchjob skal følge overvejelser i forbindelse med idempotent design. Batchjob, der er sat i kø, før en Salesforce-servicevedligeholdelsesnedetid forbliver i køen. Når nedetid for service slutter, og der er systemressourcer tilgængelige, udføres de batchjob, der er sat i kø. Hvis et batchjob kører, når nedetid indtræffer, rulles batchkørslen tilbage og genstartes, når tjenesten er gendannet. Da kørselsmetoder derfor kan køres flere gange, kan alle ikke-transaktionsmæssige handlinger, f.eks. udkald, forsøges igen.
• Overvej at konfigurere batchjobbet til at fremhæve BatchApexErrorEvent-begivenheder for at håndtere fejl- og undtagelsesscenarier.

Et planlægningsudløst forløb er et forløb, der er planlagt til at blive kørt på et angivet tidspunkt og med en gentaget frekvens (dagligt, ugentligt eller en gang) for at udføre handlinger på en batch af registreringer. (Eksempel: Opdater et felt i alle sager med statussen "Åben" kl. 2 hver nat). Planlagte forløb eksekveres via Cron-udløsermekanismen og massebehandles.

• Et planlægningsudløst forløb eksekverer 200 registreringer pr. kald, men vil blive eksekveret med flere samtidige tråde, hvis der findes flere end 200 registreringer.
• Planlægningsudløste forløb udføres i en synkron kontekst med synkrone begrænsninger.
• Der er ingen måde, hvorpå du aktuelt kan kontrollere antallet af registreringer, der behandles pr. planlagt forløbskald. Hvis kørslen er for mere end 200 registreringer, er der en reel risiko for samtidige Apex fejl.

Bulk API er baseret på REST-principper og er optimeret til at arbejde med store datasæt. Du kan bruge den til at indsætte, opdatere, upsertere, forespørge på eller slette mange registreringer asynkront og behandle resultaterne senere. Salesforce Platform behandler anmodningen i baggrunden. I modsætning hertil bruger SOAP API og REST API synkrone anmodninger og optimeres til klientapplikationer i realtid, der opdaterer nogle få registreringer ad gangen. Du kan bruge begge disse API'er til behandling af mange registreringer, men når datasættene indeholder hundredtusinder af registreringer, er de mindre praktiske. Bulk API's asynkrone struktur er designet til at gøre det enkelt og effektivt at behandle data fra nogle få tusinde til millioner af registreringer.

Den nemmeste måde at bruge Bulk API er at aktivere det til behandling af registreringer i Data Loader ved hjælp af CSV-filer. Med Data Loader behøver du ikke skrive din egen klientapp. Men nogle gange kræver entydige krav, at du skriver en tilpasset app.

Der er to masse-API'er tilgængelige i Salesforce Platform.

• Bulk API 2.0 er den nyeste API. Det giver et strømlinet og nemmere at bruge arbejdsflow og er fokus for forbedringer.
• Den oprindelige Bulk API understøttes stadig fuldt ud, men forbedres ikke længere. Vi anbefaler, at du bruger Bulk API 2.0, hvor det er muligt.

Hvis du ønsker flere oplysninger om API-grænser, kan du se Bulk API Limits og Bulk API 2.0 Limits.

Se i denne vejledning, når du opbygger eller overvejer asynkron behandling på Salesforce Platform. Det er altid en god ide at forstå det fulde omfang af indstillinger, der er tilgængelige for dig, og hvordan de kan passe til din specifikke anvendelsessituation. Sørg for at vurdere dit aktuelle landskab grundigt, før du foretager ændringer af nogen af dine eksisterende arkitekturer, især hvis din aktuelle løsning fungerer godt.