Salesforce giver os mulighed for at behandle eller udføre et bestemt antal udsagn/poster ad gangen. Der er nogle grænser for, at DML-sætninger, Apex-klasser osv. kan udføres eller behandles. Disse grænser er kendt som guvernørgrænser. I denne vejledning vil vi se, hvad Governor-grænserne er, og hvordan de kan håndteres. Salesforce Apex leverer også 'Limit'-klassen for at kende de grænser, der er relateret til callouts, Apex-klasser, lightning-webkomponenter, SOSL- og SOQL-sætninger.
Guvernørens grænser
Overvej et scenario, hvor Alish og Subash er to personer, der bruger Salesforce-organisationen. Alice ønsker at behandle eller udføre 1000 DML-sætninger i én transaktion. Sideløbende ønsker Subash at indlæse 5000 poster ad gangen. Hvis de gør det parallelt, vil Salesforce ikke acceptere og bliver hektisk. Derfor kommer guvernørgrænserne ind i billedet. I dette tilfælde kan Alish behandle 100 DML ad gangen, og Subash kan behandle 500 poster ad gangen. De kan bruge AsynchronousBatch Apex til at udføre hver transaktion på en separat tråd uden at forstyrre hver af dem og fuldføre deres opgave.
Grundlæggende begrænser regulatorgrænser i Salesforce behandlingen og udførelsen i flere transaktioner. 'Per-Transaction Apex Limits' tæller for hver transaktion, og 'Størrelsesspecifik Apex Limit' omhandler størrelsen af koden. Salesforce understøtter to processer: synkrone og asynkrone processer. I den synkrone proces udføres Apex-scriptet på én gang, mens Apex-scriptet i den asynkrone proces udføres ved at opdele i flere job.
Tilladte grænser
Lad os diskutere grænseantallet for forskellige scenarier:
- Det kan være muligt at behandle/køre 100 SOQL-forespørgsler i synkron Apex og 200 SOQL-forespørgsler i asynkron Apex.
- Kun 50.000 poster vil returnere fra en SOQL-forespørgsel for både synkron og asynkron apex.
- Hvis vi bruger Database.getQueryLocator(), returneres kun 10.000 ad gangen for både synkron og asynkron Apex.
- I begge scenarier er antallet af udstedte SOSL-forespørgsler 20.
- Den bunkestørrelse, der kræves for at behandle den synkrone Apex, er 6 MB. For asynkron Apex er den krævede heap-størrelse dobbelt, hvilket gør den til 12 MB.
- Den maksimale CPU-tid, der er tilladt for synkron Apex, er 10.000 millisekunder og 60.000 millisekunder for asynkron Apex.
- Kun 10 minutter er tilladt til udførelsen for begge Apex.
- I begge tilfælde kan vi kun bruge 10 sendEmail()-metoden med 100 modtagere.
- De tegn, der er til stede i Apex-klassen eller i Apex-trigger, skal være inden for 1 mio.
- I Batch Apex (asynkron) er størrelsen 200. QueryLocator() i klassen 'Database' returnerer 50 millioner poster pr. transaktion.
- Kun 5 Apex-job vil være i kø eller aktive.
LIMIT Klasse eksempel:
Apex kan specificere Governor-grænserne i klassen 'LIMIT'. Denne klasse giver nogle metoder, der fortæller guvernørens grænser. Lad os se på følgende eksempel, der viser nogle guvernørgrænser:
System.debug('Antal samlede forespørgsler kan behandles: '+ Limits.getLimitAggregateQueries());
System.debug('Antal webserviceudsagn kan behandles: '+ Limits.getLimitCallouts());
System.debug('Antal poster kan behandles: '+ Limits.getLimitDmlRows());
System.debug('Antal DML-sætninger kan kaldes: '+ Limits.getLimitDmlStatements());
System.debug('Samlet mængde hukommelse i bytes: '+ Limits.getLimitHeapSize());
System.debug('Antal SOQL-forespørgsler kan udstedes: '+ Limits.getLimitQueries());
System.debug('Antal poster kan udstedes: '+ Limits.getLimitQueryRows());
System.debug('Antal SOSL-forespørgsler kan udstedes: '+ Limits.getLimitSoslQueries());
Produktion:
Det kan også være muligt at kontrollere, hvor mange DML-sætninger/rækker, der kan returneres ved hjælp af de 'dome'-metoder, der findes i 'LIMIT'-klassen.
- Limits.getDMLStatements() returnerer det samlede antal DML-sætninger, der bruges i en instans.
- Limits.getDMLRows() returnerer det samlede antal rækker, der returneres af DML-sætningerne.
- Limits.getCpuTime() returnerer den CPU-udnyttede tid for den aktuelle transaktion i millisekunder.
Eksempel på brug:
Lad os skrive en SOQL-forespørgsel, der returnerer de to poster fra 'WorkOrder'-objektet. Derefter skal du slette disse to poster ved at bruge 'slet' DML.
System.debug('DML Statements:'+Limits.getDMLStatements());System.debug('Rows: '+Limits.getDmlRows());
System.debug('CPU Time '+Limits.getCpuTime());
// SOQL-forespørgsel for at vælge 2 rækker fra WorkOrder-objektet
List
//Brug delete DML til at slette to rækker
slette konti;
System.debug('**Efter SOQL:**');
System.debug('DML Statements:'+Limits.getDMLStatements());
System.debug('Rows: '+Limits.getDmlRows());
System.debug('CPU Time '+Limits.getCpuTime());
Produktion:
I det givne eksempel er der ingen DML-sætninger og 0 rækker. Den eksisterende CPU-tid er 1 millisekund. Efter at have returneret 2 rækker fra SOQL-forespørgslen og slettet disse to rækker, er det samlede antal DML-sætninger, der returneres af Limits.getDMLStatements() 1, det samlede antal rækker, der returneres af Limits.getDMLRows() er 2, og CPU'en tid, der er nødvendig for at udføre denne transaktion, er 51 millisekunder.
Eksempel på bedste praksis: 'BRUG ALDRIG DML INDEN I SLØKKEN'
Lad os se, hvordan vi kan køre koden uden at få guvernørgrænsen. Vi opretter først en post på 'Product'-objektet (API - Product2) fra 'WorkOrder'-objektet ved at tildele 'WorkOrder'-emnet til 'Product Name' i selve 'for'-løkken. Lad os se følgende kode:
Produkt2 prod_obj;for (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])
{
prod_obj = nyt produkt2(Navn = wo_objekt.Emne);
indsæt prod_obj;
}
Vi kan gøre dette på en bedre måde ved at erklære en liste (prod_s) og derefter gemme prod_obj i listen. Vi kan indsætte denne liste i produktet uden for løkken.
ListProdukt2 prod_obj;
for (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])
{
prod_obj = nyt produkt2(Navn = wo_objekt.Emne);
prod_s.add(prod_obj);
}
indsæt prod_obj;
Konklusion
Vi har nu lært, hvad Apex-grænser er i Salesforce med en detaljeret forklaring. Det er bedre at gå med Asynchronous Apex-processen for at få bedre Governor-grænser sammenlignet med Synchronous Apex. Vi lærte også om guvernørgrænserne for forskellige scenarier og gav en prøvedemonstration vedrørende grænseantallet fra 'Limit'-klassen. Vi bekræftede også antallet af DML-sætninger, rækker og CPU-tid ved at køre én DML-sætning. Vi afsluttede denne vejledning med at diskutere et eksempel på bedste praksis.