Salesforce Apex – Governor Limits

Salesforce Apex Governor Limits



Salesforce tillåter oss att bearbeta eller exekvera ett visst antal uttalanden/poster åt gången. Det finns vissa gränser för DML-satser, Apex-klasser, etc. att exekvera eller bearbeta. Dessa gränser är kända som Governor limits. I den här handledningen kommer vi att se vad Governor-gränserna är och hur de kan hanteras. Salesforce Apex tillhandahåller också klassen 'Limit' för att känna till gränserna som är relaterade till callouts, Apex-klasser, lightning webbkomponenter, SOSL- och SOQL-satser.

Guvernörens gränser

Tänk på ett scenario där Alish och Subash är två personer som använder Salesforce-organisationen. Alice vill bearbeta eller exekvera 1000 DML-satser i en transaktion. Parallellt vill Subash ladda 5000 poster åt gången. Om de gör det parallellt, accepterar inte Salesforce och blir hektiskt. Därför kommer guvernörens gränser in i bilden. I det här fallet kan Alish behandla 100 DML åt gången och Subash kan behandla 500 poster åt gången. De kan använda AsynchronousBatch Apex för att göra varje transaktion på en separat tråd utan att störa var och en av dem och slutföra sin uppgift.







I grund och botten begränsar regulatorns gränser i Salesforce bearbetningen och exekveringen i flera transaktioner. 'Per-Transaction Apex Limits' räknas för varje transaktion och 'Size-Specific Apex Limit' handlar om storleken på koden. Salesforce stöder två processer: synkrona och asynkrona processer. I den synkrona processen exekveras Apex-skriptet på en gång medan i den asynkrona processen exekveras Apex-skriptet genom att delas upp i flera jobb.



Tillåtna gränser

Låt oss diskutera gränsvärdet för olika scenarier:



  1. Det kan vara möjligt att bearbeta/köra 100 SOQL-frågor i synkron Apex och 200 SOQL-frågor i asynkron Apex.
  2. Endast 50 000 poster kommer att returneras från en SOQL-fråga för både synkron och asynkron apex.
  3. Om vi ​​använder Database.getQueryLocator() returneras endast 10 000 åt gången för både synkron och asynkron Apex.
  4. I båda scenarierna är antalet utfärdade SOSL-frågor 20.
  5. Högstorleken som krävs för att bearbeta den synkrona Apexen är 6 MB. För asynkron Apex är den heapstorlek som krävs dubbel vilket gör den 12 MB.
  6. Den maximala CPU-tiden som tillåts för synkron Apex är 10 000 millisekunder och 60 000 millisekunder för asynkron Apex.
  7. Endast 10 minuter tillåts för utförandet för båda Apex.
  8. I båda fallen kan vi endast använda 10 sendEmail()-metoden med 100 mottagare.
  9. De tecken som finns i Apex-klassen eller i Apex-utlösaren måste vara inom 1 miljon.
  10. I Batch Apex (asynkron) är storleken 200. QueryLocator() i klassen 'Databas' returnerar 50 miljoner poster per transaktion.
  11. Endast 5 Apex-jobb kommer att stå i kö eller aktiva.

LIMIT Klassexempel:

Apex kan specificera Governor-gränserna i klassen 'LIMIT'. Den här klassen tillhandahåller några metoder som talar om för guvernörens gränser. Låt oss titta på följande exempel som visar några guvernörsgränser:





System.debug('Antal sammanställda frågor kan bearbetas: '+ Limits.getLimitAggregateQueries());

System.debug('Antal webbtjänstuttalanden kan bearbetas: '+ Limits.getLimitCallouts());

System.debug('Antal poster kan bearbetas: '+ Limits.getLimitDmlRows());

System.debug('Antal DML-satser kan kallas: '+ Limits.getLimitDmlStatements());

System.debug('Total mängd minne i byte: '+ Limits.getLimitHeapSize());

System.debug('Antal SOQL-frågor kan utfärdas: '+ Limits.getLimitQueries());

System.debug('Antal poster kan utfärdas: '+ Limits.getLimitQueryRows());

System.debug('Antal SOSL-frågor kan utfärdas:  '+ Limits.getLimitSoslQueries());

Produktion:

Det kan också vara möjligt att kontrollera hur många DML-satser/rader som kan returneras med hjälp av de 'dome'-metoder som finns i klassen 'LIMIT'.



  1. Limits.getDMLStatements() returnerar det totala antalet DML-satser som används vid en instans.
  2. Limits.getDMLRows() returnerar det totala antalet rader som returneras av DML-satserna.
  3. Limits.getCpuTime() returnerar CPU-använd tid för den aktuella transaktionen i millisekunder.

Användningsexempel:

Låt oss skriva en SOQL-fråga som returnerar de två posterna från 'WorkOrder'-objektet. Efter det, radera dessa två poster med 'radera' DML.

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

System.debug('Rows: '+Limits.getDmlRows());

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

// SOQL Fråga för att välja 2 rader från WorkOrder-objektet

List-konton = [SELECT ID FROM WorkOrder LIMIT 2];

//Använd delete DML för att ta bort två rader

ta bort konton;

System.debug('**Efter SOQL:**');

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

System.debug('Rows: '+Limits.getDmlRows());

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

Produktion:

I det givna exemplet finns det inga DML-satser och 0 rader. Den befintliga CPU-tiden är 1 millisekund. Efter att ha returnerat 2 rader från SOQL-frågan och tagit bort dessa två rader är det totala antalet DML-satser som returneras av Limits.getDMLStatements() 1, det totala antalet rader som returneras av Limits.getDMLRows() är 2 och CPU:n tid som behövs för att utföra denna transaktion är 51 millisekunder.

Exempel på bästa praxis: 'ANVÄND ALDRIG DML INNE I LOOPEN'

Låt oss se hur vi kan köra koden utan att få guvernörsgränsen. Vi skapar först en post på 'Product'-objektet (API - Product2) från  'WorkOrder'-objektet genom att tilldela 'WorkOrder'-subjektet 'Product Name' i själva 'for'-loopen. Låt oss se följande kod:

Produkt2 prod_obj;

för (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])

{

prod_obj = new Product2(Name = wo_object.Subject);

infoga prod_obj;

}

Vi kan göra detta på ett bättre sätt genom att deklarera en lista (prod_s) och sedan lagra prod_obj i listan. Vi kan infoga denna lista i produkten utanför loopen.

List prod_s = new List();

Produkt2 prod_obj;

för (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])

{

prod_obj = new Product2(Name = wo_object.Subject);

prod_s.add(prod_obj);

}

infoga prod_obj;

Slutsats

Vi lärde oss nu vilka Apex-gränser är i Salesforce med en detaljerad förklaring. Det är bättre att gå med Asynkron Apex-processen för att få bättre Governor-gränser jämfört med Synchronous Apex. Vi lärde oss också om Governor-gränserna för olika scenarier och gav en exempeldemonstration angående gränsräkningen från klassen 'Limit'. Vi verifierade också antalet DML-satser, rader och CPU-tid genom att köra en DML-sats. Vi avslutade den här guiden med att diskutera ett exempel på bästa praxis.