Cette page présente un ensemble de bonnes pratiques concernant la gestion de la plateforme Dynamics.
Les grands sujets abordés sont les suivants :
- Piloter la mise en place de son projet Dynamics ou PowerApps
- Gérer le déploiement des solutions partenaires depuis l’administration de Dynamics
- Gérer les personnalisations réalisées sur une organisation de développement
- Conseils pour les livraisons sur les environnements de recette et production
Gérer la mise en place de son projet Dynamics / Power Apps
Lors de l’ouverture d’un nouveau tenant Office 365, un ensemble de composants sont mis à disposition de ou des administrateurs en charge du déploiement des organisations Dynamics ou PowerApps.
Voici une liste des trois (premiers) points clés pour assurer la réussite de votre projet Dynamics :
- Répartir les licences selon le profil des utilisateurs
- Organiser les utilisateurs en Groupe
- Avoir au minimum trois organisations Dynamics/CDS sur votre tenant (Développement, Recette et Production)
Achat des licences
L’achat des licences est la phase la plus délicate pour mener à bien un projet Dynamics ou PowerApps. Avant de vous précipiter sur l’achat des licences les plus coûteuses, il faut analyser chacun des types de licences mise à disposition par Microsoft.
Depuis plus d’un an, des licences PowerApps sont disponibles, vous pouvez les retrouver ici : https://powerapps.microsoft.com/en-us/pricing/
Ces licences ont un prix attractifs qui vous permettra de faire vos premiers pas dans l’univers de la Power Platform.
Gestion des groupes et accès à Dynamics / Power Apps
Lorsque tous vos utilisateurs possèdent leur licence respective, les utilisateurs sont créés dans Dynamics ou Dans vos applications automatiquement. L’administrateur système doit affecter au moins un rôle de sécurité afin d’accéder à la plateforme.
Les groupes de sécurité Office 365 permettent de regrouper de manière logique les utilisateurs de votre instance Office 365.
Exemple : Groupe des Key users (Groupe qui permet de lister les utilisateurs testeurs d’une application).
Pour chaque organisation Dynamics ou PowerApps, il est possible d’associer un ou plusieurs groupes :
L’accès à cette organisation est restreinte aux utilisateurs Office 365 se trouvant dans les groupes attachés.
Cela vous permet de garder le contrôle sur les accès à vos plateformes. Je vous conseille d’utiliser les groupes pour isoler les administrateurs afin qu’ils soient les seuls à accéder à la Production lors de d’une livraison par exemple.
Organisations des environnements Dynamics pour un projet
Pour mener à bien un projet Dynamics et garantir la pérennité de votre application, je vous conseille au minimum de posséder l’architecture suivante :
- 3 organisations Dynamicsou CDS
- 1 Environnement de développement
- 1 Environnement de tests
- 1 Environnement de Production
- 3 Groupes de sécurité Office 365
- 1 groupe avec uniquement les administrateurs
- 1 groupe de Key users + les administrateurs
- 1 groupe avec l’ensemble des utilisateurs Dynamics
Analyse de l’architecture cible
Pour tout projet informatique de manière général, il est toujours important de lister les objectifs et comment les atteindre, en résumé, quels vont être les moyens ou les cas d’utilisation à appliquer pour atteindre les objectifs fixés par la direction.
Exemple : La direction souhaite augmenter le nombre de prospects qualifiés à contacter.
Le cas d’utilisation ou user story correspondant peut être : En tant que responsable marketing, je souhaite pouvoir créer de nouveaux prospects et les qualifier.
Mais avant de commencer tout type de développement, je conseille toujours de prendre un stylo et une feuille brouillon pour dessiner l’architecture des entités qui seront utilisées dans l’application (Même s’il s’agit d’entités standards). Il est toujours préférable de valider ces points avant de débuter la réalisation.
Mise en place de l’environnement de développement
Comme son nom l’indique, l’environnement de développement est l’organisation Dynamics qui représente le point de départ de votre projet. En premier lieu, vous devez y créer les éléments suivants:
- Un éditeur Dynamics CRM : voir l’article dédié aux éditeurs Dynamics en cliquant ici
- Une solution Dynamics contenant l’éditeur précédemment créé : Toutes les modifications sur les composants Dynamics doivent être réalisées depuis cette solution
Ces deux éléments sont capitaux pour organiser votre travail et être sur de ne pas oublier des composants lors de vos futures livraisons. La perte de temps est considérable lorsqu’un élément est manquant lors d’une livraison (Surtout si les personnes qui extraient la solution et celles qui les importent sur l’environnement de tests sont différentes…)
Pour les composants de solution, voici un tableau indiquant quelques bonnes pratiques à suivre :
| Composants | Conseils de nommage / de création |
| Applications | Les applications permettent d’organiser vos données comme vous le souhaitez. Les deux applications pour un utilisation orientée interne (Utlisateurs sous licences) sont : – Model Driven App : La structure de ce type d’applciation est fixe (Navigation à gauche et visualisation de la donnée au .milieu de l’écran) Cette applciation est à privilégier sur vous voulez réaliser un projet rapide et accompagné. – Canvas App : Les applications Canvas sont à structure de A à Z. Il est possible de construire sa propre acrchitecture et son propre UX Design (Couleur, position des formulaire, enchaînement des pages, etc.) Ce type d’application est à privilégier pour tous les projets mobiles ou tablettes. |
| Entités | Pour la création d’une nouvelle entité, faites attention à bien sélectionner quels types de propriétaires seront associés à votre entité : · Utilisateur ou équipe · Organisation Cela impacte les niveaux de privilège dans les rôles de sécurité. Je vous conseille de mettre les entités type Référentiels au niveau organisation (Exemple : Les pays) Au niveau des propriétés, je vous conseille de désélectionner les options, surtout celles avec une petite croix, car une fois activées, elles ne sont plus dés activables. Et enfin, n’oublier pas de changer le nom technique du champ par défaut. |
| Champs | Pour la création de nouveaux champs, il faut faire attention au type de champs que vous créez. Le erreurs fréquentes sont souvent : · Un champ Décimal à la place d’un champ Devise · Créer une picklist global et non un groupe d’option · Etc. Avant de créer un champ, je vous conseille de chercher parmi les champs existants de l’entité. La majorité des champs standards répondent aux besoins d’un projet. Pour les nomenclatures techniques, voici quelques bonnes pratiques à respecter (Cela aidera grandement vos développeurs ou expert PowerBI – Type Lookup : Ajouter le suffixe Id – Type Date : Ajoouter le suffixe Date – Type Picklist : Ajouter le suffixe Code – Type Deux Options : Ajouter le prefixe Is ou Has. Exemple : new_IsContractAccepted. |
| Vues | Avant de créer une vue système, il est préférable de privilégier les vues utilisateurs. Ces dernières peuvent être testées sur un périmètre restreint d’utilisateurs avant de les transformer en vues systèmes pour qu’elles soient disponibles pour l’ensemble des utilisateurs. |
| Onglet/ Section (formulaire) | Pour les onglets et sections, petite remarque, n’oublier pas de changer les noms techniques pour qu’ils soient logiques. Si ces objets sont utilisés dans du Javascript, un nom « MoneyTab » est toujours plus logique que « Tab1_Section1 » |
| Processus | Le nom des processus doivent correspondre à la principale action réalisée par le processus. Par exemple : Contact – Envoi d’email suite à la mise à jour de l’adresse postaleAvant qu’un processus automatique agisse sur une base de données entière (Avec les potentiels risquent d’erreur), il faut, idéalement, toujours vérifier le fonctionnement d’un processus en activant le déclenchement manuel. Vous pouvez créer une vue dans la recherche avancée pour isoler des données tests et lancer le processus. Si le résultat est concluant, vous pouvez activer les déclencheurs automatiques. UPDATE : Depuis la mise en route de Power Automate, il faut privilégier la création de Flows plutôt que de Workflows. Cependant, si votre processus doit être en temps réel alors privilégier les workflows classiques. |
| Web Ressources | Selon le type de web ressource créé, les noms doivent être préfixés ainsi : Images des entités : [prefixeprojet]_/Images/Entities/[NomEntité][16 ou 32].png Pour les applications par modèle ou Canvas : [prefixeprojet]_/Images/Entities/[NomEntité].svg Scripts de formulaires : [prefixeprojet]_/Scripts/Form/[NomEntité].js Scripts partagés (Bibliothèque) : [prefixeprojet]_/Scripts/Shared/[Nombibliothèque].js Page HTML : [prefixeprojet]_/Pages/[Fonctionnalité]/[Nom].js |
Livraison des solutions entre les environnements
La solution extraite qui est déployée sur les environnements de tests puis de production doit être au format gérée. Les composants se trouvant dans une solution déployée avec ce format sont non-modifiables.
Le format géré permet d’ajouter une “sur-couche” de personnalisations sans modifier le socle non gérée d’une organisation Dynamics. En d’autres termes, une solution gérée peut être installée et désinstallée d’une application Dynamics. La désinstallation réapplique les personnalisations de la couche non gérée.
Sur le schéma ci-dessous, les deux blocs vert et orange sont amovibles tandis que le bloc gris est inamovible. Il est impossible de faire machine arrière si la couche non gérée est modifiée.
Ainsi, seul l’environnement de développement possède une couche non gérée complétement modifiée tandis que les environnements de tests et de production.
Pour les livraisons de solution entre les environnements, le schéma solide le plus simple est le suivant :
Pour informations, tous les environnements possèdent des sauvegardes automatiques réalisées tous les jours. Dans le centre d’administration, il y a un onglet consacrer aux sauvegardes de toutes vos organisations.
Avant chaque livraison en Production, je vous conseille de faire une sauvegarde manuelle.
Sauvegarde des environnements Microsoft
Pour faire une sauvegarde de vos environnements, ou tout simplement voir les sauvegardes historiques disponibles, il faut se rendre sur le lien suivant : https://admin.powerplatform.microsoft.com/. Comme cité précédemment, des versions de votre CDS sont backupés automatiquement.
Attention : Une sauvegarde manuelle occupe l’espace que vous avez à disposition. Donc faites bien attention à ne pas copier une base qui risque de faire exploser votre quota !
Dans la nouvelle fenêtre, cliquer sur Sauvegarde puis choisir Créer. Puis compléter les informations sur la droite de l’écran et lancer la création de votre backup :
En cliquant sur Sauvegarde, cliquer sur Restaurer ou gérer pour réappliquer un backup d’un environnement CDS. Deux menus vous progressent de restaurer soit les backups automatiques effectuées à une certaine date soit de prendre un backup manuel.
[…] Guide des bonnes pratiques […]