• Accueil / Salesforce / Extraction des informations…
, Extraction des informations sur les limites des journaux de débogage de test<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

Extraction des informations sur les limites des journaux de débogage de test5 minutes de lecture


, Extraction des informations sur les limites des journaux de débogage de test<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>
(La suite de No Limits par 2Unlimited)

introduction

Dans les implémentations Salesforce des grandes entreprises, il y a souvent un
élément de fonctionnalité limité – il consomme la plupart d’un ou plusieurs
limites bien entendu. Il peut être amené à récupérer des informations de
une myriade d’objets standard et personnalisés, mettez à jour tout un tas d’autres objets et
faire un tas de traitements entre les deux qui consomment beaucoup de temps CPU, et quand
il est invoqué avec un grand nombre d’enregistrements il vole près du maximum
des valeurs comme Icare volant trop près du soleil. Souvent, ces zones auront
tests unitaires afin que contrairement à Icare ils ne tombent pas dans la mer et ne se noient pas si le
le code est modifié pour ajouter quelques requêtes SOQL supplémentaires.

Souvent, ces tests essaieront de garantir le nombre maximum d’enregistrements publiés
peut toujours être géré, mais le problème est qu’au moment où le test échoue
vous n’avez nulle part où aller. Une autre approche consiste à déterminer la quantité de chaque
limite est actuellement consommée et échoue au test s’il est dépassé, ce qui conduit à
tests fragiles qui échouent pour des modifications mineures ou, dans le cas du temps CPU, défaillant
des tests qui réussissent et échouent parfois, même si le code n’a pas
modifié, en fonction de ce qui se passe d’autre sur l’instance Salesforce.

Idéalement, il y aurait un moyen de savoir quand les limites consommées changent,
mais sans l’option nucléaire d’échouer au test unitaire. Dans Apex tout
que les tests font est annulée à la fin du test, quel que soit le succès ou
échec, l’envoi de notifications n’est pas une option, ni l’enregistrement de la limite
informations à un objet. C’est quelque chose avec quoi je me bats depuis des années
et n’ont pas été en mesure de trouver une solution pour. Jusqu’ici. Et dans un tour
d’événements qui ne surprendront personne, il s’agit d’un plug-in Salesforce CLI.

Le plug-in

le
limitlog
plug-in exécute le test unitaire fourni par l’utilisateur, puis s’appuie sur le fait
que les tests unitaires génèrent toujours un journal de débogage – à partir de l’aide de Salesforce sur
Ordre de priorité des journaux de débogage
:

Si vous n’avez pas d’indicateurs de trace actifs, Apex synchrone et asynchrone
les tests s’exécutent avec les niveaux de journalisation par défaut.

Le journal le plus récent de l’utilisateur est ensuite récupéré et les informations sur les limites
analysé à partir de celui-ci. Il y a un petit problème autour de cela si votre organisation a un
espace de noms, donc le plug-in vous permet d’en spécifier un si vous avez besoin de quelque chose
autre que la valeur par défaut.

Les informations sur les limites sont ensuite renvoyées au format JSON ou écrites dans un
Objet personnalisé Salesforce – vous pouvez trouver les métadonnées correspondantes sur le
limitelogsalesforce
Dépôt Github.

Les métadonnées incluent également un flux qui vérifie les informations de limite du
précédente exécution pour le test unitaire et m’envoie un e-mail si quelque chose est différent :

, Extraction des informations sur les limites des journaux de débogage de test<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

Je peux donc maintenant ajouter le plug-in à mes opérations d’intégration continue et obtenir
notifié si les limites de consommation ont augmenté, sans avoir à forcer l’unité
échecs des tests.

Installation et exécution

Si vous souhaitez capturer les informations de limite dans Salesforce, la première chose à faire
faire est de lancer une organisation scratch ou une édition développeur, cloner le limitelogsalesforce Dépôt Github et push/déploiement vers cette organisation. Assurez-vous de
s’authentifier auprès de lui via la CLI.

Ensuite, identifiez ou créez un test unitaire qui a un impact limité – cela peut être
dans la même organisation développeur/scratch ou une autre.

L’installation du plug-in dans votre CLI :

plugins sfdx:installer limitlog

Exécutez ensuite le test commande de
le plug-in comme suit :

sfdx bblimlog:test -n LimitLogSample -r KABDEV -t
LimitLogSampleTest.DoWorkTest -s KAB_TUTORIAL -u LIMITLOG -w

où:

  • -n LimitLogSample est l’unique
    nom pour ce test – le flux l’utilise pour trouver l’enregistrement précédent et
    savoir si quelque chose a changé.
  • -r KABDEV est le nom d’utilisateur à exécuter
    les tests comme. Si vos tests sont dans la même organisation que vous écrivez les données,
    vous pouvez omettre ceci.
  • -t LimitLogSampleTest.DoWorkTest
    est la méthode de test unitaire à exécuter
  • -s KAB_TUTORIAL est l’espace de noms
    de mon org dev – si vous n’avez pas d’espace de noms, omettez ceci pour récupérer le
    défaut
  • -u LIMITE JOURNAL est le nom d’utilisateur pour
    l’organisation dans laquelle les informations de test seront écrites
  • -w dit d’écrire les limites
    objets à Salesforce. Si vous ne fournissez pas ceci, assurez-vous d’ajouter le –json
    commutateur pour voir la sortie.

Vous verrez alors une sortie semblable à la suivante :

Exécution du test LimitLogSampleTest.DoWorkTest
Récupération du journal des tests
déposer
Extraction des informations sur les limites
L’écriture des informations sur les limites
Force de vente
Limite les informations écrites dans Salesforce

et l’enregistrement des limites sera disponible dans l’interface utilisateur de Salesforce :

, Extraction des informations sur les limites des journaux de débogage de test<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

et voici la liste des enregistrements dans mon organisation qui ont causé les notifications
envoyé lorsque les limites ont augmenté :

, Extraction des informations sur les limites des journaux de débogage de test<span class="wtr-time-wrap after-title"><span class="wtr-time-number">5</span> minutes de lecture</span>

Dans les prochains blogs, j’expliquerai comment cela fonctionne sous le capot, mais cela me semble suffisant pour le moment. Comme il s’agit de la première version du plug-in, je suis sûr qu’il y aura des scénarios qu’il ne gérera pas – si vous rencontrez l’un d’entre eux, veuillez soulever un problème dans le référentiel source du plug-in et je verrai ce que je peux faire.





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer