Avertissements BP check D365 F&O : les plus fréquents et leurs corrections

Les « BP checks » sont les règles de bonnes pratiques exécutées par le compilateur X++ (outil xppbp.exe). Elles signalent erreurs, avertissements et informations sur le code et les métadonnées. Microsoft en documente une partie dans le Customization Analysis Report (CAR), avec pour chaque règle le message affiché et la correction attendue. Les plus fréquentes concernent l'accès aux données : boucles imbriquées, insertions ligne à ligne, select forUpdate sans mise à jour, try mal géré dans une transaction.

La bonne pratique : corriger plutôt que supprimer l'avertissement, et ne documenter une exception que lorsque la correction changerait la logique métier.

• BPCheckNestedLoopInCode (« Nested data access loop found ») : une boucle while select dans une autre boucle. Correction : remplacer par une jointure.
• BPCheckSelectwithJoin (« Nested select statement … can be joined ») : des select imbriqués non joints. Correction : jointure.
• BPCheckInsertMethodInLoop (« Insert method can be replaced with RecordInsertList ») : insert() dans une boucle. Correction : opérations ensemblistes, voir insert_recordset et update_recordset.
• BPCheckSelectForUpdateAbsent : select forUpdate sans update. Correction : select simple, ou propriété OCC Enabled à Yes sur la table.
• BPCheckSQLCode : SQL direct dans le X++. Correction : accéder à la base en X++.
• Fonction appelée dans un select : affecter d'abord la valeur à une variable locale, puis utiliser la variable dans le select.

BPCheckNoTTSTryBlock (« Tts block with Try statement does not explicitly catch exceptions ») : dans un bloc tts, un catch générique échoue ; il faut intercepter explicitement l'exception, par exemple UpdateConflict :

ttsbegin;
try
{
    // ...
}
catch (Exception::UpdateConflict)   // conforme : exception explicite
{
    // ...
}

Autres règles fréquentes :

• BPCheckSQLQueryInInit : une requête avec boucle dans init d'un formulaire ; à déplacer.
• BPCheckinvalidExecuteQuery : un addRange après super() dans executeQuery ; à placer avant.
• BPCheckDisplayMethodCached : méthode display non mise en cache ; régler Cache Data Method ou utiliser SysClientCacheDataMethodAttribute.
• BPCheckParametersModified : un paramètre modifié dans la méthode ; le modifier côté appelant.
• BPCheckAlternateKeyAbsent : table avec index unique sans clé alternative ; mettre Alternate Key à Yes.
• BPCheckMissingDeleteActions : relation sans action de suppression ; définir une valeur autre que None.
• BPCheckEmptyLoop : boucle vide ; la supprimer.

Dans un environnement de développement, xppbp.exe génère le rapport CAR (classeur Excel) pour un modèle :

xppbp.exe -metadata=<packages> -all -model=<Modele> -xmlLog=C:\temp\BPCheckLogcd.xml -module=<Package> -car=c:\temp\CAReport.xlsx

Le CAR est l'un des prérequis de la certification de solutions pour les éditeurs. Pour un client, il sert surtout d'audit de qualité avant mise à jour ou reprise de code. Les avertissements BP s'affichent aussi à la compilation dans Visual Studio.

Corriger une série d'avertissements BP est un bon ticket : bien délimité, vérifiable par recompilation. Skalp AI rédige la spécification, génère le code X++ et les tests unitaires, compile en contrôlant les bonnes pratiques, puis livre par pull request dans votre Azure DevOps : rien n'est fusionné sans la validation de votre architecte technique. Voir mises à jour One Version D365 F&O, le cadre général dans développer en X++ sans consultant en 2026, et les offres Basic, Pro et Max (1 crédit, ≈ 400 € en Basic, 200 € en Pro, consommé seulement à la génération du code).

À lire aussi : réduire le backlog X++ d'un éditeur ISV avec l'IA et Skalp AI pour les éditeurs ISV.

• Microsoft Learn, « Customization Analysis Report (CAR) », mise à jour du 26/02/2026, consultée le 18/10/2026.
• Microsoft Learn, « Write best practice rules », mise à jour du 30/03/2026, consultée le 18/10/2026.