Solutions Dynamics CRM 2011 et bonnes pratiques associées: Mise à jour d'une solution

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:

  • Le Package CRM;
  • Les couches;
  • Les propriétés gérées des composants.

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:

  • Mise à jour des couches;
  • Résolution des conflits de configuration;
  • Suivi des dépendances;
  • Editeurs partagés.

Mise à jour des couches

La mise à jour des couches CRM dépend de leur état, gérée ou non gérée.

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

  • Solution gérée

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 :

  • Les configurations effectuées dans la couche non gérée sont conservées;
  • Importer une version incrémentée crée une nouvelle couche gérée directement au-dessus de la couche gérée de la version précédente;
  • Importer une solution de même version remplace le contenu de la couche existante;
  • Importer une solution gérée ne peut pas supprimer de composants existants.

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 :

  • Remplace le contenu de la couche « non gérée »;
  • Garantit que les mises à jour présentes dans la solution soient appliquées;
  • Remplace toutes les configurations effectuées dans l’environnement cible et doit donc être utilisé avec précaution.

 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.

Résolution des conflits 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 :

  • La couche système;
  • Les couches gérées dans l’ordre de leur import dans le CRM;
  • La couche non gérée.

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 :

Suivi des dépendances 

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 :

  • Supprimer un composant est impossible si un autre composant en dépend;
  • Exporter une solution prévient l’utilisateur s’il manque un ou des composants risquant de faire échouer l’import de la solution dans un autre environnement;
  • Les alertes durant l’export peuvent être ignorées si la solution est prévue pour être installée dans un environnement qui contient déjà les composants attendus par la solution. C’est le cas lorsque l’on crée une solution qui est destinée à être installée « au-dessus » d’une solution de base;
  • L’import d’une solution échoue si au moins l'un des composants requis n'est pas présent soit dans la solution soit dans l’environnement cible. En complément, lors de l’import d’une solution gérée tous les composants requis doivent correspondre au type de package de la solution. Un composant d’une solution gérée ne peut dépendre que d’un autre composant géré.

Editeurs partagés

La notion d’éditeur est importante dans le cas des solutions gérées car elle implique les comportements suivants :

  • Les composants présents dans des couches gérées sont la propriété de l’éditeur de leur solution;
  • Les éditeurs sont propriétaires des composants;
  • Les composants de même nom et de même éditeur sont considérés comme identiques;
  • Supprimer une solution gérée ne supprime pas un composant si celui-ci est référencé par une autre solution du même éditeur (notion d’éditeur partagé). L’utilisateur n’est pas prévenu que certains composants peuvent ne pas être supprimés.

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.

Microsoft Services / CRM – Gestion de la relation client