Guide des bonnes pratiques

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
  • 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

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.
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 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. 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.
pour mieux comprendre l’ensemble de la grille tarifaire, je vous recommande de télécharger le guide des licences rédigés par Javista en cliquant sur ce lien.
Le coût des licences peut varier de 8 euros/mois/utilisateur* (Licence team Members) à 97euros/mois/utilisateur* (Licence Entreprise Plan 1), ce qui bien évidemment peut entraîner de très lourdes conséquences sur la réussite de votre projet…
*Tarifs en cours pour l’année 2017.

Gestion des groupes et accès à Dynamics
Lorsque tous vos utilisateurs possèdent leur licence respective, les utilisateurs sont créés dans Dynamics 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, il est possible d’associer un ou plusieurs groupes :

image

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 Dynamics
    • 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 :

ComposantsConseils de nommage / de création
EntitésPour 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.




ChampsPour 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.



VuesAvant 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 »
ProcessusLe 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 postale

Avant 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.
Web RessourcesSelon 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
  • 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.


image
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 :

image

Pour informations, tous les environnements Online possèdent 3 sauvegardes. 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 dans l’administration Office 365 et ouvrir la page de gestion des environnements Dynamics 365.
Comme cité précédemment, trois versions sont stockés “gratuitement” par Microsoft (En général, les sauvegardes sont réalisées le soir).
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 !

image

Dans la nouvelle fenêtre qui s’ouvre, cliquer sur Backup and Restore. Pour chaque organisation Dynamics 365, trois sauvegardes sont présentes.
Pour en rajouter une, il suffit de cliquer sur New Backup :

image

En cliquant sur Restore, vous rétablissez la version de Dynamics.