Cet article traitera des différents processus mis en place lors de l'installation d'une nouvelle version de solution. Nous avons abordé lors du précèdent billet les concepts de base des solutions Dynamics CRM 2011 à savoir:
Si vous n'êtes pas familier avec ces notions merci de lire le précédent post Solutions Dynamics CRM 2011 et bonnes pratiques associées: Concepts clés afin de bénéficier au mieux du contenu de cet article.
Lorsqu'une solution est mise à jour nous devons tenir comptes des 4 processus suivants:
La mise à jour des couches CRM dépend de leur état, gérée ou non gérée.
Lorsque nous importons une unique solution non gérée dans notre organisation CRM, tous les
composants personnalisés préexistants contenus sur notre plateforme sont remplacés par les
composants de la solution non gérée installée.
Par exemple si je renomme l’entité Compte en Client et Opportunité en Projet ces deux modifications
seront appliquées à notre plateforme.
Les solutions non gérées fusionnent les composants selon certains critères que nous aborderons dans la
section Résolution des conflits de configuration
Lors de l’import d’une solution gérée dans une organisation dans laquelle cette solution existe déjà,
l'écran d'options d'importation vous invite à choisir la méthode de mise à jour de la solution.
Il est possible de remplacer ou non les configurations effectuées sur les éléments de la solution.
Si vous choisissez de conserver les personnalisations :
Le schéma ci-dessous modélise l'installation d'une version V2.0 de la solution gérée avec conservation des personnalisations:
L’approche recommandée est celle de toujours préserver les configurations effectuées (sans écrasement). Cette approche permet de conserver dans l’environnement cible les ajustements effectués sur les configurations.
Si les mises à jour sont obligatoires pour que les fonctionnalités opèrent correctement, il est alors nécessaire de procéder au remplacement des configurations effectuées :
Une utilisation judicieuse des propriétés gérées (verrouiller celles-ci au maximum) permet de ne pas avoir recours à ce remplacement de configuration.
Lorsque plusieurs solutions définissent des composants différemment, Microsoft Dynamics CRM résout le conflit en utilisant deux stratégies : Fusion ou La plus haute gagne (en anglais: Top wins).
Pour les composants supportant la fusion tels que les formulaires, le ruban, le plan du site, Microsoft Dynamics CRM applique les couches dans l’ordre suivant :
Les éléments sont calculés du plus bas niveau au plus haut niveau des couches afin que la couche non gérée s’applique en dernier.
Ci-dessous un exemple plus concret :
Pour tous les autres composants d’une solution CRM, la stratégie de résolution des conflits est plus simple, la dernière solution importée prend le pas sur les autres solutions. Dans l’exemple suivant le nom d’affichage de l’entité Compte est modifié par plusieurs solutions :
Le framework suit automatiquement les dépendances des composants de solution. Toute opération sur un composant calcule automatiquement toute dépendance avec d’autres composants du système. Les informations de dépendance sont utilisées pour maintenir l’intégrité du système et se prémunir d’opérations qui mèneraient à un état instable.
Les règles suivantes s’appliquent dans le cadre du contrôle de dépendance :
La notion d’éditeur est importante dans le cas des solutions gérées car elle implique les comportements suivants :
Les deux premiers articles de la série Solutions Dynamics CRM 2011 et bonnes pratiques associées, nous ont permis de découvrir l'essentiel des connaissances nécessaires à la bonne compréhension de la gestion des solutions Dynamics CRM.
Pour parfaire cette série d'article, le prochain billet décrira différents scénarios de livraison d'une solution Dynamics CRM 2011.