Solutions

Effectué

Les solutions sont des conteneurs qui suivent et gèrent les personnalisations dans un environnement Dataverse. Les solutions permettent de transporter des applications et des composants d’un environnement à un autre ou d’appliquer un ensemble de personnalisations à des applications existantes.

Lorsque vous disposez de plusieurs environnements, chacun d’entre eux possède son propre ensemble de solutions.

Schéma qui montre l’environnement de présentation de la solution.

Remarque

Si vous possédez une application Microsoft Dynamics 365 telle que Sales, celle-ci est installée à l’aide de la même infrastructure de solution. Les éditeurs de logiciels indépendants livrent également leurs produits à l’aide de solutions.

Les caractéristiques des solutions sont les suivantes :

  • Incluez les métadonnées et certaines entités avec les données de configuration. Les solutions ne comportent pas de données métier.
  • Elles comportent de nombreux composants Microsoft Power Platform tels que les applications pilotées par modèle, les applications canevas, les plans de site, les flux, les tables, les métadonnées de table, les colonnes, les formulaires, les vues, les règles métier, les définitions de processus, les connecteurs personnalisés, les ressources web, les choix, les graphiques et les composants créés par des développeurs tels que des scripts ou du code compilé.
  • Elles sont intégrées en tant qu’unité pour être exportées et importées dans d’autres environnements, ou elles sont déconstruites et enregistrées dans le contrôle de code source comme code source pour les actifs.
  • Elles permettent d’appliquer des modifications aux solutions existantes.

Types de solutions

Voici deux types de solutions :

  • Non gérée : type utilisé pendant le développement et pour le transport vers d’autres environnements de développement.
  • Gérée : type permettant d’effectuer une distribution dans les environnements hors développement.

Vous utilisez des solutions non gérées dans des environnements de développement lorsque vous apporterez des modifications à la configuration de votre application. Les solutions sont exportées comme non gérées, puis vérifiées dans votre système de contrôle de code source. Les solutions non gérées doivent être considérées comme votre source.

Effectuez vos déploiements à l’aide de solutions gérées dans tout environnement autre qu’un environnement de développement, y compris les environnements de test, de test d’acceptation utilisateur (UAT), de test d’intégration système (SIT) et de production.

Les solutions gérées peuvent être gérées (mise à niveau, correction et suppression) indépendamment des autres solutions gérées dans un environnement. Une bonne pratique ALM consiste à générer les solutions gérées par un serveur de build, puis à les considérer comme un artefact de build.

Superposition de solution

Les couches de solution décrivent la chaîne de dépendances d’un composant depuis la solution racine qui l’introduit, à travers chaque solution qui étend ou modifie le comportement du composant. Les couches sont créées via l’extension d’un composant existant (en prenant une dépendance sur celui-ci) ou par la création d’un composant ou d’une version d’une solution.

La superposition des solutions est implémentée au niveau des composants. Les solutions gérées et non gérées existent à des couches différentes au sein d’un environnement Microsoft Dataverse. Dataverse comporte deux couches distinctes :

  • Couche non gérée : toutes les solutions importées, non gérées et les personnalisations spécialisées existent au niveau de cette couche. Toutes les solutions non gérées partagent une seule couche non gérée.
  • Couche gérée : toutes les solutions importées et gérées et la solution système existent à ce niveau. Lorsque plusieurs solutions gérées sont installées, la dernière qui est installée est au-dessus de la solution gérée installée précédemment. Par conséquent, la deuxième solution installée peut personnaliser celle qui a été installée avant elle. Lorsque deux solutions gérées ont des définitions contradictoires, le comportement d’exécution est « Le dernier est celui qui gagne » ou une logique de fusion est implémentée. Si vous désinstallez une solution gérée, la solution gérée qui lui est inférieure prend effet. Si vous désinstallez toutes les solutions gérées, le comportement par défaut défini dans la solution système est appliqué. À la base du niveau des couches gérées se trouve la couche système. La couche système contient les entités et les composants nécessaires au fonctionnement de la plateforme.

Schéma qui montre les couches de la solution.

Les architectes de solution doivent décider du nombre de solutions qui seront utilisées pour leur solution métier. Vous pourriez travailler avec une seule solution, mais cela entraînerait des dépendances sur les versions, et les solutions volumineuses peuvent prendre beaucoup de temps à exporter et à importer. La plupart des projets utilisent plusieurs solutions. Les architectes de solution doivent comprendre le comportement de fusion lorsqu’une solution est mise à jour ou lorsque plusieurs solutions sont installées et affectent le même composant.

Dans l’exemple suivant, nous disposons de quatre solutions utilisant Common Data Model/des tables système : la solution Common Data Model Healthcare, une solution Contoso Common et deux solutions comportant des applications et en couches. Par exemple, disons que nous personnalisons le formulaire Contact dans l’extension Common Data Model Healthcare. Ensuite, si nous modifions les mêmes éléments de formulaire dans la solution Contoso Common, les utilisateurs voient les modifications de la solution Contoso Common.

Schéma montrant des exemples de couches de solution.

Structure de la solution

Voici les stratégies de création de solutions, classées par ordre du plus simple au plus complexe :

  • Solution unique
  • Solutions multiples
  • Plusieurs solutions avec des composants partagés

En créant une solution unique, vous établissez un ensemble fonctionnel de personnalisations. Cette approche facilite la recherche des éléments que vous avez personnalisés. En outre, cette approche est recommandée lorsque vous ne souhaitez créer qu’une seule solution gérée. Si vous pensez que vous devrez peut-être diviser la solution à l’avenir, envisagez d’utiliser plusieurs solutions.

Si vous disposez de deux solutions indépendantes qui ne partagent pas de composants, l’approche la plus directe consiste à créer deux solutions non gérées.

Vous pouvez avoir plusieurs solutions qui partagent des composants. Vous pouvez avoir un certain ensemble de fonctionnalités communes dans plusieurs solutions, et ces fonctionnalités communes sont compatibles avec toutes les autres fonctionnalités propres à chaque solution. Certains composants peuvent être inclus dans plusieurs solutions, si les modifications qui leur ont été apportées sont compatibles avec toutes les autres solutions qui les utilisent. Il est important que toutes les solutions partagent le même éditeur de solutions. Si l’éditeur de solutions n’est pas identique, vous ne pouvez pas installer plusieurs de vos solutions.

Règles que vous devez suivre avec des solutions :

  • Créez un éditeur de solutions et utilisez-le pour toutes les solutions.
  • N’utilisez pas l’éditeur par défaut, la solution par défaut ou la solution Dataverse par défaut.
  • Gardez la structure de la solution aussi simple que possible.
  • Évitez de cocher la case Inclure tous les composants sauf si vous ajoutez une table non gérée.
  • Incluez les métadonnées d’une table seulement si vous modifiez les propriétés de la table.
  • Ajoutez les sous-composants d’une table (colonnes, formulaires, vues, etc.) uniquement lorsque vous les modifiez.

Ajouter uniquement le nécessaire à une solution est appelé la segmentation d’une solution.

Capture d’écran présentant l’ajout d’une table.

Lorsque vous décidez de la segmentation en une ou plusieurs solutions, vous devez tenir compte des éléments suivants :

  • N’utilisez des solutions multiples que dans un but tangible, car les solutions multiples ajoutent de la complexité.
  • Évitez les solutions multiples qui partagent des composants.
  • Les solutions multiples nécessitent leur propre environnement pour garantir leur indépendance.
  • Prenez soin de gérer les dépendances.
  • Les créateurs doivent savoir dans quelle solution installer de nouveaux composants.
  • Le partitionnement horizontal et vertical sont des modèles courants de fractionnement de solutions multiples.

Division horizontale de la solution

Le fractionnement horizontal désigne la création de solutions contenant uniquement des composants du même type.

Schéma de la division horizontale de la solution.

Superposition verticale de la solution

La superposition verticale regroupe les composants en zones fonctionnelles. Souvent, vous disposez d’une base partagée/solution commune avec des solutions distinctes pour chaque domaine d’activité clé.

Schéma qui montre la superposition de la solution verticale.

Vous pouvez combiner le partitionnement vertical et horizontal, par exemple, la base qui contient toutes les tables et processus avec des solutions distinctes pour chaque application.