Déterminer quand configurer ou quand coder
En tant que développeur, vous devez aborder les applications sur Microsoft Power Platform en tenant compte du fait que l’écriture de code pour obtenir la fonctionnalité d’application commerciale souhaitée doit être considérée comme une exception aux approches sans code et low-code. Toutefois, les domaines de qualité tels que la maintenabilité, l’évolutivité, la stabilité et les performances doivent également être pris en compte lorsque vous déterminez la meilleure approche pour un scénario donné.
Il est important de savoir ce que Microsoft Power Platform permet d’accomplir avec ses fonctionnalités standard car cela vous évitera de développer des fonctions qui sont déjà disponibles et qu’il suffit de configurer. Cela s’applique également aux fonctionnalités implémentées dans les applications Dynamics 365 disponibles. Par exemple, les calculs de factures à l’aide de tarifs multi-devises variables sont complexes, mais ils sont bien implémentés et testés au fil du temps dans Dynamics 365 Sales. Si cette fonctionnalité est requise, vous devez envisager d’utiliser les fonctionnalités intégrées de Dynamics 365 Sales au lieu d’implémenter votre propre moteur de calcul.
Vous devez également reconnaître que Microsoft Power Platform met souvent en œuvre un élément d’une manière particulière, qui profite à la plateforme. Cela peut être différent si vous avez l’habitude de le faire dans un code d’application personnalisé. Il n’est pas rare que les développeurs qui commencent à concevoir des solutions Microsoft Power Platform essaient de personnaliser la plateforme selon leur manière de développer des applications personnalisées. Cela doit être évité dans la mesure du possible et vous devez essayer de tirer parti des performances de la plateforme plutôt que d’essayer de la changer en fonction de ce que vous avez l’habitude de faire. Par exemple, dans le passé, vous avez peut-être implémenté une sécurité au niveau des colonnes à l’aide d’un code personnalisé. Ceci n’est cependant pas obligatoire dans Dataverse où la sécurité au niveau des colonnes est une fonctionnalité prête à l’emploi qui doit simplement être configurée.
Règles métier et Client Script
Les règles métier ont l’avantage d’être faciles à comprendre et à implémenter pour un utilisateur qui n’est pas un développeur, et elles peuvent être incluses dans le cadre d’une solution Dataverse en vue du déploiement en production. Dans les organisations où les compétences des développeurs ne sont pas aisément disponibles et où l’Application Lifecycle Management n’est pas implémenté, les règles métier seraient un moyen privilégié d’implémenter la logique, même si certaines solutions de contournement sont nécessaires, par exemple, des champs calculés intermédiaires contenant les valeurs pour archiver une règle.
Cependant, à partir d’un certain point, les règles métier ne permettent pas de répondre aux exigences de l’entreprise, ou la complexité imposée par les règles peut amener les développeurs à préférer écrire la logique dans Client Script. Par exemple, si vous avez une logique imbriquée complexe « si/alors/sinon », celle-ci serait mieux réalisée avec une instruction changer ou avec une simple séquence de blocs si. Un autre cas concerne les valeurs dynamiques qui ne sont pas aisément accessibles par une règle métier. Par exemple, les notifications de formulaire et les valeurs en termes de choix ne sont pas disponibles au moyen des règles métier.
Flux de travail/flux Power Automate ou plug-ins
Dataverse propose diverses méthodes d’implémentation d’une logique pour répondre aux événements système, en particulier aux modifications de données telles que la création, la mise à jour et la suppression des lignes de données. Les exigences de l’entreprise peuvent être satisfaites par des solutions sans code utilisant un flux de travail et Power Automate et en étendant Dataverse avec du code côté serveur (plugins) ou côté client (script).
Vous pouvez évaluer les options à l’aide d’une approche similaire à celle utilisée dans la discussion sur les règles d’entreprise et Client Script : déterminez quelles sont les exigences de l’entreprise et les capacités de l’organisation pour y répondre. Il existe également des différences fondamentales dans les capacités. Le tableau suivant peut vous aider à déterminer quand il peut être préférable d’utiliser une approche en particulier.
| Fonctionnalité | Flux Power Automate | Flux de travail | Plug-in |
|---|---|---|---|
| Synchrone ou asynchrone | Asynchrone | L’un ou l’autre (les flux Power Automate sont recommandés par rapport aux flux de travail asynchrones) | L’un ou l’autre |
| Accès aux données externes | Oui, avec des connecteurs | Non | Oui, en utilisant les API, certaines restrictions de sécurité |
| Maintenance | Concepteurs | Utilisateurs professionnels | Développeurs |
| Peut s’exécuter en tant que | Utilisateur actuel ou propriétaire du flux | Utilisateur actuel ou propriétaire du flux de travail | Tout utilisateur sous licence, système ou utilisateur actuel |
| Peut s’exécuter à la demande | Oui | Oui | Non |
| Peut imbriquer des processus enfants | Oui | Oui | Oui |
| Phase d’exécution | Après | Avant/après | Avant/après |
| Déclencheurs | Créer, changer de colonne, supprimer, à la demande, programmé | Créer, changer de colonne, supprimer, à la demande | Créer, changer de colonne, supprimer, autres messages, y compris personnalisés |
Microsoft Power Platform évolue continuellement et en tant que développeur, vous devez être au fait des fonctionnalités nouvelles et à venir. Par exemple, si votre solution nécessite des paramètres personnalisés ou des valeurs de configuration, vous devez auparavant utiliser des tables personnalisées pour stocker ces valeurs, puis utiliser du code personnalisé ou des outils de plateforme pour déployer les données. Le nouvel ajout de variables d’environnement a simplifié cette tâche et il vous suffit désormais de déclarer vos variables, en les incluant dans le cadre des solutions, puis de définir les valeurs, le tout sans aucun code.
Power Apps Component Framework (PCF)
Pendant de nombreuses années, les ressources web HTML étaient un mécanisme d’extensibilité incontournable côté client dans les applications pilotées par modèle. L’une des faiblesses de cette approche était la faible réutilisation de ces éléments monolithiques et non extensibles. Désormais, les ressources web HTML ont été remplacées par des contrôles PCF.
PCF permet aux développeurs de créer des composants réutilisables qui peuvent être utilisés par les concepteurs au lieu des contrôles standard. Il s’agit d’un bon exemple de cas où les progrès des capacités de la plateforme permettent aux entreprises de concentrer leurs efforts de développement sur la création d’une infrastructure solide et de donner de nouvelles possibilités aux concepteurs d’applications.
Systèmes externes
Les communications avec les systèmes externes sont une caractéristique commune des implémentations de solution. Depuis des tâches simples, telles que l’envoi d’un message SMS ou la mise à jour des taux de change de devise, jusqu’à des scénarios complexes de synchronisation de données, tout cela relevait auparavant exclusivement du domaine du développement. Les implémentations utilisaient des plugins, la publication d’événements via des points de terminaison de service et des webhooks.
Cependant, avec l’adoption de Power Automate et de ses centaines de connecteurs, les interactions avec les systèmes externes peuvent désormais être implémentées par les créateurs d’applications sans utiliser de code.
Cela ne signifie pas, cependant, que le rôle du développeur est redondant. Il existe de nombreux scénarios complexes ou à hautes performances où du code est requis. De plus, les développeurs peuvent désormais concentrer leurs efforts sur la création de services et de connecteurs personnalisés tout en déléguant la connexion des blocs élémentaires aux concepteurs.
Portails et sites personnalisés
Power Pages fournit de nombreuses fonctionnalités prêtes à l’emploi et permet aux concepteurs de créer des sites web robustes et de les faire évoluer si besoin. Les développeurs participent souvent à des tâches de portail plus complexes, telles que des mises en page sophistiquées (à l’aide d’un langage de modélisation liquide) ou l’extension des fonctionnalités du site frontal à l’aide de JavaScript.
Pour les scénarios hautement spécialisés, vous pouvez décider de créer un portail personnalisé complet en utilisant ASP.NET ou des technologies similaires. Cette approche n’est pas rare mais nécessite des développeurs hautement qualifiés pour sa mise en œuvre. Encore une fois, la décision consiste souvent en un compromis entre une implémentation sans code d’une fonctionnalité standard mais généralisée et une utilisation contrôlée des ressources du développeur pour fournir des fonctionnalités spécialisées.
Le fait de décider quand utiliser le code n’est pas une simple décision binaire. Vous devez prendre en compte de nombreux facteurs : les compétences et les ressources dont vous disposez, la maturité de votre organisation en matière d’Application Lifecycle Management, la complexité des besoins, etc. Souvent, les besoins doivent être évalués au cas par cas, car un léger compromis dans les contraintes métier peut simplifier la solution et faire d’un projet de développement complexe un simple exercice de configuration.
Des connaissances solides, à jour et une compréhension des fonctionnalités de la plateforme sont essentielles, afin que chaque développeur puisse prendre des décisions rationnelles et de bon sens quant au moment opportun d’utiliser le code et d’adapter le système de sorte que celui-ci puisse être personnalisé et configuré en fonction des concepteurs et des utilisateurs métier.