Salesforce Apex - Guvernørgrenser

Salesforce Apex - Guvernørgrenser

Salesforce lar oss behandle eller utføre et bestemt antall uttalelser/poster om gangen. Det er noen grenser for DML -uttalelser, Apex -klasser osv., å utføre eller prosess. Disse grensene er kjent som guvernørgrenser. I denne opplæringen vil vi se hva guvernøren er og hvordan de kan håndteres. Salesforce Apex gir også "grense" -klassen for å kjenne grensene som er relatert til utrop, Apex -klasser, Lightning Web Components, SOSL og SOQL -uttalelser.

Guvernørgrenser

Tenk på et scenario der Alish og Subash er to personer som bruker Salesforce Org. Alice ønsker å behandle eller utføre 1000 DML -setninger i en transaksjon. Parallelt ønsker Subash å laste inn 5000 poster om gangen. Hvis de gjør det parallelt, vil Salesforce ikke akseptere og blir hektisk. Derfor kommer guvernørgrensene inn i bildet. I dette tilfellet kan Alish behandle 100 DML om gangen og Subash kan behandle 500 poster om gangen. De kan bruke AsynchronousBatch -spissen for å gjøre hver transaksjon på en egen tråd uten å forstyrre hver av dem og fullføre oppgaven sin.

I utgangspunktet begrenser guvernøren i Salesforce behandlingen og utførelsen i flere transaksjoner. "Per-transaksjons toppens grenser" teller for hver transaksjon og "størrelsesspesifikk Apex-grense" omhandler størrelsen på koden. Salesforce støtter to prosesser: synkrone og asynkrone prosesser. I den synkrone prosessen blir Apex -skriptet utført i en enkelt gang mens du er i den asynkrone prosessen, blir Apex -skriptet utført ved å dele opp i flere jobber.

Tillatt grenser

La oss diskutere grensetellingen for forskjellige scenarier:

  1. Det kan være mulig å behandle/kjøre 100 SOQL -spørsmål i synkron spiss og 200 SOQL -spørsmål i asynkron spiss.
  2. Bare 50 000 poster vil returnere fra en SOQL -spørring for både synkron og asynkron topp.
  3. Hvis vi bruker databasen.GetQuerylocator (), bare 10.000 returneres om gangen for både synkront og asynkron topp.
  4. I begge scenariene er antallet utstedt SOSL -spørsmål 20.
  5. Heapstørrelsen som kreves for å behandle den synkrone spissen er 6 MB. For asynkron spis.
  6. Den maksimale CPU -tiden som er tillatt for synkron spiss er 10.000 millisekunder og 60.000 millisekunder for asynkron spiss.
  7. Bare 10 minutter er tillatt for utførelsen for begge spissen.
  8. I begge tilfeller kan vi bare bruke 10 SendEmail () -metode med 100 mottakere.
  9. Karakterene som er til stede i Apex -klassen eller i Apex -utløseren, må være innen 1 million.
  10. I Batch Apex (asynkron) er størrelsen 200. QueryLocator () i "Database" -klassen returnerer 50 millioner poster per transaksjon.
  11. Bare 5 Apex -jobber vil være i kø eller aktiv.

Begrens klasseeksempel:

Apex kan spesifisere guvernørgrensene i "grensen" -klassen. Denne klassen gir noen metoder som forteller guvernørgrensene. La oss se på følgende eksempel som viser noen guvernørgrenser:

System.Debug ('Antall samlede spørsmål kan behandles:'+ grenser.getLimitAggregateQueries ());
System.Debug ('Antall uttalelser med webtjenester kan behandles:'+ grenser.getLimitCallouts ());
System.Debug ('Antall poster kan behandles:'+ grenser.getLimitDmlrows ());
System.Debug ('Antall DML -setninger kan kalles:'+ grenser.getLimitDmlStatements ());
System.Debug ('Total mengde minne i byte:'+ grenser.getLimitheapSize ());
System.Debug ('Antall SOQL -spørsmål kan utstedes:'+ Limits.getLimitQueries ());
System.Debug ('Antall poster kan utstedes:'+ grenser.getLimitQueryRows ());
System.DEBUG ('Antall SOSL -spørsmål kan utstedes:'+ Limits.getLimitsoslqueries ());

Produksjon:

Det kan også være mulig å sjekke hvor mange DML -setninger/rader som kan returneres ved hjelp av "kuppelen" -metodene som er til stede i "grense" -klassen.

  1. Grenser.getDmlStatements () Returnerer de totale DML -setningene som brukes på et tilfelle.
  2. Grenser.getDmlrows () Returnerer det totale antallet rader som returneres av DML -uttalelsene.
  3. Grenser.getCputime () Returnerer CPU brukt tid for den nåværende transaksjonen i millisekunder.

Brukseksempel:

La oss skrive en SOQL -spørring som returnerer de to postene fra "Workorder" -objektet. Etter det, slett disse to postene ved å bruke “Slett” DML.

System.Debug ('DML -setninger:'+grenser.getDmlStatements ());
System.Debug ('Rader:'+grenser.getDmlrows ());
System.Debug ('CPU Time'+Limits.getCputime ());
// SOQL -spørring for å velge 2 rader fra arbeidsordenobjektet
Listekontoer = [Velg ID fra Workorder Limit 2];
// Bruk slett DML for å slette to rader
slette kontoer;
System.Debug ('** etter soql: **');
System.Debug ('DML -setninger:'+grenser.getDmlStatements ());
System.Debug ('Rader:'+grenser.getDmlrows ());
System.Debug ('CPU Time'+Limits.getCputime ());

Produksjon:

I det gitte eksemplet er det ingen DML -setninger og 0 rader. Den eksisterende CPU -tiden er 1 millisekunder. Etter å ha returnert 2 rader fra SOQL -spørringen og slettet disse to radene, er det totale antallet DML -setninger som returneres av grensene.getDmlStatements () er 1, de totale radene som returneres av grensene.getDmlrows () er 2, og CPU -tiden som er nødvendig for å utføre denne transaksjonen er 51 millisekunder.

Eksempel på beste praksis: "Bruk aldri DML inne i løkken"

La oss se hvordan vi kan kjøre koden uten å få guvernørgrensen. Vi oppretter først en post på "Produkt" -objektet (API - Product2) fra "Workorder" -objektet ved å tilordne "Workorder" underlagt "produktnavnet" i "for" -sløyfen i seg selv. La oss se følgende kode:

Product2 PROD_OBJ;
for (Workorder WO_Object: [Velg emne fra Workorder])

PROD_OBJ = NYTT PRODUKT2 (navn = wo_object.Emne);
Sett inn PROD_OBJ;

Vi kan gjøre dette på en bedre måte ved å erklære en liste (prod_s) og deretter lagre prod_obj på listen. Vi kan sette inn denne listen i produktet utenfor løkken.

Liste prod_s = new List ();
Product2 PROD_OBJ;
for (Workorder WO_Object: [Velg emne fra Workorder])

PROD_OBJ = NYTT PRODUKT2 (navn = wo_object.Emne);
PROD_S.Legg til (prod_obj);

Sett inn PROD_OBJ;

Konklusjon

Vi lærte nå hvilke spissgrenser som er i Salesforce med en detaljert forklaring. Det er bedre å gå med den asynkrone Apex -prosessen for å få bedre guvernørgrenser sammenlignet med synkron spiss. Vi lærte også om guvernørgrensene for forskjellige scenarier og ga en eksempler på demonstrasjonen angående grensetallet fra "grense" -klassen. Vi bekreftet også antallet DML -uttalelser, rader og CPU -tid ved å kjøre en DML -setning. Vi konkluderte med denne guiden ved å diskutere ett eksempler på beste praksis.