Salesforce nous permet de traiter ou d'exécuter un nombre particulier d'instructions/d'enregistrements à la fois. Il existe certaines limites pour les instructions DML, les classes Apex, etc., à exécuter ou à traiter. Ces limites sont appelées limites du gouverneur. Dans ce didacticiel, nous verrons quelles sont les limites du gouverneur et comment elles peuvent être gérées. En outre, Salesforce Apex fournit la classe « Limit » pour connaître les limites liées aux appels, aux classes Apex, aux composants Web Lightning, aux instructions SOSL et SOQL.
Limites du gouverneur
Considérez un scénario où Alish et Subash sont deux personnes utilisant l'organisation Salesforce. Alice souhaite traiter ou exécuter 1 000 instructions DML en 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 agité. Par conséquent, les limites du gouverneur entrent en scène. Dans ce cas, Alish peut traiter 100 DML à la fois et Subash peut traiter 500 enregistrements à la fois. Ils peuvent utiliser AsynchronousBatch Apex pour effectuer chaque transaction sur un thread 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 de plusieurs transactions. Les 'limites Apex par transaction' comptent pour chaque transaction et la '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 une seule fois tandis que dans le processus asynchrone, le script Apex est exécuté en se divisant en plusieurs tâches.
Limites autorisées
Discutons du nombre limite pour différents scénarios :
- Il peut être possible de traiter/exécuter 100 requêtes SOQL en Apex synchrone et 200 requêtes SOQL en Apex asynchrone.
- Seuls 50 000 enregistrements seront renvoyés d'une requête SOQL pour les apex synchrones et asynchrones.
- Si nous utilisons Database.getQueryLocator(), seuls 10 000 sont renvoyés à la fois pour Apex synchrone et asynchrone.
- Dans les deux scénarios, le nombre de requêtes SOSL émises est de 20.
- La taille de segment requise pour traiter l'apex synchrone est de 6 Mo. Pour Apex asynchrone, la taille de tas requise est le double, ce qui en fait 12 Mo.
- Le temps CPU maximal autorisé pour Apex synchrone est de 10 000 millisecondes et de 60 000 millisecondes pour Apex asynchrone.
- Seulement 10 minutes sont autorisées pour l'exécution pour les deux Apex.
- Dans les deux cas, nous ne pouvons utiliser que 10 méthodes sendEmail() avec 100 destinataires.
- Les caractères présents dans la classe Apex ou dans le déclencheur Apex doivent être inférieurs à 1 million.
- Dans Batch Apex (asynchrone), la taille est de 200. Le QueryLocator() de la classe « Database » renvoie 50 millions d'enregistrements par transaction.
- Seules 5 tâches Apex seront en file d'attente ou actives.
Exemple de classe LIMIT :
Apex peut spécifier les limites du gouverneur dans la classe 'LIMIT'. Cette classe fournit des méthodes qui indiquent les limites du gouverneur. Examinons l'exemple suivant qui affiche certaines limites du gouverneur :
System.debug('Nombre de requêtes agrégées pouvant être traitées : '+ Limits.getLimitAggregateQueries());
System.debug('Nombre d'instructions de service Web pouvant être traitées : '+ Limits.getLimitCallouts());
System.debug('Nombre d'enregistrements pouvant être traités : '+ Limits.getLimitDmlRows());
System.debug('Nombre d'instructions DML pouvant être appelées : '+ Limits.getLimitDmlStatements());
System.debug('Quantité totale de mémoire en octets : '+ Limits.getLimitHeapSize());
System.debug('Nombre de requêtes SOQL pouvant être émises : '+ Limits.getLimitQueries());
System.debug('Nombre d'enregistrements pouvant être émis : '+ Limits.getLimitQueryRows());
System.debug('Nombre de requêtes SOSL pouvant être émises : '+ Limits.getLimitSoslQueries());
Sortir:
Il est également possible de vérifier le nombre d'instructions/lignes DML pouvant être renvoyées à l'aide des méthodes « dome » présentes dans la classe « LIMIT ».
- Limits.getDMLStatements() renvoie le nombre total d'instructions DML utilisées sur une instance.
- Limites.getDMLRows() renvoie le nombre total de lignes renvoyées par les instructions DML.
- Limites.getCpuTime() renvoie le temps d'utilisation du processeur pour la transaction en cours 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.
System.debug('Instructions DML :'+Limits.getDMLStatements());System.debug('Rows : '+Limits.getDmlRows());
System.debug('CPU Time '+Limits.getCpuTime());
// Requête SOQL pour sélectionner 2 lignes de l'objet WorkOrder
List
//Utilisez delete DML pour supprimer deux lignes
supprimer des comptes ;
System.debug('**Après SOQL :**');
System.debug('Instructions DML :'+Limits.getDMLStatements());
System.debug('Rows : '+Limits.getDmlRows());
System.debug('CPU Time '+Limits.getCpuTime());
Sortir:
Dans l'exemple donné, il n'y a pas d'instructions DML et 0 lignes. Le temps CPU existant est de 1 milliseconde. Après avoir renvoyé 2 lignes de la requête SOQL et supprimé ces deux lignes, le nombre total d'instructions DML renvoyées par Limits.getDMLStatements() est de 1, le nombre total de lignes renvoyées par Limits.getDMLRows() est de 2 et le processeur le temps nécessaire pour exécuter cette transaction est de 51 millisecondes.
Exemple de bonne pratique : « NE JAMAIS UTILISER 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 'Product' (API - Product2) à partir de l'objet 'WorkOrder' en attribuant le sujet 'WorkOrder' au 'Product Name' dans la boucle 'for' elle-même. Voyons le code suivant :
Produit2 prod_obj ;pour (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])
{
prod_obj = new Product2(Name = wo_object.Subject);
insérez prod_obj ;
}
Nous pouvons le faire d'une meilleure manière 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.
ListProduit2 prod_obj ;
pour (WorkOrder wo_object : [SELECT Subject FROM WorkOrder])
{
prod_obj = new Product2(Name = wo_object.Subject);
prod_s.add(prod_obj);
}
insérez 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 d'utiliser le processus Apex asynchrone pour obtenir de meilleures limites de gouverneur par rapport à Apex synchrone. Nous avons également découvert les limites du gouverneur pour différents scénarios et donné un exemple de démonstration concernant le nombre de limites de la classe 'Limit'. Nous avons également vérifié le nombre d'instructions DML, de lignes et de temps CPU en exécutant une instruction DML. Nous avons conclu ce guide en discutant d'un exemple de bonne pratique.