Bonjour à tous! Mon nom est Tanya, je suis le chef d'équipe de l'équipe de développement d'Axapta à Lamoda. Cet article traitera du développement de notre premier projet sur la plate-forme Microsoft Dynamics 365 For Finance and Operations.

Je parlerai des approches que nous avons utilisées, des erreurs qui ont été commises, je partagerai mes connaissances et mon expérience acquise. Cet article peut intéresser ceux qui commencent à développer un projet en D365 ou qui y pensent.

Il s'agit d'une transcription gratuite du rapport de la réunion Mycrosoft Dynamics 365 & Power Platform Meetup.

Objectif du projet et bases techniques

Notre filiale allemande achète des marchandises et les vend à une entité juridique russe. Auparavant, nous utilisions le système Tsenit, qui nous permettait de conserver des enregistrements uniquement au niveau des données financières, mais ne pouvait pas faire face aux tâches de marchandises et de logistique. Pour résoudre ces problèmes, nous avions des outils supplémentaires. Les données ont été stockées dans plusieurs bases de données à la fois. Tout cela a affecté négativement la vitesse et la fiabilité de l'ensemble du système.

Nous voulions que le système comptable aide la succursale allemande à soumettre des rapports, à payer des impôts et à passer des audits. L'ERP passé a à peine résolu ces problèmes, nous avons donc décidé de développer et de lancer notre propre système comptable. Notre ERP était censé combiner la finance, la comptabilité et la logistique des succursales en un seul circuit. En tant que logiciel principal, nous avons choisi Microsoft Dynamics 365 - l'ancien Dynamics AX, également connu sous le nom d'Axapta.

Le volet métier est décrit dans l'article «Technologie, externalisation et mentalité» . Ici, nous parlerons de la mise en œuvre technique. Nous avons donc dû automatiser plusieurs processus métier:

Achat de marchandises auprès de fournisseurs;
Vente à une personne morale russe;
Intégration entre D365 et Ax2012, le système comptable d'une entité juridique russe;
;
.

Dans le projet, nous avons décidé de mettre en œuvre la solution cloud Microsoft Dynamics 365, car le bureau allemand n'avait pas l'infrastructure informatique pour déployer l'application, ni les personnes qui en seraient responsables. Pour les petites succursales distantes, le schéma SaaS est optimal, car il vous permet d'obtenir tous les logiciels et environnements de développement nécessaires pour commencer la mise en œuvre, immédiatement après la signature du contrat avec le fournisseur.

Nous avions des délais serrés: il fallait terminer l'ensemble du développement en 3 mois. Étant donné que, dans l'ancien système, la comptabilité des marchandises était effectuée dans des feuilles de calcul, le transfert de l'ensemble des données historiques serait une tâche impossible au milieu d'un exercice. Mais au début de la période considérée, il suffit de ne transférer que les soldes. Il a donc fallu le lancer soit le 1er janvier 2019, soit le reporter d'une année supplémentaire.

Notre équipe n'avait pas d'expérience en développement chez D365. Malgré toutes les circonstances, nous avions prévu de démarrer ce projet le plus rapidement possible. Ensuite, je décrirai séparément toutes les étapes de développement. Je m'attarderai sur chaque itération en détail: quelle expérience nous avons acquise et quelles erreurs nous avons commises.

Première itération, modifications sur la version d'application 7.3

Afin de nous mettre rapidement au travail, nous avons d'abord développé une architecture d'application simple. Il se composait d'environnements de développement - environnements DevBox à 1 niveau. Tous les composants ont été installés sur un serveur / machine virtuelle: Application Object Server (AOS), base de données, Dynamics 365 Retail et Management Reporter.

Pour les tests, nous avons décidé d'utiliser l'environnement SAT - environnement à deux niveaux de test d'acceptation standard.

L'environnement à deux niveaux est un environnement multi-box, dont les composants sont installés dans plusieurs services cloud et incluent généralement plusieurs serveurs d'objets d'application (AOS). En fait, il est le plus proche possible d'un environnement productif, nous avons donc décidé de le tester.

Nous avons déployé les premiers environnements de développement sur l'infrastructure locale existante, mais sa capacité n'était pas suffisante pour poursuivre le développement du projet. Par conséquent, lorsque deux autres développeurs ont rejoint le projet, nous avons rapidement et élégamment déployé DevBox pour eux dans le cloud.

Nos environnements cloud ont été gérés via le portail des services Lifecycle.

Ayant fini avec les environnements, l'équipe a commencé à se développer. Nous avons configuré l'environnement de développement sur Visual Studio et les avons connectés au contrôle de version d'Azure DevOps, après avoir créé une branche pour télécharger le code. Ensuite, nous avons développé une approche pour le développement et le transfert des changements à l'environnement SAT.

Il n'y a pas de couches dans l'architecture D365; tout le code standard a été présenté dans le modèle. Les modifications ont été transférées à l'environnement SAT via le portail LCS avec un package contenant un modèle compilé.

– , – , .

Pour commencer, nous avons implémenté la modification la plus simple et la plus courante: ajouter un nouveau champ à la table standard, l'initialiser lors de la création de l'enregistrement et la sortie vers le formulaire standard.

Même dans un projet aussi simple, il existe de nouveaux types d'objets. Nous avons fait une extension pour ajouter de nouveaux champs à la table standard. Pour amener le champ au formulaire standard, nous avons créé un nouveau type d'objet - une extension pour le formulaire. Et pour initialiser le champ, nous avons créé une classe qui étend les méthodes de table. Il a permis d'initialiser le champ lors de la création de l'enregistrement.

Sur une modification aussi simple, nous avons vu l'un des principes de base de D365 - pas un changement, mais une extension des objets standard.

La modification suivante a été la création d'un nouveau formulaire. Maintenant, lors de la création d'un formulaire, il était nécessaire de spécifier son modèle.Un modèle est un modèle qui définit complètement la structure de conception d'un formulaire. Jusqu'à ce que nous reproduisions complètement la structure définie dans le modèle, notre formulaire ne sera pas compilé. Il est impossible de modifier le modèle du formulaire terminé. Par conséquent, avant de commencer le développement, nous avons pensé à l'avance à quoi ressemblerait notre formulaire.

Nous avons également conservé la capacité de gérer nous-mêmes la conception du formulaire. Si nous avons indiqué le motif - Personnalisé, nous étions entièrement responsables de la conception du formulaire: quels objets y étaient et avec quelle imbrication.

Conclusions après la première itération

1. Ne modifiez pas la norme, mais développez-la uniquement.

2. Référez-vous au modèle si nous utilisons ses objets dans un autre modèle. C'est l'une des différences entre les modèles D365 des versions précédentes: un objet existe dans un seul modèle.

3. La modification des propriétés des objets standard présente des limites. Toutes les propriétés des champs standard ne peuvent pas être modifiées dans leurs extensions d'objets standard. Par exemple, l'extension de la table PurchTable est le champ LineDisc. Nous pouvons contrôler la visibilité du champ et de l'étiquette, et les propriétés telles que obligatoires et modifiables ne peuvent pas être modifiées.

4. Il n'y a pas de travail dans D365, tout se fait à travers des cours.

5. Nous avons battu les modèles trop finement, et il s'est avéré que notre principe «une modification = un modèle» ne fonctionne pas.

Deuxième itération et transition vers un modèle

Au début de la deuxième itération, nous avions deux modèles qui se faisaient référence. Pour cette raison, nous ne pouvions plus transférer ces modifications indépendamment. Par conséquent, nous avons décidé de travailler dans un nouveau modèle, dans lequel il était nécessaire de transférer toutes les modifications existantes.

Un modèle dans D365 est une collection de fichiers source situés dans un répertoire séparé. Lors de la compilation, ils sont collectés dans une bibliothèque distincte qui a un lien avec d'autres bibliothèques.

Par conséquent, la fusion en un modèle sur DevBox se résumait au transfert de fichiers d'un répertoire à un autre et à la suppression des anciens répertoires.

Nous avons donc construit un nouveau modèle, obtenu sa dernière version sur chaque DevBox, puis continué à travailler dans le cadre d'un modèle sur les environnements de développement.

Naturellement, nous avons déjà transféré quelques modèles pour les tests sur l'environnement SAT. Par conséquent, il était nécessaire de les supprimer et d'en libérer un nouveau.

Toutes les mises à jour de l'environnement SAT ont été effectuées à l'aide de packages, y compris la suppression des modèles. Nous avons créé un package avec des modèles vides qui doivent être supprimés et y avons ajouté un script avec les noms de ces modèles. Ensuite, nous avons collecté un package avec un nouveau modèle et l'avons déployé dans l'environnement SAT. Ainsi, SAT a obtenu un nouveau modèle.

Lorsque les modèles ont été combinés, nous avons remarqué que chaque développeur nomme les extensions d'objets à sa manière. Nous nous sommes mis d'accord sur les règles de dénomination des objets selon le modèle: PurchTable.LamodaModelFormExtension, PurchTableTypeLamodaModelClass_Extension .

Nous avons également convenu dans l'équipe que pour un objet standard, nous ne créons qu'une seule extension et y apportons des modifications.

J'ai sélectionné quelques modifications intéressantes que nous avons apportées à ce stade. Ils montrent des approches de développement possibles dans D365.

Tâche 1

Lors de l'enregistrement de la facture de la commande client, il était nécessaire de remplacer le numéro de facture par le numéro de la commande. Pour ce faire, nous avons défini une classe standard avec possibilité d'extension, ce qui nous a permis d'effectuer cette modification.

Nous avons fait une extension de la classe SalesInvoiceJourCreate standard. Il y a Next dans sa méthode getNumAndVoucher () - c'est notre nouveau super, il parle d'appeler le code de méthode standard. Après avoir appelé le code standard, nous avons remplacé le numéro de facture par la valeur souhaitée.

C'est l'une de nos approches de développement: utiliser des extensions et ajouter notre propre code avant ou après (en option - avant et après) l'exécution de code standard.

Tâche 2

Il était nécessaire de modifier l'affichage des totaux de la commande d'achat: regrouper les totaux par le numéro de facture du fournisseur à partir des lignes de commande d'achat. Dans ce cas, nous n'avons pas trouvé de place pour l'expansion sans réduire de moitié les performances, nous avons donc fait notre propre version des résultats sans toucher aux standards.

Tâche 3
Autre modification intéressante: dans les lignes du formulaire de bon de commande, il a été nécessaire d'ajouter des champs de la liste des articles avec possibilité de filtrage. Dans les versions précédentes, la modification était complètement inintéressante et a été résolue en ajoutant simplement une table en tant que source de données au formulaire et en chevauchant les deux méthodes.

Dans la version 7.3, nous ne pouvions pas étendre les méthodes à une source de données de formulaire standard. Pour effectuer un filtrage et ne pas créer de nouveau formulaire pour cela, nous avons ajouté la vue en tant que source de données au formulaire.

La possibilité d'étendre les méthodes à la source de données est apparue dans la version 8.1 de D365.

Conclusions après la deuxième itération

A ce stade, nous avons développé les modifications de base nécessaires au lancement du projet.

Nous avons introduit les règles de dénomination des extensions. Ils ont non seulement aidé à rendre les noms cohérents et compréhensibles, mais ont simplifié davantage la mise à jour, car nos noms ne coïncidaient pas avec les noms des objets standard du Service Pack.
J'ai été ravi de la rapidité avec laquelle les références croisées se produisent lors de la construction d'un projet ou d'un modèle.
La mise à jour des modèles dans différents types d'environnements se produit de différentes manières. Nous en étions convaincus sur un exemple de fusion de modèles.
Avant de commencer le développement d'une nouvelle modification, vous devez obtenir la dernière version du modèle, car le développement est effectué dans le cadre d'un modèle.
Le mécanisme de l'entité de données pour charger et décharger les données dans Excel lors de la mise à jour des données sur le prod s'est avéré très pratique. Notre service Data & Analytics l'utilise désormais pour récupérer les données de notre D365 basé sur le cloud.

Nous avons fait le développement principal à temps. Go Live est sorti, le modèle est en prod. Et nous avons été confrontés au problème de ne publier que des modifications testées dans le modèle. Nous voulions également faciliter le processus de débogage lors des tests de modifications et accélérer la mise à jour de l'environnement de test.

Comment ça marche maintenant

Dans la dernière itération, nous avons ajouté deux environnements: construire et tester. Une fois tous les environnements configurés et vérifiés, nous avons simplifié les tests et appris à publier uniquement les modifications testées dans le modèle.

Pour les tests, nous avons déployé un environnement à 1 niveau et l'avons connecté à la branche de développement dans le système de contrôle de version. La mise à jour consistait désormais à obtenir la dernière version du modèle lui-même et son assemblage. Dans cet environnement, nous avons fait ses débuts, comme dans la DevBox habituelle.

Les packages de build à publier sont désormais exécutés dans un nouvel environnement de build. Les modifications testées ont été transférées dans une nouvelle branche du système de contrôle de version par des changesets (packages de modifications téléchargés sur le système de contrôle de version), sur un principe du plus ancien au dernier.

Ensuite, nous avons déployé le package dans l'environnement SAT où les tests utilisateur ont eu lieu, après quoi nous avons planifié la publication du package sur le portail LCS sur le prod. Nous avons donc mis en place le processus de publication à l'aide de l'environnement de génération.

Et nous avons décidé de ne pas réviser les projets, mais les ensembles de modifications à modifier, téléchargés dans le contrôle de version.

La première mise à jour de la version cloud

Nous avons travaillé sur la version cloud, nous devions donc être mis à jour régulièrement. La première mise à jour était une transition de la version 7.3 à la version 8.0. Cela a pris environ deux semaines.

Bien sûr, nous nous sommes créés les principaux problèmes, mais nous avons aussi gagné:

Nous ne nous sommes pas immédiatement mis d'accord sur les règles de dénomination des objets standard. Dans la première mise à jour, nos noms d'objet coïncidaient avec les noms d'objets dans le Service Pack.
Lors de la mise à jour des environnements cloud, nous nous sommes nécessairement déconnectés des machines AOS, sinon le processus de mise à jour n'a pas pu être terminé avec un utilisateur connecté.
Le package de mise à jour pour les environnements prod et SAT devait être combiné avec le package de modèle.

Aujourd'hui, la mise à jour de tous nos environnements prend environ 3-4 jours et se déroule sans l'implication des développeurs. Nous pouvons même publier une version en même temps que la mise à jour, l'essentiel est que la build, SAT et prod aient la même version.

Le processus de mise à jour consiste à télécharger le package de mise à jour sur le portail lcs. La DevBox et le test sont mis à jour en premier, puis la version est mise à jour, les derniers sont SAT et prod.

Résultats de l'ensemble du premier projet

Nous avons acquis de l'expérience dans la construction de l'architecture d'application D365.
Élaboration d'une nouvelle approche pour l'examen du code.
Nous avons établi les règles de transfert des bases de données vers DevBox (dans D365, il est important d'effectuer des tests initiaux sur DevBox, et maintenant nous testons même les développeurs sur DevBox).
A écrit des directives de développement à D365.
Appris à se développer dans le cloud.

Toute cette expérience nous a aidés à développer le projet de manière plus réfléchie. Maintenant que nous connaissons les capacités du système, nous pouvons construire plus correctement l'architecture, ou plutôt définir des tâches. Les processus intégrés autour du projet facilitent la connexion des développeurs qui écrivent pour la première fois sous D365.

Développement du premier projet sur la plateforme de Microsoft Dynamics 365 For Finance and Operations