Créer des correctifs pour simplifier les mises à jour de solution
Cette rubrique s’applique à Dynamics 365 Customer Engagement (on-premises). Pour la version Power Apps de cette rubrique, consultez : Créer des correctifs pour simplifier les mises à jour de solution.
Si vous ajoutez une entité à une solution et exportez la solution, l’entité et toutes ses ressources associées sont exportées dans cette solution. Ces ressources comprennent les attributs, formulaires, vues, relations, visualisations et autres ressources qui sont fournis avec l’entité. L’exportation de tous les objets signifie que vous pouvez modifier involontairement des objets sur le déploiement cible, ou conserver des dépendances fortuites.
Pour résoudre ce problème, vous pouvez créer et publier des correctifs de solution contenant des sous-composants d’entités au lieu de publier l’entité entière et toutes ses ressources. La solution d’origine et un ou plusieurs correctifs associés peuvent être reportés (fusionnés) ultérieurement dans une version mise à jour de la solution, qui peut ensuite remplacer la solution d’origine dans l’organisation Dynamics 365 Customer Engagement (on-premises) cible.
Correctifs
Vous pouvez appliquer des correctifs aux solutions gérées ou non gérées et inclure uniquement les modifications apportées aux entités et aux ressources d’entité associées. Les correctifs ne contiennent pas des composants système non personnalisés ou des relations dépendantes, car ces composants existant déjà dans l’organisation de déploiement. À un certain stade du cycle de développement, vous pouvez reporter tous les correctifs dans une nouvelle version de la solution pour remplacer la solution d’origine à partir de laquelle les correctifs ont été créés.
Les correctifs sont stockés dans la base de données Customer Engagement en tant qu’enregistrements d’entité de la Solution. Un attribut ParentSolutionId autre que zéro indique que la solution est un correctif. Les correctifs peuvent être créés et gérés via les API de service d’organisation ou les API web, qui sont utiles pour développer l’automatisation, par exemple un script d’installation de produit. Toutefois, l’application web Customer Engagement fournit plusieurs formulaires web qui vous permettent de créer et de gérer de manière interactive des correctifs.
Les correctifs peuvent être créés uniquement à partir d’une solution parente à l’aide du message CloneAsPatchRequest ou de l’action CloneAsPatch
Le parent du correctif ne peut pas être un correctif.
Les correctifs ne peuvent posséder qu’une solution parente.
Un correctif crée une dépendance (au niveau de solution) dans sa solution parente.
Vous pouvez installer un correctif uniquement si la solution parente est présente.
Vous ne pouvez pas installer un correctif sauf si le nom unique et le numéro de la version principale/secondaire de la solution parente, identifiés par
ParentSolutionId, correspondent à ceux de la solution parente installée dans l’organisation cible.Un correctif doit avoir le même numéro de version principale et secondaire que la solution parente, mais un numéro de build et de version supérieur. Le nom complet peut être différent.
Si une solution contient des correctifs, les correctifs suivants doivent avoir un numéro de version numériquement supérieur à un correctif existant pour cette solution.
Les correctifs prennent en charge les mêmes opérations que les solutions, comme la mise à jour additive, mais pas la suppression. Vous ne pouvez pas supprimer des composants d’une solution avec un correctif. Pour supprimer des composants d’une solution, effectuez une mise à niveau.
Les correctifs exportés comme gérés doivent être importés en haut d’une solution parente gérée. La règle est que la protection du correctif (géré ou non) doit correspondre à son parent.
N’utilisez pas les correctifs non gérés pour les besoins de production.
Les correctifs ne sont pris en charge que dans l’organisation des applications Customer Engagement de la version 8.0 et ultérieure.
Lorsqu’un correctif est installé, il est installé uniquement au-dessus de la solution de base qu’il corrige et en dessous de toutes les solutions au-dessus. Cela signifie que tous les solutions au-dessus remplaceront les paramètres dans le correctif pour le même type de composant.
Les outils SolutionPackager et PackageDeployer de cette version prennent en charge les correctifs de solution. Consultez l’aide en ligne de l’outil pour connaître toutes les options de ligne de commande associées aux correctifs.
Créer un correctif
Créez un correctif à partir d’une solution non gérée dans une organisation en utilisant le message CloneAsPatchRequest ou l’action CloneAsPatch, ou encore via l’application Web. Après avoir créé le correctif, la solution d’origine est verrouillée et il n’est pas possible de la modifier ou de l’exporter tant que des correctifs dépendants existant dans l’organisation identifient la solution comme solution parente. Le contrôle de version du correctif est similaire au contrôle de version de la solution et est spécifié au format suivant : principale.secondaire.build.version. Vous ne pouvez pas apporter des modifications aux versions principales ou secondaires existantes de la solution lorsque vous créez un correctif.
Exporter et importer un correctif
Vous pouvez utiliser les API de service d’organisation ou web, l’application web ou l’outil Package Deployer pour exporter et importer un correctif. Les demandes de message de service d’organisation appropriées sont ImportSolutionRequest et ExportSolutionRequest. Les actions pertinentes pour l’API Web sont l’action ImportSolution et l’action ExportSolution.
Exemples de correctifs
Le tableau suivant répertorie les détails d’un exemple de correctif. Notez que dans cet exemple, la solution et les correctifs sont importés dans l’ordre numérique et sont additifs, ce qui est cohérent avec l’importation de la solution en général.
| Nom du correctif | Description |
|---|---|
| SolutionA, version 1.0 (non gérée) | Contient entityA avec 6 champs. |
| SolutionA, version 1.0.1.0 (non gérée) | Contient entityA avec 6 champs (3 ont été mis à jour) et ajoute entityB avec 10 champs. |
| SolutionA, version 1.0.2.0 (non gérée) | Contient entityC avec 10 champs. |
Le processus d’importation se présente comme suit :
Le développeur ou le personnalisateur importe d’abord la solution de base (SolutionA 1.0) dans l’organisation. Le résultat est entityA avec 6 champs dans l’organisation.
Ensuite, le correctif 1.0.1.0 de SolutionA est importé. L’organisation contient maintenant entityA avec 6 champs (3 ont été mis à jour), plus entityB avec 10 champs.
Enfin, le correctif 1.0.2.0 de SolutionA est importé. L’organisation contient maintenant entityA avec 6 champs (3 ont été mis à jour), plus entityB avec 10 champs, plus entityC avec 10 champs.
Autre exemple de correctif
Prenons un autre exemple de correctif, avec les détails répertoriés dans le tableau suivant.
| Nom du correctif | Description |
|---|---|
| SolutionA, version 1.0 (solution de base non gérée) | Contient l’entité Account dont la longueur du champ du numéro de compte est ajustée de 20 à 30 caractères. |
| SolutionB, version 2.0 (fournisseur différent non géré) | Contient l’entité Account dont la longueur du champ du numéro de compte est ajustée à 50 caractères. |
| SolutionA, version 1.0.1.0 (correctif non géré) | Contient une mise à jour de l’entité Account dont la longueur du champ du numéro de compte est ajustée à 35 caractères. |
Le processus d’importation se présente comme suit :
Le développeur ou le personnalisateur importe d’abord la solution de base (SolutionA 1.0) dans l’organisation. Le résultat est une entité
Accountavec un champ de numéro de compte de 30 caractères.La SolutionB est importée. L’organisation contient maintenant une entité
Accountavec un champ de numéro de compte de 50 caractères.Le correctif 1.0.1.0 de SolutionA est importé. L’organisation contient toujours une entité
Accountavec un champ de numéro de compte de 50 caractères, tel qu’appliqué par SolutionB.La SolutionB est désinstallée. L’organisation contient maintenant une entité
Accountavec un champ de numéro de compte de 35 caractères, tel qu’appliqué par le correctif 1.0.1.0 de SolutionA.
Supprimer un correctif
Vous pouvez supprimer un correctif ou une solution de base (parente) à l’aide du message DeleteRequest ou, pour l’API web, à l’aide de la méthode HTTP DELETE. Le processus de suppression est différent pour une solution gérée ou non gérée contenant un ou plusieurs correctifs existant dans l’organisation.
Pour une solution non gérée, vous devez d’abord désinstaller tous les correctifs de la solution de base, dans l’ordre de version inverse de leur création, avant de désinstaller la solution de base.
Pour une solution gérée, vous désinstallez simplement la solution de base. Le système Customer Engagement désinstalle automatiquement les correctifs dans l’ordre de version inverse avant de désinstaller la solution de base. Vous pouvez également désinstaller un seul correctif.
Mettre à jour une solution
La mise à jour d’une solution implique le report (fusion) de tous les correctifs de cette solution dans une nouvelle version de la solution. Ensuite, cette solution est débloquée et peut être modifiée à nouveau (solution non gérée uniquement) ou exportée. Pour une solution gérée, aucune modification supplémentaire de la solution n’est autorisée, sauf pour créer des correctifs à partir de la solution nouvellement mise à jour. Pour déployer des correctifs dans une solution non gérée, utilisez le message CloneAsSolutionRequest ou l’action CloneAsSolution. Le clonage d’une solution crée une nouvelle version de la solution non gérée, en incorporant tous ses correctifs, avec un numéro de version principale.secondaire supérieur, le même nom unique et un nom complet.
Pour une solution gérée, la procédure est légèrement différente. Vous clonez d’abord la solution non gérée (A), en incorporant tous ses correctifs, puis en l’exportant en tant que solution gérée (B). Dans l’organisation cible contenant la version gérée de la solution (A) et ses correctifs, vous importez une solution gérée (B), puis exécutez le message DeleteAndPromoteRequest ou l’action DeleteAndPromote pour remplacer la solution gérée (A) et ses correctifs par la solution gérée mise à niveau (B) dont le numéro de version est supérieur.
Voir aussi
Utiliser des solutions segmentées et des correctifs pour simplifier les mises à jour de solution
Plan de développement de solutions
Empaqueter et distribuer les extensions à l’aide des solutions
Entité Solution
Maintenir les solutions gérées
Publier votre application sur AppSource