• Accueil / Salesforce / Blog de Bob…
, Blog de Bob Buzzard: Règles XPath personnalisées du scanner CLI Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">4</span> minutes de lecture</span>

Blog de Bob Buzzard: Règles XPath personnalisées du scanner CLI Salesforce4 minutes de lecture


, Blog de Bob Buzzard: Règles XPath personnalisées du scanner CLI Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">4</span> minutes de lecture</span>

introduction

Dans la partie 1 de cet article, j’ai montré comment créer une expression XPath qui recherche les requêtes SOQL
en dehors de la méthode de test ou des classes d’accesseurs via le
PMD designer. En ce
en lui-même était très amusant, et il y a une précipitation définitive lorsque vous venez enfin avec
les runes appropriées, mais leur valeur est limitée. Dans cet article, je vais intégrer le
expression dans une règle personnalisée et ajoutez-la au scanner Salesforce CLI.

Règle

Une règle doit se trouver dans un fichier XML d’ensemble de règles. Le site PMD a
excellente documentation
à ce sujet, je ne le reproduirai donc pas ici pour compléter mon message.

Quelques aspects clés de ma règle sont qu’il s’agit d’une expression XPath pour
évaluer par rapport à Apex codé, je dois donc ajouter ce détail à la définition afin
que la classe appropriée peut être instanciée pour la gérer:


et l’expression XPath elle-même apparaît dans les propriétés de la règle, avec le
Version XPath:


  
  
    
      
    
  

Emballer la règle

L’ensemble de règles xml doit être empaqueté sous forme de fichier JAR (Java ARchive) à l’aide de
outil du même nom. Si j’avais écrit une règle Java personnalisée, je devrais compiler
la classe et l’inclure dans le JAR, mais comme je compte sur un préexistant
classe (net.sourceforge.pmd.lang.apex.rule.ApexXPathRule) Je peux simplement empaqueter le fichier XML de l’ensemble de règles.

Par le fonctionnaire
Création de la documentation sur les règles personnalisées, mon fichier de règles réside à:

./category/apex/bobbuzzard.xml

donc pour créer mon JAR, j’exécute la commande suivante, ce qui me donne beaucoup de
informations sur ce qui est ajouté:

$ jar -cvf bobbuzzard.jar ./category

added manifest
adding: category/(in = 0) (out= 0)(stored 0%)
adding: category/apex/(in = 0) (out= 0)(stored 0%)
adding: category/apex/bobbuzzard.xml(in = 1105) (out= 545)(deflated 50%)

Installer la règle

Une fois que j’ai empaqueté la règle, je peux l’installer à l’aide du scanner: rule: add
Commande Salesforce CLI, spécifiant la langue comme Apex et le JAR que je viens de
établi:

$ sfdx scanner:rule:add -l apex -p bobbuzzard.jar 
Successfully added rules for apex.
1 Path(s) added: /Users/kbowden/PMDRULE/bobbuzzard.jar

Selon la documentation officielle, je liste les commandes pour m’assurer qu’elles sont entrées correctement
(quand j’ai compris tout cela mais que mon fichier ruleset.xml n’était pas configuré
à droite, la commande réussirait mais la règle ne serait pas ajoutée, donc vérifier
via la commande list est certainement une étape à franchir). Pour que je n’ai pas
pour patauger dans un ton de sortie, je le passe à travers
grep exclure
toutes les lignes qui ne contiennent pas les caractères
Buse :

$ sfdx scanner:rule:list | grep Buzzard
SoqlOnlyInTestAndAccessorClasses          apex         Bob Buzzard     pmd

donc tout va bien – ma règle est toute présente et correcte.

Exécuter la règle

Il ne reste plus qu’à exécuter ma règle sur quelques exemples de classes Apex. le
classes, et le jeu de règles et le JAR sont disponibles au Dépôt Github.

J’ai:

  • ScannerExample.cls – cela a une expression SOQL et une Database.query
    appel de méthode, donc je m’attends à ce qu’il soit signalé deux fois.
  • ScannerExampleAccessor.cls – comme ci-dessus, mais comme c’est un nom de classe
    se terminant par Accessor, je ne m’attends pas à ce qu’il soit signalé.
  • ScannerExampleTest.cls – une classe de test avec une expression SOQL dans un
    méthode d’essai et une dans une méthode régulière. Je m’attends à ce qu’il soit signalé une fois
    concernant la méthode régulière

Lors de l’exécution du scanner, j’ai défini la catégorie sur « Bob Buzzard » car je veux seulement
le code évalué par rapport à ma règle:

$ sfdx scanner:run --target './**/*.cls' -c "Bob Buzzard"
LOCATION                                                  DESCRIPTION                                          CATEGORY     U R L
────────────────────────────────────────────────────────  ───────────────────────────────────────────────────  ───────────  ─────
force-app/main/default/classes/ScannerExample.cls:5         SOQL queries can only appear in test methods and   Bob Buzzard
                                                            accessor classes
force-app/main/default/classes/ScannerExample.cls:10        SOQL queries can only appear in test methods and   Bob Buzzard
                                                            accessor classes
force-app/main/default/classes/ScannerExampleTest.cls:19    SOQL queries can only appear in test methods and   Bob Buzzard
                                                            accessor classes

et là nous l’avons – les lignes qui enfreignent ma règle ont été identifiées.

Ressources





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Voulez-vous utiliser Pardot à sa capacité maximale et avoir
+ DE LEADS QUALIFIÉS

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

Fermer