Asynkron behandling øker skalerbarheten ved å tillate høyere grenser per kontekst. Asynkrone forespørsler utføres i sine egne tråder i bakgrunnen, slik at brukere kan fortsette å gjøre arbeid på klientsiden mens de asynkrone oppgavene utføres i bakgrunnen.

Salesforce Lightning Platform tilbyr en rekke asynkrone teknologier som kan brukes til å løse et gitt bruksområde. Hver teknologi har fordeler og grenser som du må ta hensyn til når du velger en løsning for hvert bruksområde.

Når du velger en teknologi for implementering, bør du ta hensyn til tre viktige punkter:

1. Asynkron behandling er ikke den beste løsningen for alle problemer. Det kan være fristende å tenke på en prosess som ikke direkte krever brukermedvirkning, som en god kandidat for asynkron behandling, men det er noen ulemper. Først har asynkrone prosesser ingen tjenestenivåavtale, som betyr at det ikke er noen garanti for at en asynkron prosess vil bli fullført innen en angitt tidsperiode. Deretter er det ingen garanti for konsistent responslatens. Hvis en asynkron prosess fullføres innen en bestemt tidsperiode, kan det ta en annen tid å fullføre en etterfølgende prosess. Selv om en bruker ikke venter direkte på et svar, er det derfor ikke sikkert at asynkron behandling er riktig for scenariet hvis du har etterfølgende prosesser som avhenger av et svar, eller hvis du er bekymret for at overdreven responstid kan føre til at dataene dine blir usynkronisert med dataene i et eksternt system.
2. Det finnes forskjellige måter å behandle asynkrone forespørsler på Salesforce Platform på, så forsikre deg om at du velger den beste løsningen. Teknologi som støtter asynkron behandling på Salesforce Platform, fungerer annerledes "under bakgrunnen", og noen er utformet for svært spesifikke brukstilfeller.
3. Hvis en teknologi er asynkron på klientsiden, betyr det ikke nødvendigvis at all ende-til-ende-behandling utføres parallelt. Avhengig av valgene du gjør, kan klientens meldinger noen ganger fortsatt bli serialisert på serversiden.

Hvis du bruker feil teknologi eller feil kombinasjon av teknologi til en jobb, kan det oppstå utilsiktede konsekvenser som avbryter fordelene med asynkron behandling. Denne veiledningen gir forklaringer og anbefalinger, i tillegg til potensielle ulemper og motmønstre for ulike asynkrone brukstilfeller, sammen med grunnlaget for disse anbefalingene. Den gir også innsikt i hvordan ulike asynkrone implementeringsteknikker fungerer og er regulert på Salesforce Platform.

Hvis du bestemmer deg for hvilken teknologi som skal brukes, finnes det en fokusert beslutningsveiledning for asynkron behandling som gir en rask tilordning av typiske bruksområder til den mest egnede teknologien.

Salesforce Lightning Platform er en omfattende AI-drevet plattform som forener ansatte, autonome AI-agenter, firmadata og applikasjoner i ett enkelt, pålitelig system for å forbedre produktiviteten og kundeopplevelsen. Den aktiverer opprettelse av et "agentistisk foretak" ved å koble til Customer 360, Data Cloud og Slack for ende-til-ende-automatisering.

Dette dokumentet dekker ikke teknologier i andre økosystemer som MuleSoft, Informatica, Commerce Cloud, Tableau og Marketing Cloud.

Vær oppmerksom på at denne veiledningen fokuserer utelukkende på asynkron behandling i Salesforce Lightning Platform. Hvis du ser etter informasjon om asynkrone integrasjonsmønstre, kan du se Event-Driven Architecture.

• Før du bruker asynkron behandling må du forsikre deg om at bruksområdet passer til mønsteret. Asynkrone mønstre har ingen tjenestenivåavtale, er underlagt flere styringsmekanismer, kan ha kapasitetsgrenser definert basert på lisensiering, og kan føre til behandlingsforsinkelser på grunn av den endelige naturen til ressursene som er tildelt til asynkron infrastruktur i Salesforce Platform. Ta disse begrensningene alvorlig i betraktning når du bruker asynkron behandling i scenarier der en bruker krever et svar fra systemet før brukeren kan fortsette arbeidet sitt.
• Asynkron behandling med Salesforce er ikke en løsning for behov for grenseløs skalering. Salesforce Platform skaleres ikke uendelig, og asynkrone mønstre er fremdeles underlagt begrensninger. Asynkron behandling bruker tråder, som inneholder kontekstinformasjonen som en CPU trenger for å utføre en strøm av instruksjoner. Tråder kan kjøres parallelt. Antall tilgjengelige tråder i en hvilken som helst CPU er begrenset, så plattformen har mekanismer på plass for å sikre at dens tilgjengelige tråder brukes så effektivt som mulig. Plattformens flytkontrollmekanisme hindrer at organisasjoner bruker for mange tråder og påvirker andre organisasjoner negativt. Plattformens fair use-algoritme bestemmer antall tråder som en organisasjon har tilgjengelig for hver bestemt meldingstype.
• Ved når transaksjoner er virkelig asynkrone. Enkelte arkitekturmønstre fungerer asynkront fra slutt til slutt. Andre prosesser oppfører seg imidlertid asynkront på klientsiden eller nettlesersiden, men serialiserer forespørsler på serversiden, som deretter er underlagt synkrone styringsgrenser.
• For å bygge omfattende utgående integrasjoner fra Salesforce Platform bruker du plattformhendelser og robust mellomprogramvare i stedet for oppkall via asynkron Apex. Fordi det er et begrenset antall asynkrone tråder tilgjengelig i plattformen, har utgående integrasjoner via asynkron Apex begrenset skalerbarhet. Hvis organisasjonen har utgående integrasjoner som involverer store mengder meldinger, overskrider antall tilgjengelige tråder og har lange behandlingstider, vil bruk av asynkron Apex uunngåelig føre til forsinkelser.
• ** Pass på å inkludere overvåking når du bruker asynkron behandling.** Med overvåking kan du oppdage problemer så tidlig som mulig og rette dem før viktige ytelseshendelser skjer.
• Ta hensyn til hendelser som kan forårsake ekstreme belastninger. Når du utformer asynkrone prosesser, må du forsikre deg om at de kan håndtere arbeidsbelastningsspiker og nedturer på en forutsigbar måte. Vurder hvordan implementeringen håndterer uventede hendelser, som strømavbrudd, og utform sikkerhetstiltak som reduserer tap av data eller tap av funksjonalitet.

Når du velger en løsning for asynkron behandling på serversiden, må du først evaluere organisasjonens behov og tilgjengelige ressurser. Målet ditt er å velge en løsning som minimerer implementerings- og vedlikeholdskostnader samtidig som du sikrer skalerbarhet og minimerer sannsynligheten for grenseovertredelser. Dette målet er avhengig av de tekniske punktene som er skissert i de neste delene, i tillegg til sammensetningen av teamet. Vurder for eksempel om du har Apex i teamet som kan vedlikeholde pro-kodeløsningen. Ellers kan en deklarativ tilnærming være mer fornuftig. Husk også at forskjellige sett med grenser kan gjelde for forskjellige verktøy.

Vurder bruksområdet for en asynkron bestillingsprosess i Salesforce. Når en bestilling lagres, utløses det en melding til et eksternt lagerbehandlingssystem med spesielle instruksjoner om hvordan en artikkel pakkes og sendes. Brukeren som legger inn bestillingen, trenger ikke et umiddelbart svar fra lagerbehandlingssystemet, så forespørselen kan sendes asynkront. Den asynkrone behandlingen gir brukeren mulighet til å fortsette arbeidet uten forsinkelser.

Viktige punkter om arkitekturen:

• Hvor mange samtidige prosesser er nødvendig?
• Hvordan vil den samtidige prosessen samhandle med hverandre?
• Hvor mange SOQL-spørringer skal utføres i hver prosess?
• Hvor mange DML-operasjoner skal utføres i hver prosess?
• Hvor lenge vil hver prosess kjøre?
• Hvor sensitive er prosesser for bestemte tidsplaner?

Salesforce Platforms multitenantarkitektur isolerer og støtter samtidig de varierende kravene til mange leietagere (organisasjoner). Alle asynkrone Apex som dekkes i denne veiledningen, utføres i samme asynkrone infrastruktur i Salesforce Platform. De bruker et meldingskørammeverk som styres av to primære håndhevingsmekanismer: Flytkontroll og rimelig bruk.

Flytkontrollen og mekanismene for rettferdig bruk hindrer at en enkelt leietager bruker for mange serverressurser og ikke gir de resterende leietagerne nok ressurser. Selv om det er nyttig å forstå hvordan disse mekanismene fungerer, bør det være viktig at det å følge anbefalte fremgangsmåter for asynkron behandling, som de som er skissert i de neste delene, reduserer sannsynligheten for at du får problemer med dem betydelig.

Plattformens flytkontrollmekanisme hindrer at én organisasjon oversvømmer en gitt meldingstype, noe som forbruker for mange tråder og påvirker andre organisasjoner negativt. Før rammeverket legger til nye oppføringer i køen som er knyttet til en meldingstype, sjekker det de første flere tusen eksisterende oppføringene i køen. Hvis de fleste eksisterende oppføringer er knyttet til den samme organisasjonen og denne organisasjonen allerede har oppføringer i arbeidstråder, flyttes de nylig innlagte oppføringene til baksiden av køen. Denne prosessen kalles re-enqueuing. Gjenopprettelse skjer vanligvis for Apex og Bulk API-prosesser fordi de ofte setter inn et stort antall oppføringer i køene samtidig.

Plattformens mekanisme for rettferdig bruk implementerer et sjiktbasert system. Systemet sikrer at hver organisasjon på Salesforce Platform får en rimelig andel av behandlingstiden for en gitt meldingstype, inkludert meldingstypene Future, Queueable og Batch. Hvis én organisasjon dominerer en gitt meldingstype samtidig som andre organisasjoner venter på å utføre arbeid på samme meldingstype, reduserer algoritmen for rettferdig bruk antall tråder som organisasjonen har tilgjengelig for den bestemte meldingstypen.

En fordel med å bruke asynkrone Apex er at noen styringsgrenser, som SOQL-spørringsgrenser og heap-størrelsesgrenser, er høyere. Men ikke bruk disse metodene for mye. På grunn av de begrensede ressursene som er tildelt asynkron infrastruktur, kan kraftig bruk av Future, Queueable og Batch Apex føre til behandlingsforsinkelser som skyldes begrensninger basert på rimelig bruk og flytkontroll.

Utgående oppkall som bruker asynkron Apex, teller mot grensen for asynkron Apex. Den daglige grensen er for øyeblikket 250 000 eller 200 ganger antall gjeldende brukerlisenser avhengig av hva som er størst. Denne grensen kan være et problem for brukstilfeller med stor trafikk. Hvis du overskrider grensen, vil dine asynkrone Apex og deres tilknyttede utgående oppkall mislykkes.

I tillegg, fordi plattformen har et begrenset antall asynkrone tråder tilgjengelig, har utgående integrasjoner via asynkron Apex begrenset skalerbarhet. Eventuelle utgående integrasjoner med stor trafikk som overskrider antall tilgjengelige tråder, kan ha lange behandlingstider og føre til forsinkelser.

Vurder disse alternative løsningene for brukstilfeller med stor trafikk. API-kall med disse løsningene teller mot den daglige grensen for API-forespørsler, som er betydelig høyere enn den daglige grensen for asynkron Apex. Følgelig er disse løsningene mer skalerbare. Vær imidlertid oppmerksom på at det fremdeles finnes fysiske begrensninger for antall samtidige forespørsler som en hvilken som helst CPU kan behandle.

• Middleware Scheduled Pull. Unngå forsinkelser knyttet til utgående integrasjonsjobber med stor trafikk ved å bruke mellomprogramvare til å hente dataene på en planlagt basis i stedet for å pushe dem via asynkron Apex. Mellomprogramvare, som MuleSoft Anypoint Platform, kan bruke innebygd SOAP API eller REST API på en synkron måte slik at få, om noen, forsinkelser blir introdusert. Mellomprogramvare kan også bruke den innebygde Bulk APIen til store datavolumer.

• Middleware Pull via plattformhendelsesvarsel. I stedet for å legge sammen Asynkron Apex i Future, Queueable eller Batch for å utføre utgående integrasjoner, kan du bruke plattformhendelser. Plattformhendelsen kan enten levere den utgående informasjonen selv eller instruere et mellomprogramverktøy til å trekke ut den nødvendige informasjonen via en innebygd API og levere den til det endelige målet. Ingen av disse løsningene er utsatt for forsinkelsene som asynkron Apex er utsatt for. Men plattformhendelsesgrenser gjelder fremdeles.

Med Apex i kø kan du kjøre Apex som involverer omfattende databaseoperasjoner eller oppkall fra eksterne nettjenester, asynkront. For å bruke Apex i kø implementerer du køgrensesnittet og legger deretter til en jobb i Apex-jobbkøen. Denne tilnærmingen sikrer at den asynkrone Apex kjører i bakgrunnen i sin egen isolerte tråd og ikke forsinker utførelsen av hoved Apex. Hver jobb i køen kjøres når systemressurser blir tilgjengelig.

Apex i kø representerer utviklingen av asynkron Apex. Den tilbyr funksjoner som ikke er tilgjengelig for fremtidige Apex, inkludert:

• Jobb-IDer: Når du sender en jobb ved å kalle opp System.enqueueJob-metoden, returnerer metoden IDen til den nye jobben. Du kan bruke denne ID-en til å identifisere jobben. For å overvåke fremdriften viser du siden Apex i Salesforce-oppsettet eller spør AsyncApexJob-objektet.
• Støtte for ikke-primitive typer: Købaserte klasser kan inneholde medlemsvariabler av ikke-primitive datatyper, som sObjects eller tilpassede Apex.
• Støtte for jobbkjetting: Du kan kjede jobber i kø ved å starte en ny jobb fra en kjørende jobb. Denne teknikken kan hjelpe deg å løse scenarier som involverer prosessavhengigheter.
• Maksimal dybde kontroll: Du kan konfigurere købare jobber med en maksimal stabledybde for å sikre at kjeder av jobber ikke ender opp med uventet rekursjon.
• Dedupliserings signaturer: Købare jobber gir en valgfri signatur for å oppdage og fjerne duplikatjobber.
• Konfigurerbar forsinkelse: Du kan definere en forsinkelse på opptil 10 minutter før Købar-jobben skal utføres.
• Transaksjonsfinalister: Du kan legge ved en etterhandlingssekvens i en Købar-jobb og utføre relevante handlinger basert på resultatet. En transaksjonsleder kan for eksempel legge en Købar-jobb som mislyktes på grunn av et ikke-håndtert unntak, i kø på nytt opptil fem ganger.

Salesforce bruker et købasert rammeverk til å håndtere asynkrone prosesser. Denne køen brukes til å balansere arbeidsbelastninger for forespørsler på tvers av organisasjoner. Slik sikrer du at organisasjonen bruker denne køen så effektivt som mulig:

• Unngå å legge fremtidige eller Købare-metoder i kø direkte fra handlinger som genereres av store mengder sluttbrukeraktivitet eller integrasjons-API-kall. Denne tilnærmingen kan raskt utnytte daglige asynkrone Apex, noe som fører til alvorlige forretningseffekter.
• Unngå å legge i kø mer enn én asynkron handling per synkron handling. Når flere asynkrone metoder legges sammen fra én enkelt synkron handling, utføres ofte de asynkrone aktivitetene samtidig og bidrar til radlåsekonflikter og/eller tidsavbrudd av radlåsefeil.
• Unngå å legge til et stort antall fremtidige eller købare metoder i den asynkrone køen.
• Forsikre deg om at fremtidige metoder og Købar-metoder utføres så raskt som mulig. Jo lengre tid det tar å utføre en fremtidig metode, desto mer sannsynlig blir forespørsler bak den i køen forsinkede. For å sikre rask utføring av gruppejobber minimerer du nettjenesteoppkalltider, justerer spørringer som brukes i fremtidige metoder, og optimaliserer eventuelle andre objektautomatiseringer, inkludert Prosessbygger-prosesser, arbeidsflytregler, flyter og Apex.
• Test dine asynkrone metoder i stor skala. Bruk et miljø som genererer maksimalt antall metoder som du forventer å håndtere. Denne testen bidrar til å finne ut om du vil støte på problemer med ytelse eller grenser i produksjonsmiljøet. Vurder også innvirkningen på kumulative daglige grenser.
• Bruk Apex i stedet for fremtidige eller købare metoder til å behandle store antall poster. Apex kan håndtere komplekse, langvarige prosesser som utføres mot tusenvis av poster, og kan planlegges til å kjøre i åpningstider når flere ressurser er tilgjengelig.

Bruk planlagt Apex til å utføre på et angitt tidspunkt og med en gjentatt frekvens som definert av et cron-uttrykk. Selv om handlingen med å planlegge Apex via cron-uttrykket er en asynkron prosess, utføres den underliggende koden synkront når jobben starter. Planlagt Apex er ideelt for daglige eller ukentlige vedlikeholdsoppgaver.

• Du kan ha bare 100 planlagte Apex om gangen. For å unngå denne begrensningen kan du vurdere å bruke en tidsplanutløst flyt som kaller opp Apex i stedet for å bruke planlagt Apex.
• Bruk ekstrem forsiktighet hvis du planlegger å planlegge en klasse fra en utløser. Du må kunne garantere at utløseren ikke legger til flere planlagte klasser enn grensen. Vurder spesielt masseoppdateringer av API, importveivisere, masseendringer av poster via brukergrensesnittet og alle saker der flere enn én post kan oppdateres om gangen.
• Til engangsoppgaver som må planlegges opptil 10 minutter senere, bruker du en forsinket Købar-jobb. Denne løsningen teller ikke mot grensen på 100 planlagte jobber.
• Planlagt Apex utføres i en synkron kontekst med synkrone grenser.
• Vurder hvor lenge den planlagte jobben skal utføres. En langvarig jobb kan overlappe med starten av neste planlagte jobb.
• Salesforce planlegger klassen for utføring på det angitte tidspunktet. Faktisk utførelse kan bli forsinket basert på tjenestetilgjengelighet. Jobber som er planlagt å kjøre under nedetid for tjenestevedlikehold, blir planlagt å kjøre etter at tjenesten kommer tilbake.
• Bruk System.scheduleBatch til å planlegge gruppejobber i stedet for å ha en planlagt jobb med det ene formålet å legge til rette for en gruppejobb.

Historisk har synkrone oppkall gjort fra en Apex-metode som kjører i en synkron Apex-transaksjonskontekst, som en Visualforce-kontroller eller en Lightning-komponentkontroller, vært underlagt Apex-samtidighetsgrensen for forespørsler som kjører lenge. Fra og med Winter ’19-utgivelsen telles ikke synkrone oppkall lenger som langvarige kjøringer. Selv om Apex opprinnelig ble opprettet som en løsning på synkrone oppkall som resulterte i forespørsler som kjørte lenge, gir de også noen ekstra fordeler.

• En enkelt synkron handling kan utføre opptil tre fortsettelseshandlinger. Den forrige fortsettelsen må fullføres før en ny fortsettelseshandling utføres.
• Hver fortsettelseshandling kan utføre maksimalt tre oppkall som utføres parallelt.
• Når alle oppkallene som utføres av en fortsett-handling, er fullført, kaller plattformen opp fortsett-tilbakekall-metoden for å håndtere resultatet.

Selv om fortsettelser utføres asynkront i forhold til den opprinnelige synkrone handlingen, er det viktige forskjeller mellom Apex og andre asynkrone Apex som fremtidige metoder, Købar eller Batch. Viktige forskjeller er:

• Fortsettelser legges ikke i kø på noen måte.
• Fortsettelser bidrar ikke til grensen for daglig asynkron Apex.
• Fortsettinger bytter trådkontekst på programserveren fra en tung Apex plattformtråd til en lett tråd som bare utfører oppkall. For å utføre oppkall som kan kjøre opptil 120 sekunder, gir fortsettinger betydelige minnesbesparelser på programserveren.
• Opprinnelig kunne fortsettinger bare utføres fra et Visualforce JavaScript eksternt kall. I Summer ‘19 ble imidlertid Lightning Component-rammeverket offisielt lagt til, noe som eliminerte behovet for Visualforce.

Plattformhendelser er Salesforce Platforms implementering av en ren hendelsesdrevet arkitektur. Du finner flere detaljer om komponentene knyttet til denne typen arkitektur i Arkitektveiledningen til hendelsesdrevet arkitektur.

Plattformhendelser og plattformhendelsesutløsere/flyter er ofte gode alternativer til å kjøre asynkron Apex. De er også en utmerket måte å kalle opp behandling utenfor plattformen på. Du kan for eksempel bruke en kombinasjon av AWS-hendelsesoverføringer og plattformhendelser til å kalle opp databehandlingsfunksjonalitet uten server i AWS Lambda. Arbeid som utføres relativt raskt og uten oppkall (som ikke er mulig fra en plattformhendelsesutløser eller flyt), er en utmerket kandidat for en plattformhendelse/utløser eller en hendelses/flyt-kombinasjon.

Hendelsene som publiseres til bussen via publiser etter bekreftelse leveres i rekkefølge og kan massebehandles av utløseren eller flyten i en separat synkron kontekst. Konteksten er synkron og håndhever alle synkrone styringsgrenser. Velg plattformhendelsesutløseren/flytbatchstørrelsen nøye for å unngå å nå grenser.

• Etter hvert som hendelser publiseres i hendelsesbussen, blir de tilgjengelig for forbrukere. Når det gjelder hendelsesutløsere (Apex eller flyt), sendes disse hendelsene til tilgjengelige synkrone tråder på appnivået (én tråd per hendelsesutløser/flyt). Vær oppmerksom på at denne prosessen ikke har en tjenestenivåavtale.
• Når publiseringsoperasjoner legges til i køen, lagres resultatet av køprosessen i Database.SaveResult-objektet. Disse oppføringene viser bare om køoperasjonen var vellykket eller ikke. Implementer et Apex Publish-tilbakekall for å få det endelige resultatet av en hendelse publisert via hendelsesbussen. Med denne tilleggsinformasjonen kan du ta beslutninger om ytterligere handlinger, som å forsøke å publisere mislykkede hendelser på nytt.
• Plattformhendelser er ikke underlagt de samme grensene som asynkron Apex, men de har sine egne sett med styringsgrenser. Hvis du får problemer med grenser, kan du aktivere forbedrede hendelsesbruksmålinger for å finne ut om bestemte hendelser bruker opp flere av tildelingene enn du hadde tenkt. Hvis du trenger større gjennomstrømning for hendelsesutløsere, kan du vurdere å bruke parallelle abonnementer til å behandle hendelser samtidig i stedet for i en enkelt strøm. Med parallelle abonnementer kan du skalere Apex for å håndtere store mengder hendelser. Parallelle abonnementer er tilgjengelig for tilpassede plattformhendelser med stor trafikk, men ikke for standardhendelser eller endringshendelser.
• Plattformhendelser har to alternativer for publiseringsvirkemåte:
  • Publiser umiddelbart: Hendelser publiseres umiddelbart under transaksjonen, før den endelige databasens bekreftelse. Hendelser som publiseres på denne måten, garanteres ikke å publiseres i rekkefølge.
  • Publiser etter bekreftelse: Hendelser publiseres på det tidspunktet databasetransaksjonen blir riktig utført. Hendelser som publiseres på denne måten, er garantert publisert i rekkefølge.

Det er nyttig å bruke Publiser umiddelbart til brukstilfeller som logging, der du vil publisere loggingshendelsen uavhengig av om transaksjonen lykkes og bekreftes, eller mislykkes og rulles tilbake. Det er mulig å umiddelbart publisere en plattformhendelse som forbrukes av en plattformhendelsesutløser. Plattformhendelsesutløseren konkurrerer deretter om en databaseradelåsing med transaksjonen som publiserte den. Se gjennom alle utforminger grundig før du umiddelbart publiserer plattformhendelser for å sikre at du unngår dette scenariet.

Asynkrone flyter gir lavkodede alternativer til asynkron Apex. Som med andre former for asynkron behandling utføres de i bakgrunnen når ressurser er tilgjengelig. Asynkrone flyter har heller ingen tjenestenivåavtaler og kan ha uforutsigbare ventetider.

Planlagte baner er cron-utløserbasert for å utføres på et bestemt tidspunkt. De utføres når poster opprettes, oppdateres eller slettes, og gir deg detaljert kontroll over når du skal kjøre automatiseringen relativt til postendringen. (Eksempel: Send en e-postmelding til en bruker én time før en oppgave forfaller.) Til forskjell fra Apex fremtidige metoder, som er begrenset til maksimalt 50 metoder lagt inn i en synkron transaksjon, har planlagte flythandlinger for øyeblikket ikke en grense for maksimalt antall køer per transaksjon. Det er imidlertid en batchstørrelseskonfigurasjon i definisjonen av den planlagte banen som gir en viss kontroll over hvor mange poster som håndteres av den planlagte banflytutføringen.

Asynkrone baner kan legges til i postutløste flyter. De kjører i bakgrunnen og forsinker ikke utførelsen av transaksjonen som opprinnelig utløste flyten. Du kan bruke en asynkron bane til å utføre en operasjon som kjører lenge, eller hvilken som helst operasjon som du vil kjøre på eget tidspunkt. Asynkrone baner kan bidra til å unngå blandede DML-feil som oppstår når du må oppdatere en verdi i en relatert post som ikke er en del av posten som utløste flyten.

Notat: Utgående meldinger er en eldre funksjon, og plattformhendelser (beskrevet i forrige del) er en mer moderne tilnærming og gir større fleksibilitet. Plattformhendelser er Salesforces anbefalte mønster for hendelsesdrevet integrasjon.

Utgående meldinger er et middel til asynkron utgående kommunikasjon via SOAP API. Når den er konfigurert i Salesforce, produserer definisjonen av den utgående meldingen et SOAP WSDL som kan forbrukes av en ekstern nettjenesteleverandør. Utgående meldinger kan utløses fra arbeidsflytregler, Prosessbygger-prosesser eller Lightning etter lagring. En utgående SOAP-melding kan inneholde opptil 100 varsler. Hvert varsel inneholder objekt-IDen og en referanse til de tilknyttede sObject-dataene. Hvis informasjonen i det underliggende objektet endres etter at varselet er lagt i kø, men før det sendes, leveres bare de nyeste dataene, ikke de mellomliggende endringene.

Når en utgående meldingsleder (nettjenesten du konfigurerte med det genererte WSDL-et) mottar en melding, bruker den den inkluderte økt-ID-informasjonen til å kalle opp Lightning Platform API for å oppdatere posten i Salesforce som utløste den utgående meldingen.

• Utgående meldinger håndteres ikke via den købaserte asynkrone infrastrukturen i Salesforce som kjører aktiviteter som fremtidige metoder, Købar Apex, Batch Apex, Bulk API og så videre. I stedet lagres poster lokalt i OutboundMessage-objektet. Meldinger sendes og prøves på nytt via en lokal planlagt bakgrunnsprosess.
• Meldinger sendes ikke synkront når den utgående meldingshandlingen utføres av initieringsautomatiseringen (for eksempel en flytutløser etter lagring). I stedet forblir de i OutboundMessage-objektet til de sendes riktig eller til de utelates etter 24 timer med mislykket levering.
• For å unngå en uendelig sløyfe med utgående meldinger må du forsikre deg om at brukeren som oppdaterer objektene, ikke har tillatelsen Send utgående meldinger.

E-post-til-sak fungerer vanligvis på en synkron måte. Det er en grense på fire synkrone tråder for å håndtere innkommende E-post-til-sak-forespørsler. Den synkrone formen for behandleren opprettholder en tilkobling til den innkommende Salesforce-postserveren (MTA) som mottar e-postmeldingen. Det finnes imidlertid årsaker til at E-post-til-sak kan håndteres asynkront:

• E-post-til-sak er underlagt trådgrenser, spesielt totalt 10 behandlertråder per appserver: fire tråder for synkron behandling og seks tråder for asynkron behandling.
• Hvis en synkron e-postbehandler overskrider 15 sekunder med utførelsestid, merkes denne bestemte e-posttjenesteadressen som asynkron i en periode på 30 minutter. Påfølgende behandlingsforespørsler om denne tjenesteadressen fører til en melding som legges i kø for MessageTypeName = MAILCATCHER_EMAIL_TO_CASE, sammen med en referanse til e-postinnholdet.
• Hvis en synkron tråd allerede er i bruk for en bestemt organisasjon og tjenesteadresse, legges flere forespørsler for denne tjenesteadressen i kø asynkront.
• Hvis en e-postmelding som håndteres synkront, støter på en feil, som tidsavbrudd for radlåsing, lagres forespørselen og legges i kø asynkront.
• Hvis ingen synkrone behandlertråder er tilgjengelig, legges forespørselen i kø asynkront.

• Det er et alternativ for fjerning av duplikatverdier når du konfigurerer E-post-til-sak, men det fjerner ikke duplikatverdier for vedlegg før e-postmeldingen er behandlet. Denne fjerning av duplikater sparer plass i databasen, men reduserer ikke behandlingstiden for e-post. Du kan imidlertid forbedre ytelsen ved å implementere en tilpasset Apex for e-post-til-sak for meldingsbehandling. Denne implementeringen påvirker ikke noen styringsgrenser, men den gir behandleren tilgang til e-postmeldingen og alle vedleggene før noe blir bekreftet til databasen. Denne tilgangen lar deg beregne sjekksummer for alle de inkluderte vedleggene og forkaste eventuelle som du bestemmer er unødvendige, inkludert duplikater, velkjente signaturbilder eller uønskede filtyper.
• Det å bekrefte e-postvedlegg til Salesforce Files er ansvarlig for det meste av e-postbehandlingstiden. Etter hvert som svar-svar på eller fra kontakten øker og e-postkjeden blir større, øker også behandlingstiden for hver e-postmelding. Hvis e-postalternativet "Bare svar med nytt innhold" ikke er valgt, vil e-postkjeder vokse med hvert svar. Vi anbefaler derfor at du bruker en Apex for e-post-til-sak med logikk som implementerer fjerning av duplikater av vedlegg på behandlingstidspunktet.
• Til tross for at Apex kalles opp som en del av håndteringen, er E-post-til-sak-behandlere unntatt fra den samtidige Apex.

Hvis du vil behandle store volumer av poster asynkront, kan du vurdere å bruke en av disse løsningene.

Du kan bruke Apex til å bygge komplekse, langvarige prosesser som involverer tusenvis av poster. Apex fungerer ved å dele opp postsettet og behandle det i administrerbare biter. Du kan for eksempel bygge en arkiveringsløsning som kjører hver natt og legger til poster som er eldre enn en bestemt dato, i et arkiv. Eller du kan bygge en dataoppryddingsoperasjon som ser på alle kontoer og salgsmuligheter hver natt og utfører eventuelle nødvendige oppdateringer basert på et sett forhåndsdefinerte kriterier.

• Apex er best til å behandle store mengder data fordi asynkron Apex har høyere grenser enn synkron Apex. Apex fungerer også mer effektivt når den behandler flere elementer per batch, fordi den bruker masseoperasjoner som medfører færre overskudd fra købehandling. For å unngå å utløse flytkontrollmekanismen via køflyt og unngå å utnytte den daglige grensen for asynkron Apex, må du derfor ikke opprette batcher med små omfangsstørrelser eller med raske behandlingstider.
• Unngå å legge gruppejobber i kø direkte fra handlinger som genereres av store mengder sluttbrukeraktivitet eller integrasjons-API-kall. Denne løsningen kan raskt utnytte fleksikøen. Hvis du planlegger å kalle opp en gruppejobb fra en utløser, må du garantere at utløseren ikke legger til flere gruppejobber enn grensen.
• Batch Apex er begrenset til maksimalt fem samtidige tråder, noe som begrenser dens gjennomstrømning mye mer enn fremtidige metoder eller Apex i kø.
• Gruppejobber som involverer store mengder data, bør ideelt sett planlegges til å kjøre i åpningstider for å frigjøre ressurser for prosesser som krever svar i sanntid eller i nærheten av sanntid.
• Når du kaller opp System.scheduleBatch, planlegger plattformen jobben for utføring på det tidspunktet du angir. Faktisk utførelse skjer på eller etter dette tidspunktet, avhengig av tjenestetilgjengelighet.
• Planleggeren kjører i systemkontekst. Alle klasser utføres uavhengig av om brukeren som planla utførelsen, har tillatelse til å utføre klassen eller ikke.
• Alle planlagte Apex gjelder for gruppejobber som er planlagt med System.scheduleBatch. Etter at gruppejobben har blitt lagt i kø (med statusen Oppbevaring eller Sett i kø), gjelder alle gruppejobbgrenser, og jobben teller ikke lenger mot planlagte Apex.
• For en gruppejobb med en gjentagende tidsplan bør du vurdere riktig virkemåte hvis den forrige jobben fremdeles utføres når den nye jobben begynner å kjøre.
• Gruppejobber som utføres fra synkrone Apex-transaksjoner, bruker flexkøen. Flex-køen er begrenset til maksimalt 100 elementer når som helst. Hvis en transaksjon forsøker å legge til flere oppføringer, genererer plattformen feil og sender ikke gruppejobben.
• Oppkall og andre ikke-transaksjonelle operasjoner fra gruppejobber må følge viktige punkter om idempotent design. Gruppejobber som legges i kø før en nedetid for Salesforce-tjenestevedlikehold, beholdes i køen. Når nedetid for service avsluttes og systemressurser er tilgjengelig, utføres gruppejobbene i køen. Hvis en gruppejobb kjører når nedetid skjer, rulles gruppeutførelsen tilbake og startes på nytt etter at tjenesten er gjenopprettet. Fordi utførelsesmetoder derfor kan kjøres flere ganger, kan eventuelle ikke-transaksjonelle operasjoner, som oppkall, prøves på nytt.
• Vurder å konfigurere gruppejobben til å heve BatchApexErrorEvent-hendelser for å håndtere feil- og unntaksscenarier.

En tidsplanutløst flyt er en flyt som er planlagt å utføres på et angitt tidspunkt og med gjentatt frekvens (daglig, ukentlig eller én gang) for å utføre handlinger på en batch med poster. (Eksempel: Oppdater et felt i alle saker med statusen Åpen kl. 14:00 hver natt.) Planlagte flyter utføres via cron-utløsermekanismen og behandles samlet.

• En tidsplanutløst flyt utfører 200 poster per oppkall, men utføres med flere samtidige tråder hvis det finnes flere enn 200 poster.
• Tidsplanutløste flyter utføres i en synkron kontekst med synkrone grenser.
• Det er for øyeblikket ingen måte å kontrollere antall poster som behandles per planlagt flytoppkall. Hvis utførelsen er for flere enn 200 poster, er det en reell fare for samtidige Apex.

Bulk API er basert på REST-prinsipper og er optimalisert for arbeid med store datasett. Du kan bruke den til å sette inn, oppdatere, oppdatere, spørre eller slette mange poster asynkront og behandle resultatet senere. Salesforce Platform behandler forespørselen i bakgrunnen. I motsetning til dette bruker SOAP API og REST API synkrone forespørsler og er optimalisert for sanntidsklientprogrammer som oppdaterer noen få poster om gangen. Du kan bruke begge disse API-ene til å behandle mange poster, men når datasettene inneholder hundretusener av poster, er de mindre praktiske. Bulk APIs asynkrone rammeverk er utformet for å gjøre det enkelt og effektivt å behandle data fra noen få tusen til millioner av poster.

Den enkleste måten å bruke Bulk API er å aktivere den for behandling av poster i Data Loader ved hjelp av CSV-filer. Med Data Loader trenger du ikke å skrive din egen klientapp. Noen ganger krever imidlertid unike krav at du skriver en tilpasset app.

Det finnes to Bulk-API-er tilgjengelig i Salesforce Platform.

• Bulk API 2.0 er den nyere API. Den gir en strømlinjeformet og brukervennlig arbeidsflyt, og er fokus for forbedringer.
• Den opprinnelige Bulk API er fortsatt fullt støttet, men blir ikke lenger forbedret. Vi anbefaler at du bruker Bulk API 2.0 der det er mulig.

Hvis du vil ha mer informasjon om API-grenser, kan du se Bulk API-grenser og Bulk API 2.0-grenser.

Se denne veiledningen når du bygger eller vurderer asynkron behandling på Salesforce Platform. Det er alltid en god idé å forstå hele omfanget av alternativer som er tilgjengelig for deg, og hvordan de kan passe til ditt spesifikke bruksområde. Pass på å vurdere det gjeldende landskapet grundig før du gjør endringer i noen av dine eksisterende arkitekturer, spesielt hvis den gjeldende løsningen fungerer bra.