Salesforce ermöglicht es uns, eine bestimmte Anzahl von Auszügen/Aufzeichnungen gleichzeitig zu verarbeiten oder auszuführen. Es gibt einige Beschränkungen für die Ausführung oder Verarbeitung von DML-Anweisungen, Apex-Klassen usw. Diese Grenzen werden als Governor-Grenzen bezeichnet. In diesem Tutorial werden wir sehen, was die Governor-Limits sind und wie sie gehandhabt werden können. Außerdem stellt Salesforce Apex die „Limit“-Klasse bereit, um die Limits zu kennen, die sich auf Callouts, Apex-Klassen, Lightning-Webkomponenten, SOSL- und SOQL-Anweisungen beziehen.
Gouverneursgrenzen
Stellen Sie sich ein Szenario vor, in dem Alish und Subash zwei Personen sind, die die Salesforce-Organisation verwenden. Alice möchte 1000 DML-Anweisungen in einer Transaktion verarbeiten oder ausführen. Parallel dazu will Subash 5000 Datensätze gleichzeitig laden. Wenn sie es parallel tun, akzeptiert Salesforce nicht und wird hektisch. Daher kommen Gouverneursgrenzen ins Bild. In diesem Fall kann Alish 100 DML gleichzeitig verarbeiten und Subash kann 500 Datensätze gleichzeitig verarbeiten. Sie können den AsynchronousBatch Apex verwenden, um jede Transaktion in einem separaten Thread durchzuführen, ohne sie zu stören, und ihre Aufgabe erledigen.
Grundsätzlich begrenzen Governor-Limits in Salesforce die Verarbeitung und Ausführung in mehreren Transaktionen. 'Pro-Transaktions-Apex-Limits' zählen für jede Transaktion und 'Größenspezifisches Apex-Limit' bezieht sich auf die Größe des Codes. Salesforce unterstützt zwei Prozesse: synchrone und asynchrone Prozesse. Beim synchronen Prozess wird das Apex-Skript auf einmal ausgeführt, während beim asynchronen Prozess das Apex-Skript durch Aufteilen in mehrere Jobs ausgeführt wird.
Zulässige Grenzen
Lassen Sie uns die Limitanzahl für verschiedene Szenarien besprechen:
- Es kann möglich sein, 100 SOQL-Abfragen in synchronem Apex und 200 SOQL-Abfragen in asynchronem Apex zu verarbeiten/auszuführen.
- Nur 50.000 Datensätze werden von einer SOQL-Abfrage für synchronen und asynchronen Apex zurückgegeben.
- Wenn wir Database.getQueryLocator() verwenden, werden jeweils nur 10.000 für synchrones und asynchrones Apex zurückgegeben.
- In beiden Szenarien beträgt die Anzahl der ausgegebenen SOSL-Abfragen 20.
- Die für die Verarbeitung des synchronen Apex erforderliche Heap-Größe beträgt 6 MB. Für asynchrones Apex ist die erforderliche Heap-Größe doppelt so groß, also 12 MB.
- Die maximal zulässige CPU-Zeit für synchrones Apex beträgt 10.000 Millisekunden und 60.000 Millisekunden für asynchrones Apex.
- Für beide Apex sind nur 10 Minuten für die Ausführung vorgesehen.
- In beiden Fällen können wir nur 10 sendEmail()-Methoden mit 100 Empfängern verwenden.
- Die Zeichen, die in der Apex-Klasse oder im Apex-Auslöser vorhanden sind, müssen innerhalb von 1 Million liegen.
- In Batch Apex (asynchron) beträgt die Größe 200. Der QueryLocator() der „Database“-Klasse gibt 50 Millionen Datensätze pro Transaktion zurück.
- Nur 5 Apex-Aufträge befinden sich in der Warteschlange oder sind aktiv.
Beispiel der LIMIT-Klasse:
Apex kann die Governor-Grenzwerte in der „LIMIT“-Klasse festlegen. Diese Klasse stellt einige Methoden bereit, die den Governor-Grenzwerten mitteilen. Schauen wir uns das folgende Beispiel an, das einige Governor-Limits zeigt:
System.debug('Anzahl aggregierter Abfragen, die verarbeitet werden können: '+ Limits.getLimitAggregateQueries());
System.debug('Anzahl der Webdienstanweisungen, die verarbeitet werden können: '+ Limits.getLimitCallouts());
System.debug('Anzahl der Datensätze, die verarbeitet werden können: '+ Limits.getLimitDmlRows());
System.debug('Anzahl der aufrufbaren DML-Anweisungen: '+ Limits.getLimitDmlStatements());
System.debug('Gesamtspeicher in Bytes: '+ Limits.getLimitHeapSize());
System.debug('Anzahl der SOQL-Abfragen, die ausgegeben werden können: '+ Limits.getLimitQueries());
System.debug('Anzahl Datensätze kann ausgegeben werden: '+ Limits.getLimitQueryRows());
System.debug('Anzahl der SOSL-Abfragen, die ausgegeben werden können: '+ Limits.getLimitSoslQueries());
Ausgang:
Es kann auch möglich sein, zu prüfen, wie viele DML-Anweisungen/Zeilen mit den „dome“-Methoden zurückgegeben werden können, die in der „LIMIT“-Klasse vorhanden sind.
- Limits.getDMLStatements() gibt die Gesamtzahl der DML-Anweisungen zurück, die in einer Instanz verwendet werden.
- Limits.getDML Rows () gibt die Gesamtzahl der Zeilen zurück, die von den DML-Anweisungen zurückgegeben werden.
- Limits.getCpuTime() gibt die CPU-Nutzungszeit für die aktuelle Transaktion in Millisekunden zurück.
Anwendungsbeispiel:
Lassen Sie uns eine SOQL-Abfrage schreiben, die die beiden Datensätze aus dem „WorkOrder“-Objekt zurückgibt. Danach löschen Sie diese beiden Datensätze mit „delete“ DML.
System.debug('DML Statements:'+Limits.getDMLStatements());System.debug('Zeilen: '+Limits.getDmlRows());
System.debug('CPU-Zeit'+Limits.getCpuTime());
// SOQL-Abfrage zur Auswahl von 2 Zeilen aus dem WorkOrder-Objekt
List
//Verwenden Sie delete DML, um zwei Zeilen zu löschen
Konten löschen;
System.debug('**Nach SOQL:**');
System.debug('DML Statements:'+Limits.getDMLStatements());
System.debug('Zeilen: '+Limits.getDmlRows());
System.debug('CPU-Zeit'+Limits.getCpuTime());
Ausgang:
Im angegebenen Beispiel gibt es keine DML-Anweisungen und 0 Zeilen. Die vorhandene CPU-Zeit beträgt 1 Millisekunde. Nach der Rückgabe von 2 Zeilen aus der SOQL-Abfrage und dem Löschen dieser beiden Zeilen beträgt die Gesamtzahl der von Limits.getDMLStatements() zurückgegebenen DML-Anweisungen 1, die Gesamtzahl der von Limits.getDMLRows() zurückgegebenen Zeilen 2 und die CPU Zeit, die zum Ausführen dieser Transaktion benötigt wird, beträgt 51 Millisekunden.
Best-Practice-Beispiel: „DML NIE INNERHALB DER SCHLEIFE VERWENDEN“
Mal sehen, wie wir den Code ausführen können, ohne das Governor-Limit zu erreichen. Zuerst erstellen wir einen Datensatz für das „Produkt“-Objekt (API – Produkt2) aus dem „WorkOrder“-Objekt, indem wir das „WorkOrder“-Subjekt dem „Product Name“ in der „for“-Schleife selbst zuweisen. Sehen wir uns den folgenden Code an:
Produkt2 prod_obj;for (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])
{
prod_obj = neues Produkt2 (Name = wo_object.Subject);
prod_obj einfügen;
}
Wir können dies besser tun, indem wir eine Liste (prod_s) deklarieren und dann das prod_obj in der Liste speichern. Wir können diese Liste außerhalb der Schleife in das Produkt einfügen.
ListeProdukt2 prod_obj;
for (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])
{
prod_obj = neues Produkt2 (Name = wo_object.Subject);
prod_s.add (prod_obj);
}
prod_obj einfügen;
Abschluss
Wir haben jetzt mit einer ausführlichen Erklärung erfahren, welche Apex-Grenzwerte in Salesforce gelten. Es ist besser, sich für den asynchronen Apex-Prozess zu entscheiden, um im Vergleich zum synchronen Apex bessere Governor-Grenzen zu erreichen. Wir haben auch etwas über die Governor-Limits für verschiedene Szenarien gelernt und eine Beispieldemonstration bezüglich der Limitanzahl aus der „Limit“-Klasse gegeben. Wir haben auch die Anzahl der DML-Anweisungen, Zeilen und CPU-Zeit überprüft, indem wir eine DML-Anweisung ausgeführt haben. Wir haben diesen Leitfaden mit der Diskussion eines Best-Practice-Beispiels abgeschlossen.