Importer une solution dans un environnement

Objectif

Importer un package de solution dans un environnement cible pour que les entités, formulaires, vues et règles construits ailleurs soient recréés dans cet environnement.

Prérequis

• Vous êtes connecté au Centre de contrôle d’administration en tant qu’administrateur de la plateforme.
• Vous disposez d’un fichier de package de solution exporté depuis un autre environnement (voir Exporter une solution).
• L’environnement cible existe et est Actif (voir Créer un environnement).

Étapes

1. Sélectionnez l’environnement cible en haut du Centre de contrôle d’administration — une solution s’importe dans un environnement : l’importation s’applique donc à l’environnement actuellement sélectionné.
2. Ouvrez la page Solutions depuis la navigation supérieure.
3. Sélectionnez Importer.
4. Fournissez le package de solution que vous avez exporté.
5. Si le package contient des données de démonstration, la question vous est posée avant toute importation : cochez Inclure les données de démonstration pour importer ces lignes, puis sélectionnez Importer. La case reste décochée tant que vous ne la cochez pas, et elle est désactivée pour un environnement de production. Les lignes de configuration du package sont toujours importées, et un package sans lignes de démonstration ne pose pas la question.
6. La solution est déployée immédiatement — comme dans Power Apps, une importation s’applique directement dans l’environnement sélectionné. La solution importée (gérée) apparaît ensuite dans la liste des solutions, et les créateurs peuvent utiliser ses composants.

Ce qui se passe en coulisses

Avant toute application, le package est validé et ses dépendances sont vérifiées — chaque formulaire, vue et règle doit faire référence à une entité qui se trouve soit dans le même package, soit déjà dans l’environnement cible. Les entités et leurs tables sont ensuite créées dans l’espace de données isolé propre à l’environnement cible, et les formulaires, vues et règles y sont enregistrés. Chaque environnement conserve ses propres données, séparément : la solution importée démarre donc vide dans l’environnement cible.

L’importation est répétable : si un composant existe déjà dans la cible — parce qu’il s’agit du formulaire ou de la vue intégrés d’une table standard, ou parce que vous importez de nouveau la même solution —, il est mis à jour sur place au lieu de provoquer une erreur ; une solution qui ajoute un champ à une table standard s’importe donc proprement, même si cette table (et ses formulaires et vues par défaut) est déjà présente.

Cela vaut aussi pour les groupes d’options. Un groupe d’options déjà présent dans la cible est mis à jour d’après celui qui est importé : les libellés et l’ordre sont actualisés, les nouvelles options sont ajoutées, et les options que le groupe importé ne contient plus sont supprimées. Les options sont mises en correspondance par la valeur que leur a attribuée la plateforme : une option renommée est donc mise à jour plutôt qu’ajoutée en double, et aucun enregistrement ne voit jamais la signification de sa valeur stockée changer à son insu. Deux situations arrêtent en revanche l’importation, car aucune ne peut être résolue sans perte de données : un groupe d’options qui porte le même nom qu’un groupe déjà présent mais appartient à un autre éditeur, et la suppression d’une option que des enregistrements utilisent encore.

Les importations s’appliquent immédiatement. Une étape d’approbation par environnement pour les environnements de niveau supérieur (Test, Production) est prévue dans le cadre du futur pipeline de déploiement basé sur les flux — elle ne fait pas partie de l’importation directe aujourd’hui.

Une solution peut dire sur quoi elle repose. Si son paquet nomme des solutions dont elle a besoin, l’importation vérifie d’abord l’environnement et refuse avec « Importez d’abord … » — avant d’écrire quoi que ce soit — quand l’une manque ou est trop ancienne.

Si une importation échoue en cours de route, rien n’est conservé. Quand c’est la première importation de cette version de la solution ici, tout ce qu’elle avait déjà créé — tables, formulaires, rôles, applications — est retiré, et l’importation est marquée Échouée avec la raison. Corrigez la cause et importez de nouveau. (La réimportation d’une version déjà installée n’est pas annulée, car cela retirerait aussi la copie qui fonctionne.)

Importer une version plus récente : une mise à niveau

Lorsque l’environnement possède déjà une version antérieure de la solution, importer une version plus récente la remplace. La version antérieure quitte la liste des solutions, et l’environnement se retrouve tel qu’une nouvelle installation de la nouvelle version le laisserait :

• Tout ce que la nouvelle version apporte encore reste, enregistrements compris, et appartient désormais à la nouvelle version.
• Ce que la nouvelle version n’apporte plus est supprimé, comme une désinstallation le supprimerait. Un rôle qu’elle a abandonné est retiré aux personnes qui le détenaient.

Si la version antérieure ne peut pas être retirée, l’importation réussit quand même, la version antérieure reste dans la liste et le message affiché après l’importation le signale. Importez à nouveau la nouvelle version pour réessayer. Ne désinstallez pas la version antérieure : des parties de la nouvelle lui appartiennent encore.

Quand une solution enrichit une table que vous avez déjà

Certaines solutions ajoutent des champs à une table avec laquelle l’environnement a été créé, par exemple un code et un statut sur Unités. L’importation ajoute ces champs et laisse tout le reste de la table en l’état : la table conserve ses champs, ses enregistrements et son organigramme existants. La table appartient toujours à l’environnement, et non à la solution.

Désinstaller cette solution ne retire que ce qu’elle a ajouté. La table reste, avec ses propres champs et enregistrements.

Une solution peut faire pointer une recherche existante vers une autre table. Par exemple, le Responsable d’une unité pourrait pointer vers un poste plutôt que vers une personne. Les valeurs qui pointaient vers l’ancienne table sont effacées, car elles n’ont aucun sens pour la nouvelle. La désinstallation rétablit la cible d’origine de la recherche et efface les valeurs qu’elle contenait.

Une solution ne peut pas changer le type de données d’un champ, par exemple transformer un champ texte en recherche. L’importation s’arrête avec un message nommant le champ, et rien n’est modifié. L’auteur de la solution doit plutôt ajouter un nouveau champ.

Quand une solution en nécessite une autre

Une solution peut reposer sur la solution d’un autre éditeur : par exemple une table Badge dont la colonne Visitor fait référence à la table qu’apporte la solution Visitors. Les deux peuvent être installées côte à côte dans un environnement, chacune sous son propre éditeur, mais celle sur laquelle l’autre repose doit être là en premier.

L’importation vérifie donc chaque recherche. Une colonne qui fait référence à une table que le package ne transporte pas et que l’environnement n’a pas arrête l’importation avant toute écriture, et le message nomme la colonne et la table. Importez la solution qui apporte la table, puis réimportez celle-ci.

Les exportations n’enregistrent pas encore les solutions sur lesquelles repose un package : c’est donc cette vérification, table par table, qui détecte une importation faite dans le mauvais ordre.

Données initiales : la configuration toujours, la démonstration seulement sur demande

Les données initiales sont des enregistrements qu’un package apporte avec lui, et les lignes de chaque table relèvent de l’un de deux types :

• Configuration : les lignes dont la solution a besoin pour fonctionner, comme des seuils d’approbation. Elles sont toujours importées, production comprise.
• Démonstration : les lignes qui mettent la solution en valeur, comme des clients fictifs. Elles ne sont importées que si vous cochez Inclure les données de démonstration, et jamais dans un environnement de production, où elles se mêleraient à vos propres enregistrements sans rien pour les distinguer et resteraient en place si la solution était désinstallée.

Le message affiché après l’importation indique ce qui a été importé, et combien de lignes de démonstration ont été laissées de côté. Voir Livrer des données initiales avec une solution.

Dépannage

• « Le package de solution n’est pas valide. » — le package ne respecte pas le format attendu. Exportez-le de nouveau depuis l’environnement source.
• « field '…' references '…', which is neither in the package nor in this environment. » — une colonne du package fait référence à une table, ou prend ses valeurs dans un groupe d’options, que le package ne transporte pas et que cet environnement n’a pas. Rien n’a été importé. Si une autre solution l’apporte, importez d’abord cette solution. S’il appartient à cette solution, ajoutez-le dans l’environnement d’où vous avez exporté et exportez de nouveau.
• « Les données de démonstration ne peuvent pas être importées dans …, qui est un environnement de production. » Importez la solution sans elles. Ses lignes de configuration sont tout de même importées.
• La solution est arrivée, mais ses enregistrements d’exemple manquent. Elle a été importée sans ses données de démonstration. Importez-la de nouveau, dans un environnement qui n’est pas de production, avec Inclure les données de démonstration coché.
• « L’environnement cible … est introuvable » / « n’est pas actif ». — sélectionnez un environnement existant et actif ; attendez qu’un environnement nouvellement créé ait fini d’être provisionné.

Scénarios associés

• Exporter une solution.
• Créer un environnement.