Ei-synkronoitu käsittely parantaa skaalattavuutta sallimalla korkeampia rajoituksia per konteksti. Ei-synkronoidut pyynnöt suoritetaan omissa ketjuissaan kulissien takana, jotta käyttäjät voivat jatkaa asiakassivun työskentelyä, kun ei-synkronoidut tehtävät suoritetaan taustalla.

Salesforce Lightning Platform tarjoaa useita ei-synkronoituja teknologioita, joita voidaan käyttää tietyn käyttötarkoituksen ratkaisemiseen. Jokaisella teknologialla on etuja ja rajoituksia, jotka sinun täytyy ottaa huomioon, kun valitset lähestymistapaa kullekin käyttötapaukselle.

Kun valitset toteutettavaa teknologiaa, pidä mielessäsi kolme tärkeää huomioitavaa seikkaa:

1. Ei-synkronoitu käsittely ei ole paras tapa ratkaista ongelmia. On houkuttelevaa ajatella, että prosessi, joka ei vaadi suoraan käyttäjän vuorovaikutusta, on hyvä ehdokas ei-synkronoidulle käsittelylle, mutta siinä on joitakin haittoja. Ensinnäkin ei-synkronoiduilla prosesseilla ei ole palvelutasosopimusta, mikä tarkoittaa, että ei ole takeita siitä, että ei-synkronoitu prosessi suoritetaan määritetyn ajan kuluessa. Toiseksi vastauksen jatkuvaa viiveä ei voida taata. Jos ei-synkronoitu prosessi suoritetaan loppuun tietyn ajan kuluessa, seuraavan prosessin suorittaminen saattaa kestää eri aikaa. Tästä syystä, vaikka käyttäjä ei odottaisi vastausta suoraan, ei-synkronoitu käsittely ei välttämättä sovellu skenaarioosi, jos sinulla on vastauksesta riippuvaisia myöhempiä prosesseja tai jos olet huolissasi siitä, että liian pitkät vastausajat saattavat aiheuttaa datasi epäsynkronoinnin ulkoisen järjestelmän datan kanssa.
2. Ei-synkronoituja pyyntöjä voi käsitellä eri tavoin Salesforce Platformissa, joten varmista, että valitset parhaan tavan. Teknologiat, jotka tukevat asynkronista käsittelyä Salesforce Platformissa, toimivat eri tavalla ”päällikkön alla”, ja jotkin niistä on suunniteltu hyvin tietyille käyttötarkoituksille.
3. Jos teknologia on asynkroninen asiakassivulla, se ei välttämättä tarkoita, että kaikki päätepisteiden käsittely suoritetaan rinnakkain. Riippuen tekemistäsi valinnoista, asiakassovelluksen viestit voidaan joskus edelleen sarjoittaa palvelinpuolelta.

Jos käytät töissä väärää teknologiaa tai väärää teknologiayhdistelmää, voi ilmetä tahattomia seurauksia, jotka poistavat ei-synkronoidun käsittelyn hyödyt. Tämä opas tarjoaa selityksiä ja suosituksia sekä mahdollisia haittoja ja vasta-kuvioita erilaisille ei-synkronoiduille käyttötarkoituksille sekä niiden perustelut. Se tarjoaa myös havaintoja siitä, miten eri ei-synkronoidut toteutustekniikat toimivat ja miten niitä hallitaan Salesforce Platformissa.

Jos päätät, mitä tekniikkaa haluat käyttää, käytettävissäsi on kohdennettu Asynkronisen käsittelyn päätösten opas, joka tarjoaa nopean kartoituksen tyypillisistä käyttötarkoituksista sopivimpaan tekniikkaan.

Salesforce Lightning Platform on kattava tekoälyn perustuva alusta, joka yhdistää työntekijät, itsenäiset tekoälyn agentit, yritystiedot ja sovellukset yhteen luotettuun järjestelmään tuottavuuden ja asiakaskokemuksen parantamiseksi. Se mahdollistaa "aktiivisen yrityksen" luomisen yhdistämällä Customer 360 -sovellukset, Data Cloudin ja Slackin kokonaisvaltaista automatisointia varten.

Tämä asiakirja ei kata muiden ekosysteemien teknologioita, kuten MuleSoft, Informatica, Commerce Cloud, Tableau ja Marketing Cloud.

Huomaa, että tämä opas keskittyy vain asynkroniseen käsittelyyn Salesforce Lightning Platformissa. Jos etsit tietoja ei-synkronoiduista integraatiokuvioista, tutustu tapahtumiin perustuvaan arkkitehtuuriin.

• Varmista ennen asynkronisen käsittelyn käyttämistä, että käyttötarkoituksesi vastaavat kuviota. Ei-synkronoiduilla kuvioilla ei ole palvelutasosopimusta, niihin sovelletaan useita hallintamekanismeja, niillä voi olla kapasiteettirajoituksia, jotka on määritetty lisenssien perusteella, ja ne voivat aiheuttaa käsittelyn viiveitä, koska Salesforce Platformissa ei-synkronoituun infrastruktuuriin kohdistetut resurssit ovat rajallisia. Ota nämä rajoitukset vakavasti huomioon, kun käytät asynkronista käsittelyä skenaarioissa, joissa käyttäjä tarvitsee vastauksen järjestelmästä ennen kuin hän voi jatkaa töitään.
• Asynkroninen käsittely Salesforcen kanssa ei ole ratkaisu rajoittamattomaan skaalautumiseen. Salesforce Platform ei skaalaa loputtomiin ja ei-synkronoituja kuvioita on edelleen rajoitettu. Ei-synkronoitu käsittely käyttää ketjuja, jotka sisältävät asiayhteydestä riippuvaisia tietoja, joita CPU tarvitsee suorittaakseen ohjeiden viestiketjun. Ketjut voidaan suorittaa rinnakkain. CPU:ssa käytettävissä olevien ketjujen määrä on rajoitettu, joten alustalla on käytössä mekanismeja, joilla varmistetaan, että sen käytettävissä olevia ketjuja käytetään mahdollisimman tehokkaasti. Sovellusalustan kulkujen hallintajärjestelmä estää organisaatioita kuluttamasta liikaa ketjuja ja vaikuttamasta negatiivisesti muihin organisaatioihin. Sovellusalustan reilun käytön algoritmi hallitsee organisaation käytettävissä olevien viestiketjujen määrää kullekin tietylle viestityypille.
• Tiedä milloin transaktiot ovat todella asynkronisia. Jotkin arkkitehtuurikuviot toimivat asynkronisesti loppuun asti. Muut prosessit toimivat kuitenkin ei-synkronoidusti asiakassovelluksen tai selaimen puolella, mutta sarjoittavat palvelinpuolen pyynnöt, jotka ovat synkronoitujen hallintarajoitusten alaisia.
• Jos haluat laatia suuria lähteviä integraatioita Salesforce Platformista, käytä sovellusalustan tapahtumia ja kestävää välitysohjelmistoa ei-synkronoidun Apex -kutsujen sijaan. Koska alustalla on käytettävissä rajallinen määrä ei-synkronoituja ketjuja, ei-synkronoidun Apexin kautta lähtevät integraatiot ovat rajoitetusti skaalattavissa. Jos organisaatiollasi on lähteviä integraatioita, jotka sisältävät paljon viestejä, ylittävät käytettävissä olevien viestiketjujen määrän ja joilla on pitkiä käsittelyaikoja, asynkronisen Apexin käyttäminen aiheuttaa väistämättä viiveitä.
• Muista ottaa valvonta käyttöön, kun käytät ei-synkronoitua käsittelyä. Valvonnan avulla voit havaita ongelmia mahdollisimman aikaisessa vaiheessa ja korjata ne ennen merkittäviä suorituskykytapahtumia.
• Tilin tapahtumat, jotka voivat aiheuttaa äärimmäisiä latauksia. Kun suunnittelet ei-synkronoituja prosesseja, varmista, että ne voivat hallita työkuormien ruuhka-aikoja ja ruuhka-aikoja ennakoitavalla tavalla. Mieti, miten toteutuksesi käsittelee odottamattomia tapahtumia, kuten sähkökatkoksia, ja suunnittele tietoturvatoimenpiteitä, jotka vähentävät datan katoamista tai toiminnallisuuden katoamista.

Kun valitset lähestymistavan palvelinpuolen asynkroniseen käsittelyyn, arvioi ensin organisaatiosi vaatimukset ja käytettävissä olevat resurssit. Tavoitteenasi on valita lähestymistapa, joka minimoi toteutuksen ja huoltokustannukset varmistaen samalla skaalattavuuden ja minimoi rikkomusten todennäköisyyden. Tämä tavoite riippuu seuraavissa osioissa kuvatuista teknisistä huomioitavia asioita sekä tiimisi rakenteesta. Harkitse esimerkiksi, onko tiimisi Apex, jotka voivat ylläpitää koodiratkaisusi. Muussa tapauksessa deklaratiivinen lähestymistapa voi olla järkevämpää. Pidä myös mielessäsi, että eri työkaluille voidaan soveltaa erilaisia rajoituksia.

Harkitse ei-synkronoidun tilausprosessin käyttötarkoitusta Salesforcessa. Kun tilaus tallennetaan, se lähettää ulkoiseen varastonhallintajärjestelmään viestin, joka sisältää erityisiä ohjeita tuotteen pakkaamiseen ja lähettämiseen. Tilauksen tehnyt käyttäjä ei tarvitse välitöntä vastausta varaston hallintajärjestelmästä, joten pyyntö voidaan lähettää asynkronisesti. Ei-synkronoitu käsittely sallii käyttäjän jatkaa töitään ilman viiveitä.

Arkkitehtuurissasi huomioitavia asioita:

• Kuinka monta samanaikaista prosessia tarvitaan?
• Miten samanaikaiset prosessit vuorovaikuttavat keskenään?
• Kuinka monta SOQL-kyselyä suoritetaan kussakin prosessissa?
• Kuinka monta DML-operaatiota suoritetaan kussakin prosessissa?
• Kuinka kauan kukin prosessi kestää?
• Kuinka luottamuksellisia prosessit ovat tietyille ajoituksille?

Salesforce Platformin multitenant-arkkitehtuuri eristää ja tukee samanaikaisesti useiden vuokralaisten (organisaatioiden) eri vaatimuksia. Kaikki tässä oppaassa kuvatut ei-synkronoidut Apex suoritetaan samassa ei-synkronoidussa infrastruktuurissa Salesforce Platformissa. He käyttävät viestijonointikehystä, jota hallitsevat kaksi ensisijaista täytäntöönpanomekanismia: kulkujen hallinta ja oikeudenmukainen käyttö.

Kulkujen hallinta ja reilun käytön mekanismit estävät yhtä vuokralaista käyttämästä liian monta palveluresurssia tai jättämästä tarpeeksi resursseja muille vuokralaisille. Vaikka on hyödyllistä ymmärtää, miten nämä mekanismit toimivat, tärkein syy tulisi olla se, että ei-synkronoitujen käsittelyn suositeltujen käytäntöjen noudattaminen, kuten seuraavissa osioissa kuvatut, vähentää merkittävästi ongelmien todennäköisyyttä niiden kanssa.

Sovellusalustan kulkujen hallintajärjestelmä estää yhtä organisaatiota täyttämästä tietyn viestityypin, mikä kuluttaa liikaa ketjut ja vaikuttaa negatiivisesti muihin organisaatioihin. Ennen kuin kehysjärjestelmä lisää uusia merkintöjä viestityyppiin liittyvään jonoon, se tarkastaa jonossa ensimmäiset useat tuhannet olemassa olevat merkinnät. Jos suurin osa olemassa olevista merkinnöistä liittyy samaan organisaatioon ja organisaatiolla on jo merkintöjä myös työntekijäketjuissa, uudet lisätyt merkinnät siirretään jonon perään. Tätä prosessia kutsutaan uudelleenkiinnitykseksi. Uudelleenkiinnitys tapahtuu tavallisesti Apex ja Bulk API -prosesseille, koska ne lisäävät usein suuria määriä merkintöjä jonoihinsa samanaikaisesti.

Sovellusalustan oikeudenmukaisen käytön mekanismi toteuttaa tasoihin perustuvan järjestelmän. Järjestelmä varmistaa, että jokainen Salesforce Platform -organisaatio saa oikeudenmukaisen osan tietyn viestityypin käsittelyaikaa, mukaan lukien Tulevat, Jonossa olevat ja Eräviestit. Jos yksi organisaatio hallitsee tiettyä viestityyppiä samanaikaisesti, kun muut organisaatiot odottavat töiden suorittamista samalle viestityypille, oikeudenmukaisen käytön algoritmi vähentää tietylle viestityypille organisaation käytettävissä olevien ketjujen määrää.

Eräs hyöty ei-synkronoiduista Apex on se, että jotkin hallintarajoitukset, kuten SOQL-kyselyiden rajoitukset ja pinojen koon rajoitukset, ovat korkeampia. Älä kuitenkaan luota liikaa näihin menetelmiin. Asynkroniseen infrastruktuuriin kohdistettujen rajoitettujen resurssien vuoksi Future-, Queueable- ja Apex raskas käyttö voi aiheuttaa käsittelyn viiveitä, jotka johtuvat rajoituksista, jotka perustuvat reilun käytön ja kulkujen hallintaan.

Ei-synkronoitua Apexia käyttävät lähtevät callout-kutsut lasketaan ei-synkronoidun Apexin rajoitukseen. Päivittäinen rajoitus on tällä hetkellä 250 000 tai 200 kertaa soveltuvien käyttäjälisenssien määrä, kumpi niistä on suurempi. Tämä rajoitus voi olla ongelma raskaan käytön tapauksissa. Jos ylität rajoituksen, ei-synkronoidut Apex ja niihin liittyvät lähtevät callout-kutsut epäonnistuvat.

Lisäksi, koska alustalla on rajallinen määrä käytettävissä olevia ei-synkronoituja ketjuja, ei-synkronoidun Apexin kautta lähtevät integraatiot ovat rajoitetusti skaalattavissa. Kaikilla raskailla lähtevillä integraatioilla, jotka ylittävät käytettävissä olevien ketjujen määrän, voi olla pitkiä käsittelyaikoja ja viiveitä.

Harkitse näitä vaihtoehtoisia lähestymistapoja raskaan käytön tapauksissa. API-kutsut, joilla on nämä lähestymistavat, lasketaan päivittäiseen API-pyyntöjen rajoitukseen, joka on merkittävästi korkeampi kuin päivittäinen asynkroninen Apex. Näin ollen nämä lähestymistavat ovat skaalattavissa. Huomaa kuitenkin, että samanaikaisten pyyntöjen määrällä on edelleen fyysisiä rajoituksia, joita mikä tahansa CPU voi käsitellä.

• Middleware Scheduled Pull. Vältä raskaisiin lähteviin integraatiotöihin liittyviä viiveitä käyttämällä middleware-ohjelmistoa noutaaksesi dataa ajoitetusti sen sijaan, että työntäisit sitä ei-synkronoidun Apexin kautta. Middleware, kuten MuleSoft Anypoint Platform, voi käyttää natiivista SOAP API- tai REST API -rajapintaa synkronoidusti, jolloin viiveitä esiintyy vain vähän. Middleware voi myös käyttää natiivia Bulk API -rajapintaa suurille datamääreille.

• Middleware Pull sovellusalustan tapahtuman ilmoituksen kautta. Voit käyttää sovellusalustan tapahtumia sen sijaan, että käytettäisiin tulevia, jonoja tai eräsynkronoimatonta Apexia lähtevien integraatioiden suorittamiseen. Sovellusalustan tapahtuma voi joko toimittaa lähtevät tiedot itse tai neuvoa middleware-työkalua noutamaan vaaditut tiedot natiivin API:n kautta ja toimittamaan ne lopulliseen kohteeseensa. Kumpaakaan näistä lähestymistavoista ei koske asynkronisen Apexin viiveet. Sovellusalustan tapahtumien rajoitukset ovat kuitenkin edelleen voimassa.

Queueable Apex sallii sinun suorittaa Apex, jotka sisältävät laajoja tietokantaoperaatioita tai ulkoisten verkkopalveluiden callout-kutsuja ei-synkronoidusti. Jos haluat käyttää Queueable Apexia, toteuta Queueable-käyttöliittymä ja lisää sitten työ Apex-töiden jonoon. Tämä lähestymistapa varmistaa, että asynkroninen Apex suoritetaan taustalla omassa eristetyssä ketjussaan eikä se viivästytä Apex suorittamista. Jokainen jonoon asetettu työ suoritetaan, kun järjestelmäresursseja tulee saataville.

Jonotettava Apex edustaa asynkronisen Apexin evoluutiota. Se tarjoaa ominaisuuksia, joita tulevat Apex eivät voi käyttää, mukaan lukien:

• Töiden tunnukset: Kun lähetät työn kutsumalla System.enqueueJob-metodia, metodi palauttaa uuden työn tunnuksen. Voit käyttää tätä tunnusta tunnistaaksesi työsi. Voit valvoa sen edistymistä Salesforcen Määritykset-valikon Apex tai kyselemällä AsyncApexJob-objektia.
• Ei-primitivisten tyyppien tuki: Jonotettavat luokat voivat sisältää jäsenten muuttujia, jotka käyttävät muita kuin primitiivisiä datatyyppejä, kuten sObjects-objekteja tai mukautettuja Apex.
• Tuki työnketjuun: Voit ketjuttaa Jonotettavat työt yhteen aloittamalla toisen työn käynnissä olevasta työstä. Tämä tekniikka voi auttaa sinua käsittelemään prosessien sidonnaisuuksiin liittyviä skenaarioita.
• Pienimmän syvyyden hallinta: Voit määrittää jonoon asetettavia töitä, joiden pinojyvyys on enintään, jotta työn ketjut eivät pääty odottamattomaan toistumiseen.
• Deduktoinnin allekirjoitukset: Jonossa olevat työt tarjoavat halutessasi allekirjoituksen identtisten töiden havaitsemiseen ja poistamiseen.
• Määritettävä viive: Voit määrittää enintään 10 minuutin viiveen ennen kuin Jonostava työ suoritetaan.
• Transaktion viimeistäjät: Voit liittää Jonotettava-työhön toiminnon jälkeisen järjestyksen ja suorittaa asiaankuuluvia toimintoja sen tulosten perusteella. Esimerkiksi transaktion viimeistelijä voi asettaa jonon uudelleen jonoon, joka epäonnistui käsittelemättömän poikkeuksen takia enintään viisi kertaa.

Salesforce käyttää jonoihin perustuvaa kehysjärjestelmää ei-synkronoitujen prosessien käsittelemiseen. Tätä jonoa käytetään tasapainottamaan pyyntöjen työkuormia eri organisaatioissa. Varmistaaksesi, että organisaatiosi käyttää tätä jonoa mahdollisimman tehokkaasti:

• Vältä jonottamasta tulevia tai Jonotettavissa-metodeja suoraan toiminnoista, joita suuret määrät loppukäyttäjien toimintoja tai integraation API-kutsuja luovat. Tämä lähestymistapa voi tyhjentää päivittäiset ei-synkronoidut Apex nopeasti, mikä aiheuttaa vakavia liiketoimintavaikutuksia.
• Vältä lisäämästä jonoon useita ei-synkronoituja toimintoja per synkronoitu toiminto. Kun yhdestä synkronoidusta toiminnosta yhdistetään useita ei-synkronoituja menetelmiä, ei-synkronoidut toiminnot suoritetaan usein samanaikaisesti ja ne vaikuttavat rivien lukkojen ristiriitoihin ja/tai rivien lukkojen aikakatkaisuvirheisiin.
• Vältä lisäämästä suuria määriä tulevia tai Jonostavat-metodeja ei-synkronoituun jonoon.
• Varmista, että tulevat ja Queueable-metodit suoritetaan mahdollisimman nopeasti. Mitä kauemmin tuleva metodi kestää suorittaa, sitä todennäköisemmin sen jälkeiset pyynnöt jonossa viivästyvät. Varmista erätöiden nopea suoritus minimoimalla verkkopalveluiden callout-kutsut, hienosäätämällä tulevissa metodissasi käytettyjä kyselyitä ja optimoimalla muita objektien automatisointeja, kuten Process Builder -prosesseja, työnkulkusääntöjä, kulkuja ja Apex.
• Testaa asynkronisia menetelmiäsi laajalti. Käytä ympäristöä, joka luo enimmäismäärän menetelmiä, joita haluat käsitellä. Tämä testaus auttaa sinua määrittämään, kohtaavatko sinulla suorituskykyongelmia vai rajoituksia tuotantoympäristössäsi. Ota myös huomioon kumulatiivisten päivittäisten rajoitusten vaikutukset.
• Käytä Apex tulevien tai Queueable-metodien sijaan käsitelläksesi suuria määriä tietueita. Erä Apex voi käsitellä monimutkaisia ja pitkäkestoisia prosesseja, jotka suoritetaan tuhansille tietueille, ja se voidaan ajoittaa tapahtumaan vapaiden aikojen aikana, kun enemmän resursseja on saatavilla.

Käytä ajoitettua Apexia suorittaaksesi sen määritetyssä ajassa ja toistuvasti cron-lausekkeen määrittämällä tavalla. Vaikka Apexin ajoittaminen cron-lausekkeen kautta on asynkroninen prosessi, sen perustana oleva koodi suoritetaan synkronoidusti, kun työ käynnistyy. Ajoitettu Apex soveltuu hyvin päivittäisiin tai viikoittaisiin huoltotehtäviin.

• Sinulla voi olla vain 100 ajoitettua Apex kerralla. Voit välttyä tältä rajoitukselta käyttämällä ajoitetusti käynnistyvää kulkua, joka kutsuu Apex ajoitetun Apex sijaan.
• Ole äärimmäisen varovainen, jos aiot ajoittaa luokan käynnistimestä. Sinun täytyy voida taata, että käynnistin ei lisää enempää ajoitettuja luokkia kuin rajoitusta. Harkitse erityisesti API-joukkopäivityksiä, ohjattuja tuontitoimintoja, tietueiden joukkomuutoksia käyttöliittymän kautta ja kaikkia tapauksia, joissa useita tietueita voidaan päivittää kerralla.
• Käytä viivästyneitä Jonossa oleva-töitä kertaluonteisille tehtäville, jotka täytyy ajoittaa 10 minuuttia myöhemmin. Tätä lähestymistapaa ei lasketa 100 ajoitetun työn rajoitukseen.
• Ajoitettu Apex suoritetaan synkronoidussa kontekstissa synkronoiduilla rajoituksilla.
• Mieti, kuinka kauan ajoitettu työ kestää. Pitkäaikainen työ saattaa limittyä seuraavan ajoitetun työn alkuun.
• Salesforce ajoittaa luokan suorituksen määritettynä aikana. Todellinen suoritus voi viivästyä palvelun saatavuuden perusteella. Palvelun huoltotyön aikana ajoitetut työt ajoitetaan suoritettavaksi, kun palvelu palautuu.
• Käytä erätöiden ajoittamiseen System.scheduleBatch-funktiota sen sijaan, että sinulla olisi ajoitettu työ, jonka ainoa tarkoitus on määrittää erätyö.

Historiallisesti synkronoituja callout-kutsuja, jotka tehtiin Apex-metodista, joka suoritetaan synkronoitujen Apex-transaktioiden asiayhteydessä, kuten Visualforce-ohjaimessa tai Lightning-komponenttien ohjaimessa, sovellettiin pitkäaikaisia pyyntöjä koskevaa Apex-yhteenvetorajoitusta. Synkronoituja callout-kutsuja ei lasketa enää pitkäaikaisiksi Winter ’19 -julkaisusta alkaen. Vaikka Apex luotiin alunperin ratkaisuna synkronoituihin callout-kutsuihin, jotka johtivat pitkäaikaisiin pyyntöihin, ne tarjoavat myös joitakin lisäetuja.

• Yksi synkronoitu toiminto voi suorittaa enintään kolme jatko-toimintoa. Edellisen jatkamisen täytyy olla suoritettu loppuun ennen kuin uusi jatkamistoiminto suoritetaan.
• Jokainen jatko-toiminto voi suorittaa enintään kolme callout-kutsua, jotka suoritetaan rinnakkain.
• Kun kaikki jatko-toiminnon suorittamat callout-kutsut on suoritettu, sovellusalusta kutsuu jatko-callback-metodia tulosten käsittelemiseksi.

Vaikka jatkamiset suoritetaan asynkronisesti alkuperäisen synkronoidun toiminnon suhteen, Apex ja muiden asynkronisten Apex, kuten tulevien metodien, Jonostavat- tai Erä-ominaisuuksien, välillä on tärkeitä eroavaisuuksia. Tärkeimmät eroavaisuudet ovat:

• Jatkoja ei aseteta jonoon millään tavalla.
• Jatkukset eivät vaikuta päivittäiseen asynkroniseen Apex.
• Jatkaisut vaihtavat sovelluspalvelimen ketjun kontekstin raskaasta Apex ketjusta kevyeksi ketjuksi, joka suorittaa vain callout-kutsuja. Jatkaisut säästävät merkittävästi sovelluspalvelimen muistia suorittaakseen kutsut, jotka voivat kestää enintään 120 sekuntia.
• Alunperin jatkamiset voitiin suorittaa vain Visualforce JavaScript -etäkutsusta. Jatkaisut lisättiin kuitenkin virallisesti Lightning Summer ‘19 -julkaisussa, jolloin Visualforce tarve poistettiin.

Sovellusalustan tapahtumat ovat Salesforce Platformin toteutus, joka perustuu pelkästään tapahtumiin perustuvaan arkkitehtuuriin. Löydät lisätietoja tämäntyyppiseen arkkitehtuuriin liittyvistä komponenteista Arkitehtuurin opas tapahtumiin perustuvaan arkkitehtuuriin.

Sovellusalustan tapahtumat ja sovellusalustan tapahtumien käynnistimet/kulut ovat usein hyviä vaihtoehtoja ei-synkronoidun Apexin käyttämiseen. Ne ovat myös hyvä tapa käynnistää tietojen käsittely sovellusalustan ulkopuolella. Voit esimerkiksi käyttää yhdistelmää Amazon Web Services (AWS) -tapahtumien välittäjiä ja sovellusalustan tapahtumia kutsuaksesi AWS Lambda -palvelimettomia laskentaominaisuuksia. Työt, jotka suoritetaan suhteellisen nopeasti ja ilman kutsuja (jotka eivät ole mahdollisia sovellusalustan tapahtumien käynnistimestä tai kulusta), sopivat hyvin sovellusalustan tapahtumaan/käynnistimeen tai tapahtuman/kulun yhdistelmään.

Bussiin julkaisemisen jälkeen julkaistut tapahtumat toimitetaan järjestyksessä, ja käynnistin tai kulku voi käsitellä niitä joukkona erillisessä synkronoidussa asiayhteydessä. Asiayhteys on synkronoitu ja se noudattaa kaikkia synkronoitujen hallintarajoituksia. Valitse sovellusalustan tapahtumien käynnistin/kulkujen erän koko huolellisesti välttyäksesi rajoitusten ylittymiseltä.

• Kun tapahtumat julkaistaan tapahtumaväylässä, ne ovat kuluttajien käytettävissä. Jos kyseessä on tapahtumien käynnistin (Apex tai kulku), nämä tapahtumat lähetetään käytettävissä oleviin synkronoituihin ketjuihin sovellustasolla (yksi ketju per tapahtumien käynnistin/kulku). Huomaa, että tällä prosessilla ei ole palvelutasosopimusta.
• Kun jonoon lisätään julkaisutoimintoja, jonoprosessin tulokset tallennetaan Database.SaveResult-objektiin. Nämä merkinnät osoittavat vain, onnistuiko jonotoiminto. Jos haluat nähdä tapahtumaväylän kautta julkaistun tapahtuman lopullisen tuloksen, suorita Apex-julkaisun callback-kutsu. Näiden lisätietojen avulla voit päättää muista toiminnoista, kuten yrittää julkaista epäonnistuneita tapahtumia uudelleen.
• Vaikka sovellusalustan tapahtumille ei sovelleta samoja rajoituksia kuin ei-synkronoidulle Apexille, niillä on omat hallintarajoituksensa. Jos sinulla on ongelmia rajoitusten kanssa, voit ottaa käyttöön parannetut tapahtumien käyttötilastot määrittääksesi, käyttävätkö tietyt tapahtumat enemmän rajoituksiasi kuin aiot. Jos haluat parantaa tapahtumien käynnistimien määrää, harkitse yhdensuuntaisten tilausten käyttämistä tapahtumien käsittelemiseksi samanaikaisesti yhden viestiketjun sijaan. Yhdensuuntaisten tilausten avulla voit skaalata Apex Platform -tapahtumien käynnistimiä käsittelemään suuria määriä tapahtumia. Yhdensuuntaiset tilaukset ovat käytettävissä mukautetuille raskaan sovellusalustan tapahtumille, mutta ei vakiomuotoisille tapahtumille tai muutostapahtumille.
• Sovellusalustan tapahtumilla on kaksi julkaisutapaa:
  • Julkaise välittömästi: Tapahtumat julkaistaan välittömästi transaktion aikana, ennen kuin lopullinen tietokanta sitoutuu. Tällä tavalla julkaistuja tapahtumia ei välttämättä julkaista järjestyksessä.
  • Julkaise sitoumuksen jälkeen: Tapahtumat julkaistaan, kun tietokantatransaktio sitoutetaan onnistuneesti. Tällä tavalla julkaistut tapahtumat julkaistaan varmasti järjestyksessä.

Julkaise välittömästi -vaihtoehdon käyttäminen on hyödyllistä käyttötapauksissa, kuten lokiin tallentamisessa, jossa haluat julkaista lokitustapahtuman riippumatta siitä, onnistuiko transaktio ja sitoutuu, tai epäonnistuu ja peruutetaan. On mahdollista julkaista välittömästi sovellusalustan tapahtuma, jonka kuluttaa sovellusalustan tapahtumien käynnistin. Sen jälkeen sovellusalustan tapahtumien käynnistin kilpailee tietokannan rivin lukituksen kanssa sen julkaisseen transaktion kanssa. Tarkasta kaikki suunnittelut huolellisesti ennen sovellusalustan tapahtumien välitöntä julkaisemista varmistaaksesi, että vältyt tältä skenaariolta.

Ei-synkronoidut kulut tarjoavat alhaisen koodin vaihtoehtoja ei-synkronoidulle Apexille. Kuten muut asynkronisen käsittelyn muodot, ne suoritetaan taustalla, kun resursseja on saatavilla. Ei-synkronoiduilla kuluilla ei myöskään ole palvelutasosopimuksia ja niillä voi olla ennustamattomia odotusaikoja.

Ajoitetut polut perustuvat cron-käynnistimiin, jotka suoritetaan tiettynä aikana. Ne suoritetaan, kun tietueita luodaan, päivitetään tai poistetaan, ja ne sallivat sinun hallita tarkasti, milloin sinun tulisi suorittaa automaatio suhteessa tietueen muutokseen. (Esimerkki: lähetä käyttäjälle sähköposti tunti ennen tehtävän erääntymistä). Toisin kuin tulevilla Apex, jotka on rajoitettu synkronoidussa transaktiossa enintään 50 metodiin, ajoitetuilla kulkutoiminnoilla ei tällä hetkellä ole jonojen enimmäisrajoitusta per transaktio. Ajoitetun polun määritelmä sisältää kuitenkin erän koon kokoonpanon, joka sallii jonkin verran hallita, montako tietuetta ajoitettu polun kulun suoritus käsittelee.

Tietueiden käynnistämiin kulkuihin voidaan lisätä asynkronisia polkuja. Ne suoritetaan taustalla eikä ne viivästytä kulun alunperin käynnistäneen transaktion suorittamista. Voit käyttää asynkronista polkua suorittaaksesi pitkäaikaisen toiminnon tai minkä tahansa toiminnon, jonka haluat suorittaa omalla ajallaan. Ei-synkronoidut polut voivat auttaa välttymään yhdistetyiltä DML-virheiltä, jotka tapahtuvat, kun sinun täytyy päivittää tietueeseen liittyvä arvo, joka ei kuulu kulun käynnistäneeseen tietueeseen.

Huomautus: Lähtevä viestintä on vanha ominaisuus ja sovellusalustan tapahtumat (kuvattu edellisessä osiossa) ovat nykyaikaisempi lähestymistapa ja tarjoavat enemmän joustavuutta. Sovellusalustan tapahtumat ovat Salesforcen suosittelema malli tapahtumiin perustuvaa integraatiota varten.

Lähtevät viestit tarjoavat keinon asynkroniseen lähtevään viestintään SOAP API:n kautta. Kun lähtevän viestin määritelmä on määritetty Salesforcessa, se tuottaa SOAP WSDL:n, jonka ulkoinen verkkopalveluntarjoaja voi kuluttaa. Lähtevät viestit voidaan käynnistää työnkulkusäännöistä, Process Builder -prosesseista tai Lightningin kulunkäynnistimistä tallennuksen jälkeen. Lähtevä SOAP-viesti voi sisältää enintään 100 ilmoitusta. Jokainen ilmoitus sisältää objektin tunnuksen ja viitteen siihen liittyvään sObject-dataan. Jos perustana olevan objektin tiedot muuttuvat ilmoituksen jonon jälkeen, mutta ennen sen lähettämistä, vain uusimmat tiedot toimitetaan, eikä väliaikaisia muutoksia.

Kun lähtevän viestin kuuntelija (verkkopalvelu, jonka määritit luodulla WSDL:llä) vastaanottaa viestin, se käyttää siihen sisältyviä istunnon tunnustietoja kutsuakseen Lightning Platform API -rajapintaa päivittääkseen Salesforcessa tietueen, joka käynnisti lähtevän viestin.

• Lähteviä viestejä ei käsitellä Salesforcen jonoihin perustuvan asynkronisen infrastruktuurin kautta, joka suorittaa toimintoja, kuten tulevia metodeja, jonoon asetettavaa Apex, Apex, Bulk API:a jne. Sen sijaan tietueita säilytetään paikallisesti OutboundMessage-objektissa. Viestit lähetetään ja yritetään uudelleen paikallisen ajoitetun taustaprosessin kautta.
• Viestejä ei lähetetä synkronoidusti, kun lähtevän viestin toiminto suoritetaan automaattisesti (esimerkiksi kulunkäynnistin tallennuksen jälkeen). Sen sijaan ne säilyvät OutboundMessage-objektissa, kunnes ne lähetetään onnistuneesti tai kunnes ne jätetään pois 24 tunnin epäonnistuneen toimituksen jälkeen.
• Varmista, että objekteja päivittävällä käyttäjällä ei ole lähetä lähteviä viestejä -käyttöoikeutta välttyäksesi lähtevien viestien loputtomalta silmukalta.

Sähköpostista tapaukseksi -toiminto toimii tavallisesti synkronoidusti. Saapuvien Sähköpostista tapaukseksi -pyyntöjen käsittelyyn on rajoitettu neljä synkronoitua ketjua. Käsittelijän synkronoitu muoto ylläpitää yhteyttä saapuvaan Salesforce-sähköpostipalvelimeen (MTA), joka vastaanottaa sähköpostin. Sähköpostista tapaukseksi -toiminto voidaan kuitenkin käsitellä ei-synkronoidusti seuraavista syistä:

• Sähköpostista tapaukseksi -toimintoon liittyy ketjun rajoituksia, erityisesti 10 käsittelijäketjua yhteensä per sovelluspalvelin: neljä ketjua synkronoidulle käsittelylle ja kuusi ketjua ei-synkronoidulle käsittelylle.
• Jos synkronoidun sähköpostin käsittelijän suoritusaika ylittää 15 sekuntia, kyseinen sähköpostipalveluosoite merkitään ei-synkronoiduksi 30 minuutin ajan. Tämän palvelun osoitteen myöhemmät käsittelijäpyynnöt johtavat viestiin, joka on asetettu MessageTypeName = MAILCATCHER_EMAIL_TO_CASE -kenttään, ja viite sähköpostin sisältöön.
• Jos synkronoitu ketju on jo käytössä tietylle organisaatiolle ja palvelun osoitteelle, sen lisäpyynnöt asetetaan jonoon ei-synkronoidusti.
• Jos synkronoidusti käsiteltävällä sähköpostilla ilmenee virhe, kuten rivin lukituksen aikakatkaisu, pyyntö tallennetaan ja jonotetaan ei-synkronoidusti.
• Jos synkronoituja käsittelijäketjuja ei ole saatavilla, pyyntö asetetaan jonoon ei-synkronoidusti.

• Saatavilla on kopioinnin poistovaihtoehto, kun määrität Sähköpostista tapaukseksi -toiminnon, mutta se ei kumoa liitetiedostojen kopiointia ennen kuin sähköposti on käsitelty. Tämä kopioinnin poistaminen säästää tilaa tietokannassa, mutta se ei vähennä sähköpostien käsittelyaikoja. Voit kuitenkin parantaa suorituskykyä ottamalla käyttöön mukautetun Apex tapaukseksi -käsittelijän viestien käsittelyä varten. Tämä toteutus ei vaikuta hallintarajoituksiin, mutta se myöntää käsittelijälle pääsyn sähköpostiviestiin ja kaikkiin sen liitetiedostoihin ennen kuin mitään sitoutetaan tietokantaan. Tämän käyttöoikeuden avulla voit laskea kaikkien sisällytettyjen liitetiedostojen tarkastussummat ja hylätä kaikki tarpeettomat, mukaan lukien identtiset, tunnetut allekirjoituskuvat tai tarpeettomat tiedostotyypit.
• Sähköpostiliitteiden sitouttaminen Salesforce Filesiin on vastuussa suurimmasta osasta sähköpostin käsittelyaikaa. Kun yhteyshenkilöön tai sen vastaukset kasvavat ja sähköpostiketju kasvaa, myös kunkin sähköpostin käsittelyaika kasvaa. Jos ”Vastaa vain uudella sisällöllä” -vaihtoehtoa ei ole valittu, sähköpostiketjut kasvavat jokaisella vastauksella. Tästä syystä suosittelemme, että käytät Apex tapaukseksi -käsittelijää, joka käyttää logiikkaa, joka toteuttaa liitetiedostojen kopioinnin poistamisen käsittelyaikana.
• Vaikka Apex kutsutaan osana käsittelyä, Sähköpostista tapaukseksi -toiminnon käsittelijät ovat vapautettuja samanaikaisesta Apex.

Jos haluat käsitellä suuria määriä tietueita ei-synkronoidusti, harkitse jonkin seuraavista lähestymistavoista.

Voit käyttää Apex rakentaaksesi monimutkaisia ja pitkäaikaisia prosesseja, jotka sisältävät tuhansia tietueita. Erä Apex toimii jakamalla tietuejoukkosi ja käsittelemällä sen hallittavissa oleviin osioihin. Voit esimerkiksi rakentaa arkistointiratkaisun, joka toimii öisin ja lisää arkistoon tietyn päivämäärän vanhoja tietueita. Voit myös laatia datan puhdistustoiminnon, joka tarkastaa kaikki tilit ja mahdollisuudet öisin ja suorittaa tarvittavat päivitykset esimääritettyjen ehtojen perusteella.

• Apex on paras tapa käsitellä suuria määriä dataa, koska ei-synkronoidulla Apex on korkeammat rajoitukset kuin synkronoidulla Apex. Erä Apex toimii myös tehokkaammin, kun se käsittelee useampia kohteita per erä, koska se käyttää joukkotoimintoja, jotka aiheuttavat vähemmän kustannuksia jonojen hallinnasta. Jos siis haluat välttyä kulun ohjausmekanismin käynnistämiseltä jonojen tulvien kautta ja välttyä päivittäisen asynkronisen Apex käyttämiseltä, älä luo eroja, joiden vaikutusalue on pieni tai joiden käsittelyajat ovat nopeat.
• Vältä jonoittamasta erätöitä suoraan toiminnoista, joita suuret määrät loppukäyttäjien toimintoja tai integraation API-kutsuja luovat. Tämä lähestymistapa voi tyhjentää flex-jonon nopeasti. Jos aiot kutsua erätyötä käynnistimestä, sinun täytyy varmistaa, että käynnistin ei lisää enempää erätöitä kuin rajoitusta.
• Erä Apex on rajoitettu enintään viiteen samanaikaiseen ketjuun, mikä rajoittaa sen läpimenoa paljon enemmän kuin tulevissa menetelmissä tai Jonotettava Apex.
• Suuria määriä dataa sisältävät erätöiden tulisi ajoittaa suoritukseen parhaiten ruuhka-aikojen ulkopuolella vapauttaakseen resursseja prosesseille, jotka vaativat reaaliaikaisia tai lähes reaaliaikaisia vastauksia.
• Kun kutsuit System.scheduleBatch, sovellusalusta ajoittaa työsi suoritettavaksi määrittämäsi ajankohtana. Todellinen suoritus tapahtuu kyseisenä aikana tai sen jälkeen, riippuen palvelun saatavuudesta.
• Ajoituksen suorittaja järjestelmän asiayhteydessä. Kaikki luokat suoritetaan riippumatta siitä, onko suorituksen ajoittaneella käyttäjällä luokan suoritusoikeus.
• Kaikki ajoitetut Apex koskevat System.scheduleBatchilla ajoitettuja erätöitä. Kun erätyö on asetettu jonoon (jos tila on Pidossa tai Jonossa), kaikki erätöiden rajoitukset ovat voimassa eikä työ lasketa enää ajoitettuihin Apex.
• Jos erätyöllä on toistuva aikataulu, harkitse oikeaa toimintatapaa, jos edellinen työ on edelleen käynnissä, kun uusi työ käynnistyy.
• Synkronoiduista Apex-transaktioista kerätyt erätyöt käyttävät flex-jonoa. Flex-jonossa voi olla enintään 100 kohdetta milloin tahansa. Jos transaktio yrittää lisätä enemmän merkintöjä, sovellusalusta luo virheitä eikä lähetä erätyötä.
• Erätöiden callout-kutsujen ja muiden ei-transaktio-toimintojen täytyy noudattaa idempotent-suunnittelussa huomioitavia asioita. Salesforce-palvelun huoltotyön jälkeen jonossa olevat erätyöt pysyvät jonossa. Kun palvelun käyttökatkos on päättynyt ja järjestelmäresursseja on saatavilla, jonossa olevat erätyöt suoritetaan. Jos erätyö on käynnissä käyttökatkoksen aikana, erätyö peruutetaan ja käynnistetään uudelleen palvelun palauttamisen jälkeen. Tästä syystä suoritusmenetelmät voidaan suorittaa useita kertoja, joten kaikkia muita kuin transaktio-operaatioita, kuten callout-kutsuja, voidaan yrittää uudelleen.
• Harkitse erätyön määrittämistä BatchApexErrorEvent-tapahtumien nostamiseksi virheiden ja poikkeusten skenaarioiden käsittelemiseksi.

Ajoitetusti käynnistyvä kulku on kulku, joka on ajoitettu suoritettavaksi tiettynä aikana ja toistuvasti (päivittäin, viikoittain tai kerran) toimintojen suorittamiseksi tietueiden erälle. (Esimerkki: päivitä kenttä kaikissa tapauksissa, joiden tila on "Avoin" klo 14.00 joka yö). Ajoitetut kulut suoritetaan cron-käynnistimen mekanismin kautta ja ne käsitellään joukkona.

• Ajoitetusti käynnistyvä kulku suorittaa 200 tietuetta per kutsu, mutta se suoritetaan useilla samanaikaisilla ketjuilla, jos yli 200 tietuetta on läsnä.
• Ajoitetusti käynnistetyt kulut suoritetaan synkronoidussa asiayhteydessä synkronoiduilla rajoituksilla.
• Tällä hetkellä ei voi hallita käsiteltyjen tietueiden määrää per ajoitettu kulun kutsu. Jos suoritus koskee yli 200 tietuetta, samanaikaisten Apex riski on todellinen.

Bulk API perustuu REST-periaatteisiin ja se on optimoitu toimimaan suurten datajoukkojen kanssa. Voit käyttää sitä lisätäksesi, päivittääksesi, lisätäksesi, kyselläksesi tai poistaaksesi useita tietueita ei-synkronoidusti ja käsitelläksesi tulokset myöhemmin. Salesforce Platform käsittelee pyynnön taustalla. Sitä vastoin SOAP API ja REST API käyttävät synkronoituja pyyntöjä ja ne on optimoitu reaaliaikaisille asiakassovelluksille, jotka päivittävät muutaman tietueen kerralla. Voit käyttää molempia näitä API-rajapintoja käsitelläksesi useita tietueita, mutta kun datajoukot sisältävät satoja tuhansia tietueita, ne eivät ole käytännöllisiä. Bulk API:n asynkroninen kehys on suunniteltu tekemään datan käsittelystä yksinkertaista ja tehokasta muutamasta tuhannesta miljoonaan tietueeseen.

Helpoin tapa käyttää Bulk API -rajapintaa on ottaa se käyttöön tietueiden käsittelemiseen Data Loaderissa CSV-tiedostoilla. Data Loaderin avulla sinun ei tarvitse kirjoittaa omaa asiakassovellustasi. Joskus yksilölliset vaatimukset vaativat kuitenkin mukautetun sovelluksen kirjoittamisen.

Salesforce Platformissa on kaksi Bulk API -rajapintaa.

• Bulk API 2.0 on uudempi API. Se tarjoaa virtaviivaisemman ja helpommin käytettävän työnkulun, ja se on parannusten keskiössä.
• Alkuperäistä Bulk API:a tuetaan edelleen täysin, mutta sitä ei enää paranneta. Suosittelemme, että käytät Bulk API 2.0 -rajapintaa aina, kun se on mahdollista.

Lisätietoja API-rajoituksista on kohdissa Bulk API Limits ja Bulk API 2.0 Limits.

Tutustu tähän opas, kun rakennat tai harkitset asynkronista käsittelyä Salesforce Platformissa. Sinun kannattaa aina ymmärtää, mitä vaihtoehtoja sinulla on käytettävissäsi ja miten ne sopivat tiettyyn käyttötarkoitukseesi. Muista arvioida tämänhetkinen tilasi huolellisesti ennen kuin teet muutoksia olemassa oleviin arkkitehtuureihisi, varsinkin jos tämänhetkinen ratkaisusi toimii hyvin.