Différencier l’application de base et l’application système
Les développeurs AL peuvent étendre les fonctionnalités de Business Central de plusieurs manières. Ils peuvent étendre les tables, les énumérations, les domaines d’application, les pages, les états, les flux de code et le modèle de sécurité. Ils peuvent également contribuer directement à l’application de base dans les projets open source pour les modules d’application système.
L’application Business Central se compose de plusieurs couches :
Application système : il s’agit d’un ensemble de modules open source qui facilitent la création, la gestion et la mise à niveau d’applications locales et en ligne. Ces modules vous permettent de vous concentrer sur la logique métier et les besoins de vos utilisateurs ou clients.
Application de base : il s’agit de la logique métier des fonctionnalités de Business Central.
Présentation de l’application système
L’application système comporte des modules qui interagissent avec la plateforme Dynamics 365 Business Central et l’écosystème en ligne pour prendre en charge la logique métier dans l’application de base. Si vous développez des extensions ou des modules complémentaires pour Dynamics 365 Business Central, vous devrez probablement utiliser un ou plusieurs objets des modules.
Pour une présentation des modules de l’application système, consultez Présentation des modules de l’application système.
Référence d’application système et de base pour Dynamics 365 Business Central
Dans la section Application système, vous pouvez trouver une présentation de tous les objets qui composent la couche d’application système dans Business Central, y compris les objets obsolètes triés par type d’objet. Dans la section Application de base, vous pouvez trouver une présentation de tous les objets qui composent la couche d’application de base dans Business Central. Cette section inclut également une section d’objets obsolètes, triés par type d’objet.
Pour en savoir plus, consultez Référence d’application système et de base pour Dynamics 365 Business Central.
Architecture des modules
Bien que l’architecture interne des modules puisse différer, et sera très probablement différente, des règles garantissent la cohérence et la fiabilité de l’architecture des modules d’application. Pour réduire le couplage et augmenter la cohérence, chaque module est une entité distincte dotée d’une façade accessible au public, tandis que l’implémentation interne n’est pas publique, comme illustré dans l’image suivante :
Les modules sont des projets indépendants et possèdent leurs propres fichiers app.json.
Les modules peuvent appartenir à un package spécifique ou à une couche fonctionnelle. Un module fait partie d’une couche lorsqu’il est ajouté à la structure de dossiers du package de la couche. Un module peut appartenir à plusieurs packages, car il est un package à part entière et peut être regroupé dans des packages de couches fonctionnelles plus grands.
Les dépendances à d’autres modules ne peuvent être appliquées qu’aux modules de la même couche fonctionnelle ou aux couches inférieures. Par exemple, un module de l’application de base ne peut prendre des dépendances qu’à des modules de l’application de base ou de l’application système, mais jamais avec des extensions.
Chaque module doit cibler dans un premier temps l’environnement le plus restrictif, à savoir l’environnement cloud. Si des opérations non sécurisées sont nécessaires, celles-ci doivent aboutir à un module d’application système dans lequel les opérations non sécurisées sont encapsulées avec des API sécurisées. Cette opération est effectuée en définissant la Cible sur OnPrem. Pour les modules situés dans les couches au-dessus de l’application système, la Cible doit être définie sur Cloud dans le fichier app.json.
Seuls les codeunits de façade, les pages et les tables requis dans l’API publique du module peuvent être accessibles. Les détails d’implémentation interne doivent être marqués comme tels en définissant le modificateur d’accès sur Interne. Par exemple, les entités sont accessibles dans le module, mais ne peuvent pas être appelées depuis l’extérieur du module.
Chaque module doit avoir une façade respectant les règles suivantes :
L’accès doit être public. Il doit être défini explicitement pour souligner qu’il s’agit d’une façade ou d’un codeunit de type API qui expose les fonctionnalités de base du module.
Tous les éditeurs d’intégration et d’événements commerciaux doivent être en façade en tant que fonctions internes. Cela les empêche d’être appelés en dehors du module.
Les éditeurs d’événements doivent être marqués comme internes. Les exceptions doivent être documentées.
Toutes les méthodes externes vont en façade.
Les façades ne peuvent pas comporter de logique, ni de fonctions locales.
Comme la façade est le codeunit référencé par d’autres modules, elle doit avoir un nom court et parlant. Les codeunits d’implémentation internes peuvent comporter le suffixe Impl, par exemple, car elles ne sont pas référencées en dehors du module.
Les codeunits d’implémentation comportent une logique métier. Les pages et les tables peuvent comporter du code, mais ne doivent le faire seulement si absolument nécessaire.
L’extensibilité doit être prise en compte dans le cadre de l’implémentation interne de chaque module. Si un module ne doit pas être extensible, la propriété Extensibility des tables, des pages et des énumérations doit être définie sur False pour empêcher l’extension de ces objets.
Voici quelques options où vous pouvez trouver de la documentation sur le développement de modules :
Si vous souhaitez contribuer au code de l’application système open source Business Central, vous devez déterminer le type de contribution :
Petites corrections de bogues, améliorations du produit ou avantages client
Nouvelles fonctionnalités ou modifications plus importantes de la plateforme d’applications existante
Pour en savoir plus sur les contributions, consultez Contribution à l’application système open source Business Central.
Pour en savoir plus sur l’application système, son architecture de modules et comment modifier ou créer des modules, consultez Architecture des modules.