Salesforce Apex - Limites du gouverneur

Salesforce nous permet de traiter ou d'exécuter un nombre particulier de déclarations / enregistrements à la fois. Il y a quelques limites pour les instructions DML, les classes Apex, etc., Pour exécuter ou traiter. Ces limites sont appelées limites de gouverneur. Dans ce tutoriel, nous verrons quelles sont les limites du gouverneur et comment elles peuvent être manipulées. En outre, Salesforce Apex fournit la classe «Limite» pour connaître les limites liées aux appels, aux classes Apex, aux composants Web Lightning, SOSL et SOQL.

Limites du gouverneur

Considérez un scénario où Alish et Subash sont deux personnes utilisant l'organisation Salesforce. Alice veut traiter ou exécuter 1000 instructions DML dans une seule transaction. En parallèle, Subash veut charger 5000 enregistrements à la fois. S'ils le font en parallèle, Salesforce n'acceptera pas et devient mouvementé. Par conséquent, les limites du gouverneur entrent en photo. Dans ce cas, Alish peut traiter 100 DML à la fois et Subash peut traiter 500 enregistrements à la fois. Ils peuvent utiliser l'apex AsynchronousBatch pour effectuer chaque transaction sur un fil séparé sans déranger chacun d'eux et terminer leur tâche.

Fondamentalement, les limites du gouverneur dans Salesforce limitent le traitement et l'exécution dans plusieurs transactions. Les dénombrements «par transaction Apex Limits» pour chaque transaction et «Limite Apex spécifique à la taille» traite de la taille du code. Salesforce prend en charge deux processus: les processus synchrones et asynchrones. Dans le processus synchrone, le script Apex est exécuté en un seul coup dans le processus asynchrone, le script Apex est exécuté en divisant en plusieurs travaux.

Limites autorisées

Discutons du nombre de limites pour différents scénarios:

1. Il peut être possible de traiter / exécuter 100 requêtes SOQL dans l'apex synchrone et 200 requêtes SOQL dans l'apex asynchrone.
2. Seuls 50 000 enregistrements reviendront d'une requête SOQL pour l'apex synchrone et asynchrone.
3. Si nous utilisons la base de données.getQueryLocator (), seulement 10 000 sont retournés à la fois pour l'apex synchrone et asynchrone.
4. Dans les deux scénarios, le nombre de requêtes SOSL émises est de 20.
5. La taille du tas nécessaire pour traiter l'apex synchrone est de 6 Mo. Pour l'apex asynchrone, la taille du tas requise est double, ce qui en fait 12 Mo.
6. Le temps de CPU maximum autorisé pour l'apex synchrone est de 10 000 millisecondes et 60 000 millisecondes pour l'apex asynchrone.
7. Seulement 10 minutes est autorisée pour l'exécution pour les deux apex.
8. Dans les deux cas, nous ne pouvons utiliser que 10 méthode SendEmail () avec 100 destinataires.
9. Les personnages qui sont présents dans la classe Apex ou dans le déclencheur Apex doivent être à moins de 1 million.
10. Dans le lot Apex (asynchrone), la taille est de 200. Le questionnaire () de la classe «base de données» renvoie 50 millions d'enregistrements par transaction.
11. Seuls 5 emplois APEX seront en file d'attente ou actifs.

Exemple de classe limite:

Apex peut spécifier les limites du gouverneur dans la classe «limite». Cette classe fournit des méthodes qui indiquent aux limites du gouverneur. Examinons l'exemple suivant qui affiche certaines limites du gouverneur:

Système.débogage ('Le nombre de requêtes agrégées peut être traitée:' + Limites.getLIMITAGGREGATEQUERIES ());
Système.Debug ('Nombre d'instructions de services Web peuvent être traitées:' + Limites.getliMitCallouts ());
Système.débogage ('Le nombre d'enregistrements peut être traité:' + Limites.getlimitdmlrows ());
Système.débogage ('Le nombre d'instructions DML peut être appelée:' + limites.getliMitdmlStAtsations ());
Système.Débogue («Montant total de mémoire en octets:« + limites.getlimitheApSize ());
Système.Debug ('Le nombre de requêtes SOQL peut être émise:' + Limites.getliMitqueries ());
Système.débogage ('Le nombre de dossiers peut être émis:' + limites.getLIMITQUERYROWS ());
Système.Debug ('Nombre de requêtes SOSL peuvent être émises:' + Limites.getLIMITSOSLQUERES ());

Sortir:

Il peut également être possible de vérifier le nombre de instructions / lignes DML peut être renvoyée en utilisant les méthodes «dôme» qui sont présentes dans la classe «limite».

1. Limites.getDmlStAtsations () Renvoie les instructions totales DML qui sont utilisées sur une instance.
2. Limites.getDmlRows () Renvoie le nombre total de lignes qui sont renvoyées par les instructions DML.
3. Limites.getCpuTime () Renvoie le temps utilisé par le CPU pour la transaction actuelle en millisecondes.

Exemple d'utilisation:

Écrivons une requête SOQL qui renvoie les deux enregistrements de l'objet «Workorder». Après cela, supprimez ces deux enregistrements à l'aide de «supprimer» DML.

Système.débogage ('instructions DML:' + limites.getDmlStatements ());
Système.débogage ('lignes:' + limites.getDmlRows ());
Système.débogage («temps de processeur» + limites.getCpuTime ());
// requête SOQL pour sélectionner 2 lignes dans l'objet de commande de travail
Liste des comptes = [SELECT ID From WorkOrder Limit 2];
// Utilisez Delete DML pour supprimer deux lignes
supprimer des comptes;
Système.debug ('** après soql: **');
Système.débogage ('instructions DML:' + limites.getDmlStatements ());
Système.débogage ('lignes:' + limites.getDmlRows ());
Système.débogage («temps de processeur» + limites.getCpuTime ());

Sortir:

Dans l'exemple donné, il n'y a pas de déclarations DML et 0 lignes. Le temps de processeur existant est de 1 milliseconde. Après avoir retourné 2 lignes de la requête SOQL et supprimé ces deux lignes, le nombre total d'instructions DML qui est renvoyée par les limites.getDmlStaté () est 1, les lignes totales renvoyées par les limites.getdmlRows () est 2, et le temps de processeur nécessaire pour exécuter cette transaction est de 51 millisecondes.

Best Practice Exemple: «N'utilisez jamais DML à l'intérieur de la boucle»

Voyons comment nous pouvons exécuter le code sans obtenir la limite du gouverneur. Nous créons d'abord un enregistrement sur l'objet «Produit» (API - Product2) à partir de l'objet «Workorder» en attribuant le «Workorder» soumis au «nom du produit» dans la boucle «For» elle-même. Voyons le code suivant:

Product2 prod_obj;
for (workorder wo_object: [Sélectionner le sujet de WorkOrder])

prod_obj = new Product2 (name = wo_object.Sujet);
insérer prod_obj;

Nous pouvons le faire mieux en déclarant une liste (prod_s), puis en stockant le prod_obj dans la liste. Nous pouvons insérer cette liste dans le produit en dehors de la boucle.

List prod_s = new list ();
Product2 prod_obj;
for (workorder wo_object: [Sélectionner le sujet de WorkOrder])

prod_obj = new Product2 (name = wo_object.Sujet);
prod_s.ajouter (prod_obj);

insérer prod_obj;

Conclusion

Nous avons maintenant appris quelles sont les limites Apex dans Salesforce avec une explication détaillée. Il est préférable de suivre le processus Apex asynchrone pour obtenir de meilleures limites de gouverneur par rapport à l'apex synchrone. Nous avons également appris les limites du gouverneur pour différents scénarios et avons fait une démonstration d'échantillon concernant le nombre de limites de la classe «limite». Nous avons également vérifié le nombre de déclarations DML, de lignes et de temps de CPU en exécutant une instruction DML. Nous avons conclu ce guide en discutant d'un exemple de meilleures pratiques.