Salesforce võimaldab meil töödelda või täita teatud arvu avaldusi/kirjeid korraga. DML-lausete, Apex-klasside jms täitmisel või töötlemisel on teatud piirangud. Neid piiranguid tuntakse kubermangu piirangutena. Selles õpetuses näeme, millised on kuberneri piirangud ja kuidas neid käsitleda. Samuti pakub Salesforce Apex klassi „Limit”, et teada saada piiranguid, mis on seotud tähelepanulaiendite, Apexi klasside, välkveebikomponentide, SOSL-i ja SOQL-i avaldustega.
Kuberneri piirangud
Mõelge stsenaariumile, kus Alish ja Subash on kaks inimest, kes kasutavad Salesforce'i org. Alice soovib ühe tehinguga töödelda või täita 1000 DML-lauset. Paralleelselt soovib Subash laadida korraga 5000 kirjet. Kui nad teevad seda paralleelselt, ei nõustu Salesforce ja muutub kirglikuks. Seega tulevad pildile kuberneri piirangud. Sel juhul saab Alish töödelda korraga 100 DML-i ja Subash 500 kirjet korraga. Nad saavad kasutada AsynchronousBatch Apexi, et teha iga tehing eraldi lõimel, ilma et neid häiritaks, ja täita oma ülesanne.
Põhimõtteliselt piiravad Salesforce'i valitseja piirangud mitme tehingu töötlemist ja täitmist. „Tehingupõhised tipupiirangud” arvestatakse iga tehingu puhul ja „Suuruspetsiifiline apexi piirang” käsitleb koodi suurust. Salesforce toetab kahte protsessi: sünkroonseid ja asünkroonseid protsesse. Sünkroonprotsessis käivitatakse Apexi skript ühe korraga, asünkroonses protsessis aga Apexi skript jaotatakse mitmeks tööks.
Lubatud piirangud
Arutleme erinevate stsenaariumide piirarvu üle:
- Sünkroonses Apexis võib olla võimalik töödelda/käita 100 SOQL päringut ja asünkroonses Apexis 200 SOQL päringut.
- Ainult 50 000 kirjet tagastatakse SOQL-päringust nii sünkroonse kui ka asünkroonse tipu kohta.
- Kui kasutame Database.getQueryLocator(), tagastatakse nii sünkroonse kui ka asünkroonse Apexi puhul korraga ainult 10 000.
- Mõlema stsenaariumi korral on väljastatud SOSL-päringute arv 20.
- Sünkroonse Apexi töötlemiseks vajalik kuhja suurus on 6 MB. Asünkroonse Apexi jaoks on nõutav hunniku suurus kahekordne, mis teeb sellest 12 MB.
- Sünkroonse Apexi maksimaalne lubatud protsessori aeg on 10 000 millisekundit ja asünkroonse Apexi puhul 60 000 millisekundit.
- Mõlema Apexi sooritamiseks on lubatud ainult 10 minutit.
- Mõlemal juhul saame kasutada ainult 10 sendEmail() meetodit 100 adressaadiga.
- Apexi klassis või Apexi päästikus esinevad tähemärgid peavad jääma 1 miljoni piiresse.
- Batch Apexis (asünkroonne) on suurus 200. Andmebaasi klassi QueryLocator() tagastab 50 miljonit kirjet tehingu kohta.
- Ainult 5 Apexi tööd on järjekorras või aktiivsed.
LIMIT klassi näide:
Apex saab määrata Governor limiidid klassis LIMIT. See klass pakub mõningaid meetodeid, mis ütlevad kubernerile piirid. Vaatame järgmist näidet, mis kuvab mõned kuberneripiirangud:
System.debug('Töödeldavate koondpäringute arv: '+ Limits.getLimitAggregateQueries());
System.debug('Töödeldavate veebiteenuste avalduste arv: '+ Limits.getLimitCallouts());
System.debug('Töödeldavate kirjete arv: '+ Limits.getLimitDmlRows());
System.debug('DML-lausete arvu saab nimetada: '+ Limits.getLimitDmlStatements());
System.debug('Mälu kogumaht baitides: '+ Limits.getLimitHeapSize());
System.debug('SOQL-i päringute arv saab väljastada: '+ Limits.getLimitQueries());
System.debug('Väljastada saab kirjete arv: '+ Limits.getLimitQueryRows());
System.debug('SOSL-i päringute arv saab väljastada: '+ Limits.getLimitSoslQueries());
Väljund:
Samuti on võimalik kontrollida, mitu DML-lauset/rida saab tagastada, kasutades “kupli” meetodeid, mis on klassis “LIMIT” olemas.
- Limits.getDMLStatements() tagastab eksemplaris kasutatud DML-lausete koguarvu.
- Limits.getDMLRows() tagastab DML-lausete poolt tagastatud ridade koguarvu.
- Limits.getCpuTime() tagastab praeguse tehingu CPU kasutatud aja millisekundites.
Kasutusnäide:
Kirjutame SOQL-päringu, mis tagastab kaks kirjet objektist „WorkOrder”. Pärast seda kustutage need kaks kirjet, kasutades DML-i kustutamist.
System.debug('DML-laused:'+Limits.getDMLStatements());System.debug('Rows: '+Limits.getDmlRows());
System.debug('CPU aeg '+Limits.getCpuTime());
// SOQL-päring, et valida WorkOrder objektist 2 rida
Loend
//Kahe rea kustutamiseks kasutage DML-i kustutamist
kontode kustutamine;
System.debug('**Pärast SOQL-i:**');
System.debug('DML-laused:'+Limits.getDMLStatements());
System.debug('Rows: '+Limits.getDmlRows());
System.debug('CPU aeg '+Limits.getCpuTime());
Väljund:
Antud näites pole DML-lauseid ja 0 rida. Olemasolev protsessori aeg on 1 millisekund. Pärast SOQL-päringust 2 rea tagastamist ja nende kahe rea kustutamist on Limits.getDMLStatements() poolt tagastatud DML-lausete koguarv 1, Limits.getDMLRows() tagastatud ridade koguarv on 2 ja CPU selle tehingu sooritamiseks kuluv aeg on 51 millisekundit.
Parima tava näide: „ÄRA KASUTAGE NEVER USE DML INSIDE THE LOOP”
Vaatame, kuidas saame koodi käivitada ilma valitsejapiiranguta. Esmalt loome kirje objektist „Toode” (API – Toode2) objektist „WorkOrder”, määrates tsüklis „for” objektile „Toote nimi” teema „WorkOrder”. Vaatame järgmist koodi:
Toode2 prod_obj;jaoks (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])
{
prod_obj = uus Toode2(Nimi = wo_objekt.Teema);
sisesta prod_obj;
}
Seda saab teha paremini, kui deklareerime loendi (prod_s) ja salvestame seejärel loendisse prod_obj. Saame selle loendi tootesse sisestada väljaspool ahelat.
LoendToode2 prod_obj;
jaoks (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])
{
prod_obj = uus Toode2(Nimi = wo_objekt.Teema);
prod_s.add(toode_obj);
}
sisesta prod_obj;
Järeldus
Saime nüüd üksikasjaliku selgitusega teada, millised on Apexi piirangud Salesforce'is. Parem on kasutada asünkroonse apexi protsessi, et saada paremaid valitsemispiire võrreldes sünkroonse apexiga. Samuti saime teada erinevate stsenaariumide kuberneri limiitidest ja andsime näidisesitluse limiitide loenduse kohta klassist “Limit”. Samuti kontrollisime DML-lausete, ridade ja protsessori aja arvu, käivitades ühe DML-lause. Lõpetasime selle juhendi ühe parima tava näite arutamisega.