Salesforce Platform on jatkuvasti kehittänyt automatisointiarkkitehtuuriaan monimutkaisten liiketoimintaprosessien vaatimusten mukaisesti. Aiemmat sukupolvet — Työnkulkusäännöt ja Process Builder — tarjoavat tapahtumiin perustuvan logiikan alustavat vaiheet, laajentavat tapahtumiin perustuvan logiikan automatisointivaihtoehtoja ja laajentavat vaikutusaluetta laajemmille rakentajille.

Tämä kehitys on johdattanut korkean suorituskyvyn yhdistettyyn arkkitehtuuriin, joka keskittyy kahteen täydentävään pilariin: Tietueiden käynnistämät kulut ja Apex. Tämä asiakirja tarjoaa kehyksen ja ohjeet, joilla voit tehdä tietoon perustuvia päätöksiä, kun suunnittelet käynnistimen automatisointeja.

Skaalattavan, ylläpidettävän ja tehokkaan tietueiden käynnistämän automatisoinnin rakentaminen Salesforce Platformissa vaatii kurinalaista ja arkkitehtuuria perustuvaa lähestymistapaa. Kulun ja Apexin välinen valinta ja niiden toteutus perustuvat selkeisiin periaatteisiin. Nämä pisteet tarjoavat yhteenvedon näistä periaatteista ja toimivat modernin automatisoinnin suunnittelun perussääntöinä.

• Valitse työhön sopiva työkalu Salesforce-objektien automatisoinnin tiheyden perusteella.

  • Käytä tietueiden käynnistämää kulkua Salesforce-objekteille matala tiheyden automatisointiin.

  • Laajenna tietueiden käynnistämää kulun logiikkaa kutsuttavalla Apexilla keskitason tiheyden automatisointia varten.

  • Käytä Apex-käynnistimiä Salesforce-objekteille korkean tiheyden automatisointiin.

• Ole varovainen käynnistettäessä ei-synkronoituja prosesseja.
  Tämä sääntö koskee sitä, käytätkö tietueiden käynnistämän kulun ei-synkronoituja prosesseja vai jonotettavaa työtä Apexista. Tämä kuvio voi houkutella töitä, mutta se voi johtaa monimutkaisiin virheiden käsittelyskenaarioihin ja kasvattaa hallintarajoitusten ylittymisen riskiä.

• Käytä yhtä syöttöpistettä per Salesforce-objekti.
  Käytä tietylle Salesforce-objektille yhtä mekanismia automatisoinnin aloituspisteenä. Yritä välttyä kulkujen ja Apex sekoittamiselta samalle objektille.

Kululla ja Apexilla on yhteiset perusominaisuudet. Jokainen työkalu voi kysellä tietueita, suorittaa ehdollista logiikkaa, kohdistaa muuttujia ja suorittaa DML-operaatioita, kuten luoda, päivittää ja poistaa tietueita — järjestyksessä määritetyssä järjestyksessä.

Tämä toiminnallinen päällekkäisyys ei kuitenkaan tarkoita, että työkalut olisivat vaihdettavissa. Arkkitehtuurin valinta ei koske, voidaanko tehtävä saavuttaa, vaan miten se saavutetaan ja mitkä ovat sen pitkän aikavälin vaikutukset suorituskykyyn, skaalattavuuteen ja ylläpitoon. Kulku on erinomainen deklaratiivisessa selkeydessä ja yksinkertaisten prosessien toteutusnopeudessa, kun taas Apex tarjoaa monimutkaisille ratkaisuille tarvittavan tarkkuuden ja raaka-arvon.

Automaation tiheys on tietylle Salesforce-objektille kohdistettu kuorma. Se toimii heuristisena määrittääkseen objektin optimaalisen toteutuksen. Kun automatisoinnin tiheys kasvaa, transaktioiden rajoitusten rikkomisen todennäköisyys kasvaa.

Laske automatisoinnin tiheys tarkastamalla kolme tiettyä määrän ja monimutkaisuuden ulottuvuutta:

• Automaation määrä: Yksilöllisten automatisoinnin metadatamerkintöjen (kulkujen, käynnistimen toimintojen jne.) raaka määrä, joka suoritetaan yhden DML-tapahtuman aikana.

• Tietueen määrä: Tietueita per transaktio, jotka käsitellään API-latausten tai raskaan eräkäsittelyn kautta, kun suorituskyky on kriittistä.

• Riippuvuuden laajentuminen: Alkuperäisen CRUD-toiminnon käynnistämien alempien DML-toimintojen mitta. Se mittaa sen kaavion syvyyden, jossa yksi päivitys vaihdetaan toisiinsa liittyvien objektien päivityksiin (esimerkiksi tapaus → tili → yhteyshenkilö → mukautettu yhteenveto).

Kun Salesforce-sovelluksesi vaikutusalue ja monimutkaisuus kasvaa, sitoudu käyttämään yhtä ensisijaista sisäänpääsypistettä — joko tietueiden käynnistämää kulkua tai Apex. Vältä osioiden automatisoimista useiden mekanismien välillä yhdelle Salesforce-objektille, koska se aiheuttaa heikkoa ylläpitokelpoisuutta ja hajanaista hallintaa.

Käytä tätä matriisia määrittääksesi vaaditun arkkitehtuurin standardin Salesforce-objektillesi.

• Tietueiden käynnistämä kulku on suositeltu ratkaisu pienelle automatisoinnin tiheydelle. Se tarjoaa tehon ja helppokäyttötilan tasapainon, joka soveltuu erinomaisesti suoraviivaisiin ja toisistaan riippumattomiin automaatioihin.

• Hybridikuvio (tietueiden käynnistämä kulku, jossa on kutsuttava Apex) on tehokas ja ylläpidettävä vaihtoehto keskipitkän tiheyden automaatioille, joiden monimutkaisuus kasvaa. Tämä kuvio sallii tiimien ylläpitää järjestettyä koreografiaa deklaratiivisessa kulussa, kun he delegoivat raskaita laskentatoimintoja Apexiin, tasapainottaen käytettävyyden ja suorituskyvyn.

• Apex-käynnistimet tarjoavat tarvittavat rakennuspalikat kiinteälle arkkitehtuurille, joka tukee korkean tiheyden automaatioita. Apexin suorituskyky, tarkka hallinta ja objektikohtainen abstraktio ja polymorfismi soveltuvat paremmin näiden skenaarioiden monimutkaisuuden ja skaalan hallintaan.

Ota myös DML-toimintojen päivittäinen kokonaismäärä huomioon, koska Salesforce noudattaa jaettujen resurssien hallintaa usean vuokralaisen ympäristössä ja hallintarajoituksia estääkseen automaattisia automaatioita monopolisoimasta jaettuja resursseja. Salesforce-objektit, joiden päivittäinen DML-määrä on suuri, vaativat huolellisen automatisoinnin. Esimerkiksi ei-synkronoitujen CPU-aikojen (60 000 ms) ja pinon koon (12 Mt) rajoitukset ovat synkronoituja rajoituksia korkeampia. Lisäksi ei-synkronoitujen suoritusten organisaationlaajuinen 24 tunnin rajoitus — joka lasketaan 250 000 käyttäjälisenssillä, eli 200 kertaa käyttäjälisenssisi — edellyttää, että arkkitehtuurisuunnittelusi huomioi päivittäisen DML-tiedoston kokonaismäärän välttyäksesi suorituksen aikaisilta poikkeuksilta.

Tietueiden käynnistämä kulku on sovellusalustan ensisijainen deklaratiivinen työkalu tietueiden käynnistämää automatisointia varten. Kulun helppokäyttöisyys ja sisäänrakennetut sovellusalustan suojausasetukset sallivat tiimien luoda helposti skaalattavia ja luotettavia ratkaisuja. Se on ihanteellinen valinta useimmille tiimeille, jotka rakentavat ratkaisuja Salesforce Platformilla.

Apex on sovellusalustan oma, vahvasti kirjoitettu ja objektiin suuntautunut ohjelmointikieli. Käytä Apex for Salesforce -objekteja, joiden automatisointi on tiheää, ja käyttötapoja, jotka vaativat korkeaa suorituskykyä, hienostunutta logiikkaa tai transaktioiden tarkkaa hallintaa.

Tämä matriisi tarjoaa suoran vertailun kulusta ja Apexista tärkeimpien rakenteellisten ominaisuuksien välillä päätöksentekoprosessin helpottamiseksi.

Tämä taulukko tarjoaa yleisiä ”best-fit”-suosituksia yleisille käyttötarkoituksille esitettyjen ominaisuuksien perusteella. Lopuksi otat huomioon muita huomioitavia asioita löytääksesi sopivimman vaihtoehdon tietyille skenaarioillesi, kuten tämän asiakirjan Liittyvät suositellut käytännöt -osiossa olevat skenaariot. Täältä saat lisätietoja siitä, milloin kulun ja Apexin tietty yhdistelmä tarjoaa parhaan tavan.

Skaalattavuus on tärkeä asia toteutuksesi suunnittelussa. Kun tietueiden käynnistämän automatisoinnin liiketoimintalogiikka muuttuu monimutkaiseksi, pitkäaikaiseksi tai sisältää suuria datamääriä, Salesforce Platformin ydinhallintarajoituksista tulee arkkitehtoninen rajoitus. Toimintojen, kuten datan joukkopäivitysten, monimutkaisten API-kutsujen tai raskaiden laskutoimien, riski lisääntyy rajoitusten rikkomisesta, kuten kokonaisprosessiaika tai DML-lausuntojen määrä yhdessä tietokantatransaktiossa. Synkronoidun käynnistimen virhe rajoituspoikkeuksen vuoksi aiheuttaa käyttäjän koko tallennustapahtuman peruuttamisen, mikä aiheuttaa heikon käyttökokemuksen ja mahdollisen datan katoamisen. Tämä luontainen riski vaatii arkkitehtuurikuvion monimutkaisten töiden tyhjentämiseksi.

Ei-synkronoitu automatisointi on tässä tapauksessa välttämätöntä. Ei-synkronoitujen mekanismien avulla arkkitehtit voivat irrottaa pitkäaikaiset tai raskaat työt ensisijaisesta synkronoidusta tietueen tallennustapahtumasta tehokkaasti. Tallentaa valmiiksi nopeasti ja luotettavasti, kun taas raskas käsittely delegoidaan erilliseen, sovellusalustan hallittuun transaktioon, joka suoritetaan myöhemmin. Irrottaminen parantaa vakautta, estää transaktioiden virheitä ja on tärkeää skaalattavien yrityssovellusten rakentamisessa. Sovellusalusta tarjoaa tähän useita erikoistuneita työkaluja, joilla jokaisella on omat etunsa ja kompromissinsa luotettavuuden, määrän ja monimutkaisuuden osalta.

Tietueiden käynnistämän kulun Suorita ei-synkronoidusti -polku tarjoaa yksinkertaisimman mekanismin ei-synkronoidulle "tule ja unohda" -logiikalle. Tämä polku suoritetaan erillisessä transaktiossa, kun alkuperäinen tietueen tallennustransaktio on sitoutettu onnistuneesti tietokantaan.

• Ideaalinen käyttötarkoitus: Tämä soveltuu hyvin tehtäville, jotka eivät vaadi välitöntä suoritusta tai mukautettua virheiden käsittelyä. Voit esimerkiksi lähettää sähköposti-ilmoituksen, luoda seurantatehtävän tai tehdä yksinkertaisen kutsun ulkoiseen järjestelmään.

• Rajoitukset: Tällä mekanismilla on samat päivittäiset hallintarajoitukset kuin muilla ei-synkronoiduilla kulkujen haastatteluilla. Sitä ei ole suunniteltu erittäin raskaan käsittelyn käyttöön.

Muutosdatan datan taltiointi (CDC) on tehokäyttöinen, skaalattava ja joustava kuvio, jolla käsitellään ei-synkronoitua logiikkaa, joka käynnistyy tietueen muutoksesta raskaan määrän skenaarioissa. Tässä mallissa käynnistimen ainoa vastuulla on tallentaa tietue synkronoidusti. Sen jälkeen sovellusalusta julkaisee yksityiskohtaisen tapahtumaviestin, joka sisältää tietueen muutokset raskaan tapahtumaväylään. Tämä muutostapahtuma tilataan erillisellä Apex. Se suorittaa monimutkaisia, pitkäaikaisia tai ei-synkronoituja töitä.

• Edut: Tämä kuvio irrottaa ei-synkronoidun prosessin ensimmäisestä käyttäjätapahtumasta. Ei-synkronoidun käsittelyn virhe ei palauta käyttäjän tietueen tallennusta. Kuvio tarjoaa myös kestävän tapahtumaketjun, jota useat sisäiset tilaajat tai ulkoiset järjestelmät voivat kuluttaa, ja tapahtumia voidaan toistaa jopa 72 tunnin ajan, mikä tarjoaa vahvan joustavuuden.

• Rajoitukset: CDC-tapahtumaviestit eivät sisällä tietueen aiempaa tilaa, joka vastaa Apex Trigger.oldMap -arvoa. Tapahtuman tietosisältö sisältää uudet kenttäarvot, mutta ei niiden arvoja. Tämän vuoksi on vaikeaa toteuttaa logiikkaa tietyn tilan siirtymisen perusteella (esimerkiksi suorittaa vain, jos Status__c muuttui arvosta Odottava arvoon Hyväksytty). Voit vähentää tätä kyselemällä objektin kenttähistoriaa tapahtuman tilaajasta, mutta tämä monimutkaistaa prosessia ja kenttähistorian seuranta ei välttämättä ole käytettävissä haluamallesi kentälle. Tämä saattaa rajoittaa automaatioiden tyyppejä, joita voit ladata CDC:hen.

CDC voidaan ottaa käyttöön oletusarvoisesti enintään viidelle Salesforce-objektille. Organisaatiot, jotka tarvitsevat enemmän, voivat ostaa lisäosalisenssin, joka poistaa tämän rajoituksen ja kasvattaa tapahtumien toimitusrajoituksia.

Jonotettavan Apex asettamista suoraan käynnistimestä tulisi pitää riskialttiana kuviona, jota käytetään vain, kun Apex tarjoamaa hallintaa tarvitaan (esimerkiksi monimutkaista logiikkaa tai mukautettuja uudelleenyritysmekanismeja varten), eikä CDC ole toimiva vaihtoehto.

Jos Apex vaaditaan jonoon, toteutuksen täytyy sisältää asianmukaiset suojausasetukset:

• Rajoitustarkistukset: Koodin täytyy tarkastaa transaktiossa jo käytettyjen töiden määrä ennen kuin yritetään lisätä toista.

• Kontekstien tietoisuus: Koodin täytyy havaita, suoritetaanko se ei-synkronoidussa asiayhteydessä, kuten erätyössä (System.isBatch()), ja muokata sen toimintatapaa noudattaakseen tiukempaa yhden työn per transaktio -rajoitusta asiayhteydessä.

Ei-synkronoidun Apex kutsuminen synkronoidusta käynnistimestä aiheuttaa vakausriskejä. Tämä kuvio vaatii tarkkaa suunnittelua ja testausta estääkseen organisaatiotason vaikutukset (esimerkiksi rajoitusten ylittymisen).

• Ei-synkronoitujen Apex-suoritusten (Batch, Queueable, @Future) päivittäinen rajoitus on jaettu organisaatiossa (tavallisesti 250 000 tai käyttäjälisensseihin perustuva laskenta). 20 000 tietueen joukkodatan lataus aiheuttaa käynnistimen suorittamisen 200:ssa erässä, jolloin käynnistimen kutsuja tapahtuu 100 erikseen — vielä enemmän, jos erän joukko on alle 200 tietuetta. Jos jokainen kutsu asettaa jonoon ei-synkronoidun työn, yksi datan lataus voi kuluttaa merkittävän osan päivittäisestä rajoituksesta. Tämä kulutus voi vaarantaa muut asynkronisten resurssien kriittiset liiketoimintaprosessit.

• Työn asettamisen hallintarajoitukset vaihtelevat huomattavasti asiayhteyden mukaan. Käyttäjän käyttöliittymän toiminnon käynnistämästä käynnistimestä — eli synkronoidusta transaktiosta — voidaan asettaa jonoon enintään 50 työtä. Erä-Apex-luokan execute-metodissa käynnistetystä käynnistimestä — eli asynkronisesta transaktiosta — voidaan kuitenkin noutaa vain yksi jonoon lisättävä työ. Tämän eroavaisuuden huomioimatta jättäminen on yleinen ja kriittinen virhepiste, joka aiheuttaa LimitException-virheitä suurten datatoimintojen aikana.

• Ajoitettavan Apexin (System.schedule) tai erä-Apexin (Database.executeBatch) kutsuminen suoraan käynnistimien asiayhteydestä on anti-kuvio. Näitä menetelmiä ei ole suunniteltu kutsuttaviksi käynnistimien kontekstista. Tämä aiheuttaa asynkronisen Apex nopean kulutuksen, mikä rajoittaa poikkeuksia.

Jokaisella ei-synkronoidulla mekanismilla on tiettyjä kompromisseja suorituskyvyn, hallintarajoitusten ja luotettavuuden osalta. Käytä tätä päätöspuuta oppaanasi selataksesi näitä vaihtoehtoja ja valitaksesi käyttötarkoitukseesi sopivan mekanismin.

Kuten kulkukaavio osoittaa, kun sinulla on suuria määriä DML-operaatioita, mutta et voi käyttää Muuta datan taltiointia (mahdollisesti objektien rajoitusten vuoksi), paras arkkitehtoninen valinta on usein välttää käynnistimen kutsumat prosessit kokonaan.

Harkitse sen sijaan ajoitetun prosessin käyttämistä. Tämä voi olla joko ajoitettu kulku tai ajoitettu Apex. Pakolliset vaiheet ovat:

1. Suorita yksinkertainen ja edullinen päivitys synkronoidussa käynnistimessä. Voit esimerkiksi määrittää Status__c-kentän arvoksi "odottavat käsittelyä" tai lisätä edullisen tietueen, kuten Chatter-viestin, osoittaaksesi, että tietue vaatii käsittelyä.

2. Luo ajoitettu työ, joko ajoitettu kulku tai ajoitettu Apex, joka suoritetaan säännöllisesti, esimerkiksi 15 minuutin välein tai tunnin välein.

3. Käytä kaikkien tietueiden ajoitettua työkyselyä odottavassa tilassa, suorita monimutkainen logiikka hallittavassa ja raskaassa asiayhteydessä ja päivitä tietueet käsiteltynä.

Tämä kuvio irrottaa raskaan käsittelyn kokonaan käyttäjän synkronoidusta tallennuksesta, se ei ole käynnistimen käynnistämän erän yhden työn per transaktio -rajoituksen alainen ja tarjoaa erittäin skaalattavan ja hallittavan ratkaisun ei-reaaliaikaisille vaatimuksille.

Jos ajoitetun työn viive ei ole hyväksyttävä liiketoimintavaatimuksille ja et silti voi käyttää CDC:tä tai käynnistimen käynnistämää jonoa, tämä osoittaa merkittävän arkkitehtuurin vastaavuuden. Tässä vaiheessa täytyy huomioida eri mekanismeja. Sovelluksen ydinsuunnittelun arvioiminen uudelleen voi johtaa tiettyihin johtopäätöksiin, kuten:

• Lisäosan ostaminen CDC-objektien rajoitusten poistamiseksi.

• Perusteellisesti haastaaksesi liiketoimintavaatimusta määrittääksesi, onko lähes reaaliaikainen käsittely todella "tarvittava" vai onko ajoitetun työn viive hyväksyttävä kompromissina sovellusalustan vakaudelle.

Toteutuksen monimutkaisuustaso on osa ratkaisun kokonaiskustannuksia ja sen kykyä sopeutua muuttuviin liiketoimintavaatimuksiin. Monimutkaisuus voi vaikuttaa mihin tahansa toteutukseen, jos suositeltuja käytäntöjä ei noudateta. Tämän asiakirjan Liittyvät suositellut käytännöt -osiossa on suosituksia ratkaisusi monimutkaisuuden vähentämiseksi, mukaan lukien seuraavat kuvioet:

• Hybrid Pattern: Kutsuttava Apex monimutkaiselle logiikalle kulussa

• Metadata-kehyksen käyttäminen Apex

• Mega-kulut vs. Useat kulut

Dokumentaatio on yhtä tärkeä kuin itse automatisointi. Se ei ainoastaan varmista ylläpitokelpoisuutta, vaan se on tärkeää myös tekoälylle ja agentteihin perustuville työkaluille. Dokumentaatio auttaa sinua ymmärtämään ja hallitsemaan liiketoimintaprosessejasi.

Kulussa

• Laadi yhdenmukainen nimeämiskäytäntö kaikille elementeille ja muuttujille.

• Käytä kulun Kuvaus-kenttää selittääksesi sen yleistä käyttötarkoitusta, käynnistimen ehtoja ja suunniteltua lopputulosta.

• Käytä kunkin yksittäisen elementin (esimerkiksi Get Records, Action, Transform) Kuvaus-kenttää. Tämä käytäntö on paras tapa välittää tarkoitusta. Se on erityisen tärkeää kutsuttavissa toiminnoissa ja alakuluissa, joissa kuvaus on ensisijainen paikka selittää toiminnon monimutkaista logiikkaa.

Apexissa

• Kommentoi koodiasi selkeästi selittääksesi logiikkasi perustana olevan syyn, äläkä vain sen mitä.

• Jos käytät metadataan perustuvaa kehysjärjestelmää, varmista, että metadatatietueesi sisältävät ja täyttävät ihmiselle luettavan Kuvaus-kentän selittääksesi, mitä kukin käsittelijäluokka tekee ja milloin sen tulisi suorittaa.

DevOps ja lähdekoodin hallinta ovat osa kehityksen kypsää elinkaarta. Käytä aina lähdekoodin hallintatyökalua, kuten Git Salesforce-projekteille. Sekä Apex että Salesforce-kulut ovat metadataa, joka määrittää liiketoimintalogiikkasi, ja ne täytyy versioida ja hallita.

Nykyinen DevOps-putki tarjoaa tärkeitä etuja tietueiden käynnistämien automatisointien hallinnassa.

• Automaattiset laatutarkistukset: Voit määrittää työkalut, kuten Salesforce Code Analyzer, suoritettavaksi automaattisesti myyntiputkessasi. Staattinen analyysi voi havaita ongelmallisia kuvioita molemmissa automatisointityökaluissa ennen niiden ylentämistä, mikä merkitsee ongelmia, kuten kulun silmukan sisällä olevat tehottomat Get Records-elementit tai silmukan Apexin sisällä olevat SOQL-kyselyt, jotka ovat yleisiä suorituskyvyn heikentymisen syitä.

• Regressiovastainen: Kun automatisointitiheys kasvaa, yhden kulun tai Apex muuttaminen voi aiheuttaa tahattomia seurauksia saman objektin muille automatisoinneille. Vahva DevOps-testausstrategia, jossa automatisoidut Apex suoritetaan ehdotettuihin muutoksiin, on luotettavin tapa varmistaa, että uusi kulkuversio ei rikko olemassa olevaa Apex (ja päinvastoin).

• Yhteistyö ja näkyvyys: Lähdekoodin hallinta on "yksittäinen totuuden lähde". Se sallii pääkäyttäjien ja kehittäjien työstää automatisointia samalle objektille rinnakkain. Se tarjoaa myös arvokasta tilintarkastuspolkua: kun tuotantoprosessi rikkoutuu, näet välittömästi, kuka muutti automatisointia, kun hän muutti sitä ja — sitoutusviestien kautta — miksi hän muutti sitä.

Tiimeille, joilla on pääkäyttäjiä ja kehittäjiä, DevOps Center tarjoaa yhtenäisen käyttöliittymän, joka auttaa koreografoimaan kaikki nämä vaiheet, jolloin skaalattava, lähdekoodin hallintaan perustuva kehitysprosessi on kaikkien tiimin jäsenten käytettävissä.

Tämä dokumentaatio- ja DevOps-ominaisuuksien yhdistelmä varmistaa organisaatiosi pitkän aikavälin kunnon ja ylläpidon, mikä hyödyttää kaikkia sinua seuraavia arkkitehtejä ja pääkäyttäjiä.

Yllä olevaa päätöspäivitystä kannattaa käyttää ennen toteutuksesi suunnittelua. Sen tavoitteena on auttaa sinua valitsemaan sinulle sopivin tuote. Tuotteen valinnan jälkeen on tärkeää ymmärtää olemassa olevat toteutuksesi suositellut käytännöt.

Yksi työkalu per objekti -periaate on kriittinen korkean tiheyden automatisoinnin hallinnassa, mutta älä tulkitse sitä binaarina valintana puhtaasti deklaratiivisen tai puhtaasti ohjelmallisen pinon välillä. Tehokkaampi ja ylläpidettävä arkkitehtuurikuvio hyödyntää hybridimallia: aseta tietueiden käynnistämä kulku orkestrointikerrokseksi ja kapseloi monimutkaisia toimintoja kutsuttavassa Apexissa.

Tietueiden käynnistämä kulku toimii liiketoimintaprosessin orkestrointikerroksena. Se omistaa syöttöehdot ja suorituksen kontekstin (mitä ja miten). Kun päätöslogiikka ja reititys säilytetään tässä kerroksessa, arkkitehtuurin prosessien topologia pysyy läpinäkyvänä ja hallittavissa Flow Trigger Explorerin kautta, mikä estää kriittisen liiketoimintalogiikan piilottamisen koodissa.

Monimutkaisen komponentin yleinen esimerkki on palvelutasosopimusten (SLA) laskentojen toteuttaminen tapaustietueille. Koska BusinessHours-objekti ja siihen liittyvä logiikka — jotka ovat tärkeitä tarkkojen laskutoimien kannalta, jotka eivät sisällä työaikoja ja lomia — eivät ole oletusarvoisesti käytettävissä kulussa, käytetään Apex. Tämä luokka, jota kutsutaan usein esimerkiksi ServiceLevelAgreementCalculator-nimellä, on suunniteltu käyttämällä yhtä staattista menetelmää, joka on merkitty @InvocableMethod-merkinnällä, laskeakseen kuluneet toimistoajat, määrittääkseen, onko palvelutasosopimus ”Tavoitteen sisällä” vai ”Hylätty”, ja palauttaakseen rakenteellisen tuloksen. Tämä lähestymistapa kapseloi monimutkaisen, tehokkaan logiikan Apexiin ja sallii sen suorituksen saumattomasti ja integroinnin tietueiden käynnistämän kulun deklaratiiviseen orkestrointikerrokseen.

Kun Apex ServiceLevelAgreementCalculator -luokka on määritetty, se on käytettävissä tietueiden käynnistämässä kulussa:

Tämä kuvio osoittaa, että huolenaiheet on eroteltu tarkasti. Deklaratiivista kerroksia käytetään transaktion elinkaaren ja orkestroinnin hallintaan, kun taas koodia käytetään monimutkaiseen suoritukseen. Kohtelemalla koodia toiminnallisena apukohteena sen perustana, tasapainotamme suorituskykyä ja ylläpitoa.

Modulariteetti: Päätös pivotoi pois Apexin tai kulun käyttämisestä koko prosessille. Sen sijaan arkkitehtuuri kapseloi monimutkaisen logiikan erillisiksi, joukkoturvallisiksi ja itsenäisesti testattaviksi yksiköiksi. Nämä yksiköt toimivat deklaratiivisen kerroksen kuluttamina uudelleenkäytettävinä komponentteina, mikä varmistaa, että automatisointi skaalataan monimutkaistamatta arkkitehtuurin suunnittelua.

Uusikäytettävyys: Logiikka irrotetaan käynnistintäpahtumasta. Hyvin suunniteltu koodiyksikkö (kuten InvocableMethod) kirjoitetaan kerran, mutta se hyödyntää useita syöttöpisteitä: Tietueiden käynnistämät kulut, ruutukulut tai ulkoiset integraatiot. Tämä koodin uudelleenkäyttö välttää tarpeettoman kehityksen.

Ylläpito: Prosessien kulun logiikka pysyy näkyvissä ja hallittavissa deklaratiivisessa kulussa. Tämä keskittäminen vähentää virheenkorjausta huomattavasti ja varmistaa, että järjestelmän suoritusjärjestys on deterministinen ja läpinäkyvä.

Vaikka kutsuttavan Apex käyttämisen hybridimalli kulusta on tehokas, se ei sovellu kaikille. Arkkitehtien täytyy olla tietoisia tietyistä rajoituksista ja kompromisseista ennen kuin he sitoutuvat hybridiratkaisuun.

• Ei tukea ennen tallennusta: Tämä on tärkein rajoitus. Kutsuttavat toiminnot ovat käytettävissä vain tallennuksen jälkeisessä asiayhteydessä (toimintojen ja niihin liittyvien tietueiden kulut). Niitä ei voi käyttää korkean suorituskyvyn ennen tallennusta -kontekstissa (kulut, jotka nopeuttavat kenttäpäivityksiä). Siksi tätä kuviota ei voi käyttää saman tietueen kenttäpäivitysten delegoimiseen. Suorita tämä tehokas työ käyttämällä natiivisia kulkuelementtejä ennen tallennusta tai Apex ennen kontekstia.

• Ei poistamisen peruuttamisen jälkeistä tukea: Tietueiden käynnistämä kulku ei tue poistamisen jälkeistä asiayhteyttä tällä hetkellä. Jos Salesforce-objektilla on liiketoimintavaatimus suorittaa automaatio, kun tietue palautetaan roskakorista, Apex on ainoa ratkaisu.

• Suorituskykymittari raskaan tilan skenaarioissa: Siirtyminen kulun runtimesta Apex runtimeen ei ole nollakustannustoiminto. Yleisesti ottaen nopea, Kutsuttava toiminto -toiminnon siirtäminen kulun suorituksen aikana ei ole yhtä laskutoimittaisesti nopeaa kuin natiivinen suoritus, joka pysyy kokonaan Apex. Useimmissa keskipitkän tiheyden automaatioissa tämä mikrohyökkäys on vähäinen ja hyödyllinen kompromissi käytettävyyden parantamiseksi. Äärimmäisen suuren suorituskyvyn ja suurten volyymien skenaarioissa pelkkä Apex kehysjärjestelmä tarjoaa kuitenkin raaka-arvoisen laskentajakson edun.

Vaikka automatisoinnin tiheyden heuristiikka tarjoaa lopullisia ohjeita uudempaan greenfield-arkkitehtuuriin, yritysympäristöjen Salesforce-ympäristöjen todellisuus on usein hienovaraisempi. Kypsissä organisaatioissa on tavallista löytää tietueiden käynnistämiä kulkuja ja Apex, jotka toimivat samalle Salesforce-objektille. Tämä skenaario eroaa aiemmin kuvatusta hybridikuviosta: tässä tapauksessa kulut ja Apex eivät ole yhdistettyjä tai suunniteltuja toimimaan yhdessä.

Tämä yhteistoiminta johtuu usein sovellusalustan kehittyvistä ominaisuuksista tai vanhoista teknisistä velvoitteista. Vaikka tämä on sallittu toiminta-tila, arkkitehtien täytyy käsitellä sitä lasketuksi kompromissiksi eikä lopulliseksi tilaksi.

Jakattu orkestrointi aiheuttaa merkittäviä hallinta- ja ylläpitokustannuksia, jolloin kehitys-, testaus- ja vahinkotapahtumien käsittelytoiminnot ovat hajanaisia ja hankaloittavia. Tämä parantaa ratkaisuaikaa (TTR) ja monimutkaistaa toimintaa.

• Noudata uusien Salesforce-objektien ensisijaisena oppaana automatisoinnin tiheyden periaatetta.

• Jos olemassa olevilla Salesforce-objekteilla on hybridijalanjälki ja kaksinkertainen Apex ja tietueiden käynnistämät kulkujen sisääntulopisteet, arvioi tiheys ja rakenna sitten refaktori ylläpidettäväksi hybriditilaan.

  • Jos tiheys on alhainen, refaktori Apex käynnistää tietueiden käynnistämät kulut ja määrittää suoritusjärjestyksen, jolloin ne siirtyvät yhteen automatisoinnin sisääntulopisteeseen.

  • Keskiarvoisella tiheydellä refaktorin monimutkaiset megakulut kulkevat osan kuluista oikeassa järjestyksessä. Ota Apex käyttöön vain ehdottoman välttämättömissä tapauksissa, esimerkiksi asiayhteyden poistamisen kumoamisen jälkeen.

  • Jos tiheys on korkea, suosittele Apex käyttöönottoa.

Kun organisaation liiketoimintaprosessit kehittyvät Salesforce Platformilla, tietueiden käynnistämän automatisoinnin määrä ja monimutkaisuus kasvaa väistämättä. Suositeltu peruskäytäntö on ylläpitää yksi Apex-käynnistin per Salesforce-objekti. Tämä sääntö on kriittinen, koska sovellusalusta ei takaa useiden käynnistimen suoritusjärjestystä samalle objektille samalle tapahtumalle. Tämä rajoitus voi johtaa ei-deterministiseen toimintatapaan, rassiolosuhteisiin ja ongelmiin, joita on vaikea virheenkorjata.

Yhden käynnistimen periaatteen noudattaminen tuo kuitenkin esiin arkkitehtuurin haasteen: miten hallita ja orkestroida kaikkia kyseisestä yksittäisestä syöttöpisteestä kutsuttuja liiketoimintalogiikoita ylläpitämällä ja skaalattavalla tavalla.

Tämän arkkitehtuurin ensimmäinen kehitysvaihe oli Classic Trigger Handler -kuvio. Tässä lähestymistavassa yksi Apex-käynnistin delegoi kaiken logiikkansa vastaavaan käsittelijäluokkaan (esimerkiksi OpportunityTriggerHandler). Tämä menetelmä erottaa logiikan käynnistimen tiedostosta ja tarjoaa kehittäjille deterministisen hallinnan suoritusjärjestyksestä käsittelijäluokan menetelmissä (esimerkiksi afterInsert()).

Vaikka tämä kuvio on parannus, se johtaa usein monoliittisiin käsittelijäluokkiin. Ajan myötä, kun liiketoimintavaatimuksia lisätään, luokka muuttuu suureksi, vaikea hallita ja vaikea testata erillään. Kaikkien yksittäisten prosessien suoritusjärjestys on kovakoodattu yhdessä menetelmässä, jolloin luokka on altis yhdistämisristiriidoille, mikä kasvattaa hallinta- ja ylläpitokustannuksia merkittävästi suuressa yritysympäristössä.

Arkkitehdit siirtyvät käyttämään metadataan perustuvaa käynnistimien kehysjärjestelmää ratkaistakseen modulaarisuuden ja orkestroinnin ydinkysymykset. Tämä on merkittävä arkkitehtuurinen edistysaskel, joka irrottaa automatisointilogiikan itsestään sen suorituskyvyn miten ja kun se suoritetaan.

Tämä kehysjärjestelmä perustuu kolmeen tärkeään etuun:

• Osiointi: Yksittäisen käsittelijäluokan sijaan ydinliiketoimintalogiikka jaetaan pieniksi, atomien Apex-luokiksi (esimerkiksi RecalculateAccountValues- tai NotifySalesLeads-luokaksi), ja jokainen luokka noudattaa Yksittäinen vastuuhenkilöllisyyden periaatetta. Tämä modulariteetti tekee logiikasta helpompaa testata, virheenkorjata ja ymmärtää erillään.

• Järjestys ja koreografia: Suoritusjärjestystä ei ole enää kovakoodattu Apexissa. Sen sijaan se määritetään deklaratiivisesti kokoonpanotietueissa, joita tavallisesti säilytetään mukautetussa metadatatyypissä (esimerkiksi TriggerAction__mdt). Näin pääkäyttäjät voivat muuttaa automatisointitoimintojen järjestystä, lisäämistä tai poistamista muokkaamalla metadatatietuetta, joka ei vaadi käyttöönottoa tai koodin muutosta.

• Bypass-toiminnot: Kehys tarjoaa standardoituja, tarkkoja ohitustoimintoja. Jokainen automatisointitoiminto voidaan määrittää sen metadatatietueen kautta poistettavaksi käytöstä globaalisti tai ohitettavaksi tietyille pääkäyttäjille viittaamalla mukautettuun käyttöoikeuteen.

Tämän jälkeen objektin yksittäinen Apex toimii vain dynaamisena lähettäjänä. Se ei sisällä liiketoimintalogiikkaa, mutta sen sijaan se luo keskeisen MetadataTriggerHandler-luokan. Tämä käsittelijä kyselee mukautettuja metadatatietueita määrittääkseen suoritusjärjestyksen dynaamisesti ja kutsumaan oikeita atomisia Apex määritetyssä järjestyksessä. Automatisointi on yhtenäistetty yhden, läpinäkyvän ja hallittavan kerroksen alle.

Tärkeä etu Apexin käyttämisestä vahvassa kehyksessä on kyky hallita transaktioiden tilaa ja optimoida suorituskykyä poistamalla tarpeettomat työt. Kun logiikka kerääntyy, tallennustilauksen eri automatisoinnit suorittavat samat kalliit operaatiot itsenäisesti, mikä kuluttaa arvokkaita hallintarajoituksia ja pidentää DML-toiminta-aikaa.

Kehysjärjestelmä on suunniteltu vastaamaan tähän ongelmaan kahdella ensisijaisella strategialla:

• Jaettujen tilojen hallinta: Yksittäisen Apex vaikutusalueella staattisia ominaisuuksia ja muuttujia hyödynnetään datan tallentamiseen välimuistiin. Tämä varmistaa, että kalliit toiminnot, kuten kokoonpanoasetuksen SOQL-kysely, suoritetaan vain kerran, vaikka automatisointilogiikkaa kutsuttaisiin useita kertoja eri tietueissa tai käynnistimen vaiheissa. Transaktiorajoitusten kulutus vähenee merkittävästi.

• Sovellusalustan välimuistin käyttöaste: Käytä sovellusalustan välimuistia välttyäksesi kyselemästä koko tietokantaa tiettyjen tietojen varalta, jotta voit ylittää transaktioiden välimuistin käytön. Tämä hallittu, muistissa oleva välimuisti on ihanteellinen datan noutamiseen, joka ei ole primitiivinen, jota lukee usein koodipalvelimessa ja joka on muuttumaton transaktion aikana (esimerkiksi profiilit, roolit, toimistoajat). Käyttämällä Cache.CacheBuilder-rajapintaa järjestelmä tarkastaa ensin välimuistin ja suorittaa tietokantakyselyn vain, jos dataa ei ole, mikä maksimoi suorituskyvyn ja skaalattavuuden.

Käytä aina ennen tallennusta -päivitystä, kun automatisointisi tarvitsee muuttaa vain kenttäarvoja tietueessa, joka käynnistää transaktion. Tämä koskee sekä kulun nopeutettuja kenttäpäivityksiä (joita suoritetaan ennen tallennusta) että Apex asiayhteyden edeltävää logiikkaa (ennen lisäämistä tai ennen päivitystä).

Tämä kuvio toimii hyvin riippumatta käytetystä työkalusta, koska se välttää toisen DML-toiminnon ja rekurssiivisen tallennussyklin. Muutokset tehdään tietueeseen muistissa ennen kuin se sitoutetaan tietokantaan, ja ne tallennetaan osana alkuperäistä transaktiota. Toisen tallennuksen kustannukset, jotka muutoin suorittaisivat koko tallennustilauksen uudelleen ja käynnistäisivät kaiken automatisoinnin uudelleen, poistetaan.

Ei-hallittu rekursio on yleinen virhe päivityksen jälkeisissä käynnistimissä, joissa käynnistimen logiikka suorittaa DML-päivityksen, joka puolestaan aiheuttaa saman käynnistimen käynnistymisen uudelleen. Tämä luo loputtoman silmukan, joka lopulta päättyy hallintarajoituspoikkeukseen. Vaikka staattisia totuusarvo-merkintöjä tai käsiteltyjen tietueiden tunnusten kokoelmia on käytetty historiallisesti estääkseen tällaisen toistumisen, tarkempi ja vahvempi malli on portin logiikkaa vertaamalla kenttäarvoja tietueen uuden ja vanhan version välillä.

Suorita logiikka vain, jos haluamasi kenttä on muuttunut. Tämä estää käynnistintä suorittamasta logiikkaansa myöhemmille DML-operaatioille samassa transaktiossa, jossa kriittinen data pysyy muuttumattomana.

Estä tietueiden käynnistämässä kulussa hallitsematon toistuvuus määrittämällä, että kulku suoritetaan vain, kun tietue päivitetään ehtojen vaatimusten mukaisesti:

Jos päätät käyttää kulussasi syöttöehtojen kaavaa, voit estää epäsuoran rekurssin vertaamalla $Record-globaalia muuttujaa (joka edustaa uusia arvoja) ja $RecordPrior-globaalia muuttujaa (joka edustaa alkuperäisiä arvoja ennen tallennusta). Voit esimerkiksi varmistaa, että kulku suoritetaan vain, jos mahdollisuuden Summa-kenttää on muutettu, käyttämällä tätä syöttöehdoissa:

Vertaa tietueen uudesta versiosta (Trigger.new) saatuja kenttäarvoja tietueen vanhan version (Trigger.oldMap) kenttäarvoihin nähdäksesi, onko etsimäsi muutos tapahtunut. Tämä lähestymistapa varmistaa, että automatisointi toimii automaattisesti ja että se suoritetaan vain tarvittaessa, mikä tekee järjestelmästä tehokkaamman ja estää katastrofaaliset rekursiiviset silmukat.

Hyvin rakennettu Salesforce-organisaatio vaatii yhdenmukaisen ja luotettavan mekanismin, joka ohittaa automatisoinnin. Tämä ei ole valinnainen ominaisuus, mutta se on ydinoperaation vaatimus datan eheyden ylläpitämiseksi ja hallintatehtävien käyttöönotolle.

Ohita kehysjärjestelmä on välttämätön joissakin tilanteissa:

• Kun lataat suuria määriä dataa, jokaisen tietueen käynnistimen käynnistäminen saattaa hidastaa prosessia merkittävästi, aiheuttaa rajoituksia poikkeuksia ja luoda virheellisiä tietueita ja ilmoituksia. Ohitus sallii datan syöttämisen siististi ja tehokkaasti.

• Integrointikäyttäjän täytyy ehkä synkronoida tietoja tietueiden ulkoisesta järjestelmästä. Automatisointi, joka käynnistyy tavallisesti käyttäjän käynnistämälle muutokselle (esimerkiksi sähköpostin lähettäminen tai tehtävän luominen) saattaa olla epätoivottavaa tai tarpeetonta, kun muutos on peräisin toisesta järjestelmästä.

• Pääkäyttäjien tai tukihenkilöstön täytyy ehkä suorittaa tietueisiin korjaavia päivityksiä. Ohita mekanismi sallii heidän tehdä nämä muutokset käynnistämättä vakiomuotoista liiketoimintaautomaatiota, jolla voi olla tahattomia seurauksia.

Mukautetut käyttöoikeudet: Bypass-logiikan käyttöönoton moderni ja skaalattava standardi on mukautetut käyttöoikeudet. Nämä ovat parempia kuin vanhat menetelmät useista syistä:

• Joustavuus: Mukautettuja käyttöoikeuksia voidaan kohdistaa käyttäjille käyttöoikeusjoukkojen kautta. Tämä käytäntö noudattaa Salesforcen nykyaikaista suojaus- ja käyttöoikeusmallia, mikä mahdollistaa tarkkojen ja joustavien kohdistusten. Ohitus voidaan myöntää tietylle käyttäjälle tai jopa väliaikaisesti tietyllä erääntymispäivällä/ajalla.

• Ylläpito: Mukautettujen käyttöoikeuksien käyttäminen välttää profiilien tai käyttäjien kovakoodaamisen automaattiseen logiikkaan. Jos käyttäjän rooli muuttuu tai uusi profiili tarvitsee ohittaa käyttöoikeuden, muutos on yksinkertainen käyttöoikeusjoukon kohdistus, ei koodi tai kulun muokkaus, joka vaatii käyttöönoton.

• ** Skaalattavuus:** Mukautetut käyttöoikeudet tarjoavat skaalattavan kehyksen poikkeusten hallintaan monimutkaisessa käyttäjäkannassa. Ne voidaan kohdistaa käyttäjille käyttöoikeusjoukkojen, käyttöoikeusjoukkoryhmien tai profiilien kautta. Heidän yhteytensä käyttöoikeusjoukkoon tai profiiliin näytetään myös lähdemetadatassa.

Toteutuskuviot: Käytä yhtenäistä ohituskuviota kaikkiin organisaation tietueiden käynnistämiin automaatioihin.

Tietueiden käynnistämän kulun ohittaminen: Tehokkain tapa ohittaa kulku on estää sitä suorittamasta sitä ollenkaan. Tämä saavutetaan lisäämällä ehto kulun syöttöehtoihin.

• Määritä tietueiden käynnistämän kulun Alku-elementissä ehdon vaatimukseksi Kaava arvioidaan todeksi.

  • Lisää kaavojen rakennusohjelmaan mukautetun käyttöoikeuden tarkastus käyttämällä globaalia $Permission-muuttujaa. Yhdistä tarkastus olemassa oleviin syöttöehtoihisi.

    • Kaavakuvio:

  • Tämä kuvio varmistaa, että kulku suoritetaan vain, jos käyttäjälle ei ole kohdistettu määritettyä mukautettua käyttöoikeutta. Tämä tarkastus suoritetaan ennen kuin kulun haastattelu luodaan, mikä tekee siitä tehokkaimman lähestymistavan.

Apex-käynnistimen kehysjärjestelmän ohittaminen: Apexissa voit integroida ohituslogiikan suoraan metadataan perustuvaan käynnistimen kehykseen, jotta voit hallita sitä tarkemmin.

• Mukautetun metadatatyypin TriggerAction__mdt tulisi sisältää tekstikenttä, esimerkiksi BypassPermission__c.

  • Ennen kuin koodi suorittaa toiminnon dynaamisesti MetadataTriggerHandler-luokassa, sen tulisi lukea tämän kentän arvo.

  • Jos kenttä on täytetty, käsittelijä käyttää FeatureManagement.checkPermission()-metodia määrittääkseen, onko tämänhetkisellä oletuskäyttäjällä määritetty mukautettu käyttöoikeus.

  • Jos checkPermission() palauttaa arvon true, käsittelijä ohittaa kyseisen toiminnon ja jatkaa seuraavaan toimintoon järjestyksessä.

  • Tämä kuvio on tehokas, koska se sallii sekä globaalin ohjauksen (jos kaikki TriggerAction__mdt-tietueet viittaavat samaan käyttöoikeuteen) että tarkan toiminnon ohjauksen (jos eri tietueet viittaavat eri käyttöoikeuksiin tai joillakin ei ole ohjausoikeutta ollenkaan).

Se on anti-kuvio, joka yhdistää objektin kaiken automatisoinnin yhteen massiiviseen mega-kulkuun. Yhdistämisellä yhteen kulkuun ja logiikan jakamisella useisiin hyvin ehdoitettuihin kulkuihin ei ole suurta vaikutusta suorituskykyyn. Merkittävimmät suorituskykyennusteet saadaan seuraavista:

• Ennen tallennusta -kulkujen käyttäminen saman tietueen kenttäpäivityksiin.

• Kirjoita tarkkoja syöttöehtoja varmistaaksesi, että kulkuja ei suoriteta muutoksille, jotka eivät vaikuta niiden tiettyyn käyttötarkoitukseen.

Kulunkäynnistimen tutkintaohjelma sallii sinun kohdistaa tilausarvon objektin jokaiselle kululle, mikä takaa järjestyksellisen suoritusjärjestyksen.