Rechercher dans ce blog

02 juin 2014

Certaines choses à ne pas faire en C/AL !

Voici une "petite" liste des oublis ou erreurs fréquentes pour les développeurs Dynamics NAV  :
  • Agrandir la longueur d'un champ Code/Text :
    • La plupart des champs sont répliqués à des fins d'optimisation et de souplesse d'utilisation sur plusieurs tables, il est donc TRES dangereux d'étendre un champ sans une analyse d'impact approfondie...(mais cela, vous le saviez déjà, non ?!)
    • Exemple avec l'extension du nom du client, qui causera une anomalie bloquante dès qu'un client avec un nom trop long sera saisi sur un document de vente... (succès assuré)
  • Faire un Record.INSERT/MODIFY/RENAME/DELETE sans déclencher le trigger correspondant (OnInsert, OnModify, OnRename, OnDelete)
    • Solution : appeler la méthode avec True en paramètre pour déclencher le trigger
    • Exemple : Customer.MODIFY(True)
  • Dans le même registre, faire une affectation d'un champ sans déclencher le trigger OnValidate() 
    • Solution : utiliser le VALIDATE à la place d'une affectation simple
    • Exemple : VALIDATE("Document Date","Posting Date");
  • Oublier de gérer les suppressions en cascade : typiquement Nav gère l'intégrité référentielle en modification mais pas en suppression : cette dernière doit faire l'objet d'une programmation du trigger OnDelete()
  • Oublier de paramétrer la propriété DrillDownPageID/DrillDownFormID permettant le DrillDown à partir des flowfields (de type Count/Sum, etc...)
  • Oublier de mettre la propriété Local=Yes sur les fonctions : une fonction déclarée comme locale est interne à l'objet et ne peut pas être invoquée depuis un autre objet. Cela vous permet de pouvoir modifier l'implémentation de ces fonctions sans aucun impact sur le reste de l'application (plus on isole, mieux c'est...). 
  • Dans la version SQL, oublier de définir les propriétés SumIndexFields sur les index pour les Flowfields correspondants : dans ce cas, le calcul d'un Flowfield peut être très consommateur de ressources car il est tout de même calculé mais sans être optimisé.
  • Pour les champs de type quantité, pourcentage : oublier les propriétés DecimalPlaces, Min/MaxValue, ...
  • Pour les champs de type coût/prix/montants : oublier les propriétés   AutoFormatType et AutoFormatExpr
  • Oublier la propriété NotBlank sur les champs appartenant à la clé primaire.
Enfin, last but not least, l'erreur courante est d'oublier de faire tes tests dans le contexte du client et de l'utilisateur final : les tests doivent être réalisés avec la licence du client ET avec dans le contexte de sécurité de l'utilisateur (avec ses rôles de sécurité, et non pas avec le rôle "SUPER").

18 mars 2014

Design Pattern, pour ne pas réinventer la roue...


Comme chacun le sait, Microsoft Dynamics NAV ("NAV") est une solution ouverte dont chaque partenaire peut "librement" modifier l'ensemble des objets applicatifs en utilisant l'environnement de développement intégré ("IDE" pour les intimes).

Mais "librement" ne veut pas dire "n'importe comment" : au delà des aspects liés aux coûts de développement (ET de maintenance), il faut bien comprendre que NAV a été conçu et structuré à l'aide de "pattern", c'est à dire de motifs récurrents.

Ces patterns ou motifs sont donc des solutions éprouvées répondantes à des besoins précis, largement réutilisées et réutilisables. Ils sont la garantie de l'homogénéité du produit dans tous les domaines : ergonomie, utilisabilité, processus, paramétrage, etc. Ils permettent évidement de diminuer les efforts de développement tout en réduisant les risques de dysfonctionnement.

Ces pattern ne sont pas explicitement documentés mais l’appréhension et la compréhension de ces derniers est capitale pour tout consultant/concepteur qui se respecte. C'est d'autant plus vrai qu'est né en 2012 un groupe de travail sur ces patterns, à l'initiative de Microsoft. 

Le contenu de ce groupe de travail est accessible sur la page éponyme "Design Patterns" : il regroupe les différents patterns publiés à ce jour. J'ai personnellement contribué en rédigeant le "Document Pattern" qui explique comment est structuré un document dans NAV (devis, commande, etc.).

Alors vous me direz, pourquoi tous ces patterns ne sont pas officiellement documentés...? C'est une autre histoire...! 

ps : pour information, il faut savoir que les concepteurs de Navision à l'époque ont largement utilisé U.M.L., la preuve en images avec une publication de Pavel Hruby datant de 1998 !