Salesforce stelt ons in staat om een bepaald aantal statements/records tegelijkertijd te verwerken of uit te voeren. Er zijn enkele limieten voor DML-instructies, Apex-klassen, enz. om uit te voeren of te verwerken. Deze limieten worden gouverneurslimieten genoemd. In deze zelfstudie zullen we zien wat de limieten van de gouverneur zijn en hoe ze kunnen worden afgehandeld. Salesforce Apex biedt ook de klasse 'Limit' om de limieten te kennen die verband houden met callouts, Apex-klassen, bliksemwebcomponenten, SOSL- en SOQL-statements.
Grenzen van de gouverneur
Overweeg een scenario waarin Alish en Subash twee personen zijn die de Salesforce-organisatie gebruiken. Alice wil 1000 DML-instructies in één transactie verwerken of uitvoeren. Tegelijkertijd wil Subash 5000 records tegelijk laden. Als ze het parallel doen, accepteert Salesforce het niet en wordt het hectisch. Vandaar dat de limieten van de gouverneur in beeld komen. In dit geval kan Alish 100 DML tegelijk verwerken en Subash 500 records tegelijk. Ze kunnen de AsynchronousBatch Apex gebruiken om elke transactie op een afzonderlijke thread uit te voeren zonder ze allemaal te storen en hun taak te voltooien.
Kortom, Governor-limieten in Salesforce beperken de verwerking en uitvoering in meerdere transacties. 'Apexlimieten per transactie' telt voor elke transactie en 'Size-Specific Apex Limit' behandelt de grootte van de code. Salesforce ondersteunt twee processen: synchrone en asynchrone processen. In het synchrone proces wordt het Apex-script in één keer uitgevoerd, terwijl in het asynchrone proces het Apex-script wordt uitgevoerd door te splitsen in meerdere taken.
Toegestane limieten
Laten we het aantal limieten voor verschillende scenario's bespreken:
- Het kan mogelijk zijn om 100 SOQL-query's in synchrone Apex en 200 SOQL-query's in asynchrone Apex te verwerken/uit te voeren.
- Slechts 50.000 records zullen terugkeren van een SOQL-query voor zowel synchrone als asynchrone apex.
- Als we de Database.getQueryLocator() gebruiken, worden er slechts 10.000 tegelijk geretourneerd voor zowel synchrone als asynchrone Apex.
- In beide scenario's is het aantal verzonden SOSL-query's 20.
- De heapgrootte die nodig is om de synchrone Apex te verwerken is 6 MB. Voor asynchrone Apex is de vereiste heapgrootte het dubbele, wat het 12 MB maakt.
- De maximale CPU-tijd die is toegestaan voor synchrone Apex is 10.000 milliseconden en 60.000 milliseconden voor asynchrone Apex.
- Voor beide Apex is slechts 10 minuten toegestaan voor de uitvoering.
- In beide gevallen kunnen we slechts 10 methodes sendEmail() gebruiken met 100 ontvangers.
- De tekens die aanwezig zijn in de Apex-klasse of in Apex-trigger moeten binnen 1 miljoen zijn.
- In Batch Apex (asynchroon) is de grootte 200. De QueryLocator() van de klasse 'Database' retourneert 50 miljoen records per transactie.
- Er zullen slechts 5 Apex-taken in de wachtrij staan of actief zijn.
LIMIT Klasse Voorbeeld:
Apex kan de limieten van de gouverneur specificeren in de klasse 'LIMIT'. Deze klasse biedt enkele methoden die de limieten van de gouverneur aangeven. Laten we eens kijken naar het volgende voorbeeld waarin enkele gouverneurslimieten worden weergegeven:
System.debug('Aantal geaggregeerde query's kan worden verwerkt: '+ Limits.getLimitAggregateQueries());
System.debug('Aantal webservicestatements kan worden verwerkt: '+ Limits.getLimitCallouts());
System.debug('Aantal records kan worden verwerkt: '+ Limits.getLimitDmlRows());
System.debug('Aantal DML-statements kan worden aangeroepen: '+ Limits.getLimitDmlStatements());
System.debug('Totale hoeveelheid geheugen in bytes: '+ Limits.getLimitHeapSize());
System.debug('Aantal SOQL-query's kan worden uitgegeven: '+ Limits.getLimitQueries());
System.debug('Aantal records kan worden uitgegeven: '+ Limits.getLimitQueryRows());
System.debug('Aantal SOSL-query's kan worden uitgegeven: '+ Limits.getLimitSoslQueries());
Uitgang:
Het kan ook mogelijk zijn om te controleren hoeveel DML-instructies/rijen kunnen worden geretourneerd met behulp van de “dome”-methoden die aanwezig zijn in de “LIMIT”-klasse.
- Limieten.getDMLStatements() retourneert het totale aantal DML-statements dat in een instantie is gebruikt.
- Limieten.getDMLRows() geeft het totale aantal rijen terug dat wordt geretourneerd door de DML-statements.
- Limieten.getCpuTime() retourneert de CPU-gebruikstijd voor de huidige transactie in milliseconden.
Gebruiksvoorbeeld:
Laten we een SOQL-query schrijven die de twee records van het object 'WorkOrder' retourneert. Verwijder daarna deze twee records met DML 'verwijderen'.
System.debug('DML-verklaringen:'+Limits.getDMLStatements());Systeem.debug('Rijen: '+Limits.getDmlRows());
System.debug('CPU-tijd '+Limits.getCpuTime());
// SOQL-query om 2 rijen uit het WorkOrder-object te selecteren
Lijst
// Gebruik delete DML om twee rijen te verwijderen
accounts verwijderen;
System.debug('**Na SOQL:**');
System.debug('DML-verklaringen:'+Limits.getDMLStatements());
Systeem.debug('Rijen: '+Limits.getDmlRows());
System.debug('CPU-tijd '+Limits.getCpuTime());
Uitgang:
In het gegeven voorbeeld zijn er geen DML-instructies en 0 rijen. De bestaande CPU-tijd is 1 milliseconde. Na het retourneren van 2 rijen uit de SOQL-query en het verwijderen van deze twee rijen, is het totale aantal DML-statements dat wordt geretourneerd door de Limits.getDMLStatements() 1, het totale aantal rijen dat wordt geretourneerd door de Limits.getDMLRows() is 2, en de CPU tijd die nodig is om deze transactie uit te voeren is 51 milliseconden.
Voorbeeld van best practice: 'GEBRUIK DML NOOIT BINNEN DE LUS'
Laten we eens kijken hoe we de code kunnen uitvoeren zonder de gouverneurslimiet te krijgen. We maken eerst een record op het object 'Product' (API - Product2) van het object 'WorkOrder' door het onderwerp 'WorkOrder' toe te wijzen aan de 'Productnaam' in de 'for'-lus zelf. Laten we de volgende code bekijken:
Product2 prod_obj;voor (werkopdracht wo_object: [SELECTEER onderwerp UIT werkopdracht])
{
prod_obj = nieuw Product2(Naam = wo_object.Subject);
voeg prod_obj in;
}
We kunnen dit op een betere manier doen door een lijst (prod_s) te declareren en vervolgens de prod_obj in de lijst op te slaan. We kunnen deze lijst buiten de lus in het product invoegen.
LijstProduct2 prod_obj;
voor (werkopdracht wo_object: [SELECTEER onderwerp UIT werkopdracht])
{
prod_obj = nieuw Product2(Naam = wo_object.Subject);
prod_s.add(prod_obj);
}
voeg prod_obj in;
Conclusie
We hebben nu geleerd wat Apex-limieten zijn in Salesforce met een gedetailleerde uitleg. Het is beter om mee te gaan met het Asynchronous Apex-proces om betere gouverneurslimieten te krijgen in vergelijking met Synchronous Apex. We leerden ook over de limieten van de gouverneur voor verschillende scenario's en gaven een voorbeelddemonstratie met betrekking tot het aantal limieten van de klasse 'Limit'. We hebben ook het aantal DML-statements, rijen en CPU-tijd geverifieerd door één DML-statement uit te voeren. We sloten deze gids af met het bespreken van een best practice-voorbeeld.