Salesforce nam omogoča obdelavo ali izvedbo določenega števila izjav/zapisov hkrati. Obstaja nekaj omejitev za izjave DML, razrede Apex itd., ki jih je treba izvesti ali obdelati. Te omejitve so znane kot meje guvernerja. V tej vadnici bomo videli, kaj so meje guvernerja in kako jih je mogoče obravnavati. Poleg tega Salesforce Apex ponuja razred »Limit« za poznavanje omejitev, ki so povezane z oblački, razredi Apex, spletnimi komponentami Lightning, izjavami SOSL in SOQL.
Meje guvernerja
Razmislite o scenariju, kjer sta Alish in Subash dve osebi, ki uporabljata organizacijo Salesforce. Alice želi obdelati ali izvesti 1000 izjav DML v eni transakciji. Vzporedno želi Subash naložiti 5000 zapisov hkrati. Če to počnejo vzporedno, Salesforce ne bo sprejel in postane grozljiv. Zato pridejo v poštev meje guvernerja. V tem primeru lahko Alish naenkrat obdela 100 DML, Subash pa 500 zapisov naenkrat. Uporabijo lahko AsynchronousBatch Apex za izvedbo vsake transakcije v ločeni niti, ne da bi motili vsakega od njih, in dokončanje njihove naloge.
V bistvu omejitve Guvernerja v Salesforce omejujejo obdelavo in izvajanje v več transakcijah. »Omejitve Apex na transakcijo« štejejo za vsako transakcijo, »Omejitev Apex glede na velikost« pa se ukvarja z velikostjo kode. Salesforce podpira dva procesa: sinhrone in asinhrone procese. V sinhronem procesu se skript Apex izvede v enem koraku, medtem ko se v asinhronem procesu skript Apex izvede z razdelitvijo na več opravil.
Dovoljene meje
Pogovorimo se o številu omejitev za različne scenarije:
- Možno je obdelati/zagnati 100 poizvedb SOQL v sinhronem Apexu in 200 poizvedb SOQL v asinhronem Apexu.
- Samo 50.000 zapisov se bo vrnilo iz poizvedbe SOQL tako za sinhroni kot za asinhroni vrh.
- Če uporabimo Database.getQueryLocator(), se vrne samo 10.000 hkrati za sinhroni in asinhroni Apex.
- V obeh scenarijih je število izdanih poizvedb SOSL 20.
- Velikost kopice, ki je potrebna za obdelavo sinhronega Apexa, je 6 MB. Za asinhroni Apex je zahtevana velikost kopice dvojna, kar pomeni 12 MB.
- Največji čas CPE, ki je dovoljen za sinhroni Apex, je 10.000 milisekund in 60.000 milisekund za asinhroni Apex.
- Za izvedbo obeh Apexov je na voljo samo 10 minut.
- V obeh primerih lahko uporabimo le metodo 10 sendEmail() s 100 prejemniki.
- Znaki, ki so prisotni v razredu Apex ali v sprožilcu Apex, morajo biti znotraj 1 milijona.
- V Batch Apex (asinhrono) je velikost 200. QueryLocator() razreda »Database« vrne 50 milijonov zapisov na transakcijo.
- Samo 5 opravil Apex bo v čakalni vrsti ali aktivnih.
Primer razreda LIMIT:
Apex lahko določi meje guvernerja v razredu »LIMIT«. Ta razred nudi nekaj metod, ki guvernerju povedo meje. Oglejmo si naslednji primer, ki prikazuje nekatere omejitve guvernerja:
System.debug('Število združenih poizvedb, ki jih je mogoče obdelati: '+ Limits.getLimitAggregateQueries());
System.debug('Število stavkov spletne storitve, ki jih je mogoče obdelati: '+ Limits.getLimitCallouts());
System.debug('Število zapisov, ki jih je mogoče obdelati: '+ Limits.getLimitDmlRows());
System.debug('Število stavkov DML je mogoče poklicati: '+ Limits.getLimitDmlStatements());
System.debug('Skupna količina pomnilnika v bajtih: '+ Limits.getLimitHeapSize());
System.debug('Število poizvedb SOQL, ki jih je mogoče izdati: '+ Limits.getLimitQueries());
System.debug('Število zapisov je mogoče izdati: '+ Limits.getLimitQueryRows());
System.debug('Število poizvedb SOSL je mogoče izdati: '+ Limits.getLimitSoslQueries());
Izhod:
Prav tako je mogoče preveriti, koliko izjav/vrstic DML je mogoče vrniti z uporabo metod »kupole«, ki so prisotne v razredu »LIMIT«.
- Limits.getDMLStatements() vrne skupne stavke DML, ki se uporabljajo v primerku.
- Limits.getDMLRows() vrne skupno število vrstic, ki jih vrnejo stavki DML.
- Limits.getCpuTime() vrne čas uporabe procesorja za trenutno transakcijo v milisekundah.
Primer uporabe:
Napišimo poizvedbo SOQL, ki vrne dva zapisa iz predmeta »WorkOrder«. Po tem izbrišite ta dva zapisa z uporabo DML »delete«.
System.debug('Izjave DML:'+Limits.getDMLStatements());System.debug('Vrstice: '+Limits.getDmlRows());
System.debug('Čas procesorja'+Limits.getCpuTime());
// Poizvedba SOQL za izbiro 2 vrstic iz objekta WorkOrder
List
//Uporabite delete DML za brisanje dveh vrstic
brisanje računov;
System.debug('**Po SOQL:**');
System.debug('Izjave DML:'+Limits.getDMLStatements());
System.debug('Vrstice: '+Limits.getDmlRows());
System.debug('Čas procesorja'+Limits.getCpuTime());
Izhod:
V danem primeru ni stavkov DML in 0 vrstic. Obstoječi CPE čas je 1 milisekunda. Po vrnitvi 2 vrstic iz poizvedbe SOQL in brisanju teh dveh vrstic je skupno število stavkov DML, ki jih vrne Limits.getDMLStatements(), 1, skupno število vrstic, ki jih vrne Limits.getDMLRows() je 2, CPE pa čas, ki je potreben za izvedbo te transakcije, je 51 milisekund.
Primer najboljše prakse: »NIKOLI UPORABLJAJTE DML ZNOTRAJ ZANKE«
Poglejmo, kako lahko zaženemo kodo, ne da bi dobili omejitev guvernerja. Najprej ustvarimo zapis o objektu »Product« (API – Product2) iz predmeta »WorkOrder« tako, da predmet »WorkOrder« dodelimo »Product Name« v sami zanki »for«. Poglejmo naslednjo kodo:
Product2 prod_obj;za (Delovni nalog wo_object : [IZBERITE Zadevo IZ delovnega naloga])
{
prod_obj = nov izdelek2(Ime = wo_object.Subject);
vstavi prod_obj;
}
To lahko naredimo na boljši način tako, da deklariramo seznam (prod_s) in nato shranimo prod_obj na seznam. Ta seznam lahko vstavimo v izdelek zunaj zanke.
ListProduct2 prod_obj;
za (Delovni nalog wo_object : [IZBERITE Zadevo IZ delovnega naloga])
{
prod_obj = nov izdelek2(Ime = wo_object.Subject);
prod_s.add(prod_obj);
}
vstavi prod_obj;
Zaključek
Zdaj smo izvedeli, kaj so omejitve Apex v Salesforce s podrobno razlago. Bolje je uporabiti postopek Asynchronous Apex, da pridobite boljše meje guvernerja v primerjavi s Synchronous Apex. Izvedeli smo tudi o mejah guvernerja za različne scenarije in podali vzorčno predstavitev glede števila omejitev iz razreda »Limit«. Prav tako smo preverili število stavkov DML, vrstic in časa procesorja z izvajanjem enega stavka DML. Ta vodnik smo zaključili z razpravo o enem primeru najboljše prakse.