Salesforce Apex – Limitele guvernatorului

Salesforce Apex Limitele Guvernatorului



Salesforce ne permite să procesăm sau să executăm un anumit număr de declarații/înregistrări simultan. Există anumite limite pentru executarea sau procesarea instrucțiunilor DML, clasele Apex etc. Aceste limite sunt cunoscute sub denumirea de limite guvernatorului. În acest tutorial, vom vedea care sunt limitele guvernatorului și cum pot fi gestionate. De asemenea, Salesforce Apex oferă clasa „Limit” pentru a cunoaște limitele care sunt legate de înștiințări, clase Apex, componente web fulger, instrucțiuni SOSL și SOQL.

Limitele guvernatorului

Luați în considerare un scenariu în care Alish și Subash sunt două persoane care folosesc organizația Salesforce. Alice vrea să proceseze sau să execute 1000 de instrucțiuni DML într-o singură tranzacție. În paralel, Subash vrea să încarce 5000 de înregistrări la un moment dat. Dacă o fac în paralel, Salesforce nu va accepta și devine agitat. Prin urmare, limitele guvernatorului intră în vedere. În acest caz, Alish poate procesa 100 DML la un moment dat, iar Subash poate procesa 500 de înregistrări la un moment dat. Ei pot folosi AsynchronousBatch Apex pentru a face fiecare tranzacție pe un fir separat, fără a-i deranja pe fiecare și pentru a-și îndeplini sarcina.







Practic, limitele guvernatorului din Salesforce limitează procesarea și execuția în mai multe tranzacții. „Limite Apex per tranzacție” contează pentru fiecare tranzacție, iar „Limita Apex specifică mărimii” se ocupă de dimensiunea codului. Salesforce acceptă două procese: procese sincrone și procese asincrone. În procesul sincron, scriptul Apex este executat dintr-o singură mișcare, în timp ce în procesul asincron, scriptul Apex este executat prin împărțirea în mai multe joburi.



Limite permise

Să discutăm numărul limită pentru diferite scenarii:



  1. Este posibil să procesați/rulați 100 de interogări SOQL în Apex sincron și 200 de interogări SOQL în Apex asincron.
  2. Doar 50.000 de înregistrări vor reveni dintr-o interogare SOQL atât pentru vârful sincron, cât și pentru cel asincron.
  3. Dacă folosim Database.getQueryLocator(), doar 10.000 sunt returnate la un moment dat atât pentru Apex sincron, cât și pentru cel asincron.
  4. În ambele scenarii, numărul de interogări SOSL emise este de 20.
  5. Dimensiunea heap-ului care este necesară pentru a procesa Apex-ul sincron este de 6 MB. Pentru Apex asincron, dimensiunea heap necesară este dublă, ceea ce îl face de 12 MB.
  6. Timpul maxim de procesor care este permis pentru Apex sincron este de 10.000 de milisecunde și 60.000 de milisecunde pentru Apex asincron.
  7. Doar 10 minute sunt permise pentru execuție pentru ambele Apex.
  8. În ambele cazuri, putem folosi doar metoda 10 sendEmail() cu 100 de destinatari.
  9. Caracterele care sunt prezente în clasa Apex sau în declanșatorul Apex trebuie să fie în limita a 1 milion.
  10. În Batch Apex (asincron), dimensiunea este de 200. QueryLocator() din clasa „Bază de date” returnează 50 de milioane de înregistrări per tranzacție.
  11. Doar 5 joburi Apex vor fi în coadă sau active.

Exemplu de clasă LIMIT:

Apex poate specifica limitele guvernatorului în clasa „LIMIT”. Această clasă oferă câteva metode care indică limitele guvernatorului. Să ne uităm la următorul exemplu care afișează unele limite guvernatorului:





System.debug('Numărul de interogări agregate pot fi procesate: '+ Limits.getLimitAggregateQueries());

System.debug('Numărul de instrucțiuni ale serviciului Web pot fi procesate: '+ Limits.getLimitCallouts());

System.debug('Numărul de înregistrări pot fi procesate: '+ Limits.getLimitDmlRows());

System.debug('Numărul de instrucțiuni DML poate fi numit: '+ Limits.getLimitDmlStatements());

System.debug('Cantitatea totală de memorie în octeți: '+ Limits.getLimitHeapSize());

System.debug('Numărul de interogări SOQL pot fi emise: '+ Limits.getLimitQueries());

System.debug('Numărul de înregistrări poate fi emis: '+ Limits.getLimitQueryRows());

System.debug('Numărul de interogări SOSL pot fi emise:  '+ Limits.getLimitSoslQueries());

Ieșire:

De asemenea, se poate verifica câte instrucțiuni/rânduri DML pot fi returnate folosind metodele „dome” care sunt prezente în clasa „LIMIT”.



  1. Limits.getDMLStatements() returnează totalul instrucțiunilor DML care sunt utilizate la o instanță.
  2. Limits.getDMLRows() returnează numărul total de rânduri care sunt returnate de instrucțiunile DML.
  3. Limits.getCpuTime() returnează timpul utilizat CPU pentru tranzacția curentă în milisecunde.

Exemplu de utilizare:

Să scriem o interogare SOQL care returnează cele două înregistrări din obiectul „WorkOrder”. După aceea, ștergeți aceste două înregistrări folosind DML „Ștergeți”.

System.debug('DML Statements:'+Limits.getDMLStatements());

System.debug('Rânduri: '+Limits.getDmlRows());

System.debug('Timp CPU '+Limits.getCpuTime());

// Interogare SOQL pentru a selecta 2 rânduri din obiectul WorkOrder

Listă conturi = [SELECT ID FROM WorkOrder LIMIT 2];

//Utilizați ștergere DML pentru a șterge două rânduri

ștergerea conturilor;

System.debug('**După SOQL:**');

System.debug('DML Statements:'+Limits.getDMLStatements());

System.debug('Rânduri: '+Limits.getDmlRows());

System.debug('Timp CPU '+Limits.getCpuTime());

Ieșire:

În exemplul dat, nu există instrucțiuni DML și 0 rânduri. Timpul CPU existent este de 1 milisecundă. După returnarea a 2 rânduri din interogarea SOQL și ștergerea acestor două rânduri, numărul total de instrucțiuni DML care este returnat de Limits.getDMLStatements() este 1, numărul total de rânduri returnate de Limits.getDMLRows()  este 2 și CPU timpul necesar pentru a executa această tranzacție este de 51 de milisecunde.

Exemplu de cea mai bună practică:  „NU UTILIZAȚI NICIODATĂ DML ÎN BUCLĂ”

Să vedem cum putem rula codul fără a obține limita guvernatorului. Mai întâi creăm o înregistrare pe obiectul „Produs” (API – Product2) din obiectul „Comandă de lucru”, atribuind subiectul „Comandă de lucru” „Nume produs” în bucla „for”. Să vedem următorul cod:

Product2 prod_obj;

pentru (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])

{

prod_obj = nou Produs2(Nume = wo_object.Subject);

insert prod_obj;

}

Putem face acest lucru într-un mod mai bun declarând o listă (prod_s) și apoi stocând prod_obj în listă. Putem introduce această listă în produs în afara buclei.

List prod_s = new List();

Product2 prod_obj;

pentru (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])

{

prod_obj = nou Produs2(Nume = wo_object.Subject);

prod_s.add(prod_obj);

}

insert prod_obj;

Concluzie

Am aflat acum care sunt limitele Apex în Salesforce cu o explicație detaliată. Este mai bine să mergeți cu procesul Asynchronous Apex pentru a obține limite de guvernator mai bune în comparație cu Synchronous Apex. Am aflat, de asemenea, despre limitele guvernatorului pentru diferite scenarii și am oferit un exemplu de demonstrație cu privire la numărul de limite din clasa „Limit”. De asemenea, am verificat numărul de instrucțiuni DML, rânduri și timpul CPU prin rularea unei singure instrucțiuni DML. Am încheiat acest ghid discutând un exemplu de bune practici.