| Remarque |
|---|
Assurez-vous d'avoir lu attentivement la documentation depuis le début afin de valider tous les prérequis et de disposer de toutes les informations essentielles. |
Etapes de migration
...
https://divalto.atlassian.net/wiki/spaces/UDW62/folder/11723538537
Etape 1 : Lancer la migration
Depuis VSCode, executer la commande (ctrl+shift+P) Divalto : Migrate current project
Etape 2 : Confirmation
Une confirmation sera demandée par l’extension. Répondre oui pour continuer vers la migration du projet
Etape 3 : Vérification de l'éligibilité du projet
Une console s’ouvre dans la zone que vous avez configuré. Elle vous indique que la migration peut commencer (si votre projet n’est pas éligible à la migration des profils, nous ne déclenchons pas le processus).
C’est à cet endroit que vous pourrez avoir le détail de progression de migration.
Etape 4 : Récupération des données du projet
L’extension va récupérer les données permettant de savoir si le projet est déjà migré et ce qu’il faut migrer. Un message s’affichera dans la console lorsque les données sont récupérées.
Nous considérons que votre projet est déjà migré si la table sw_data_feature n’est pas vide.
| Remarque |
|---|
Etape 5 : Exporter la configuration spécifique Un message conseillera ensuite d’exporter la configuration spécifique du projet avant de démarrer la migration pour s’assurer d’en garder une copie et de pouvoir l’appliquer au besoin ou la consulter à tout moment du processus. 
|
| Remarque |
|---|
Etape 6 : Lancement du Backend [GLOBAL] Update Project Un message vous demandera si vous avez bien lancé le Backend [GLOBAL] Update Project. Si ce n’est pas fait, laissez le message suivant en attente et lancez le Backend indiqué plus bas.   |
Etape 7 : Définir les éléments à migrer
Cette étape peut ne pas se présenter à vous. Elle analyse les données de l'étape 4 et si besoin, vous demandera de valider ou indiquer vos choix concernant des noms de feature ou capacité, ainsi que leur valeur par défaut pour pouvoir remplir la table sw_data_confpermission_overloadprofilemapping
Quelques points sont à détailler dans cette étape :Dépendant du volume de spécifique à migrer, nous avons décidé d’appliquer une limite de 10 éléments pour ne pas imposer de devoir répondre à trop de question.
Cependant, nous alertons et permettons de l'éviter.
Suite au point précédent, s’il y a des éléments en attente de traitement, une succession de questions vous seront posées.
Comme inscrit dans le point suivant, ce n’est pas grave si vous vous trompez lors de la saisie de la réponse car le récapitulatif sera consultable avant migration dans la table sw_data_confpermission_overloadprofilemapping.
Voici un exemple des deux types de question posée :Questions posées lorsque nous trouvons une feature ou capacité des éléments à migrer
Tout d'abord, nous demandons de confirmer le nom à utiliser pour une feature ou capacité
Puis nous demandons de confirmer la valeur de la feature ou capacité
Dans la console, le récapitulatif sera affiché
Question posée lorsque nous trouvons une feature ou capacité à migrer avec plusieurs valeurs possibles
Tout d'abord, nous demandons de confirmer le nom à utiliser pour une feature ou capacité
Puis nous demandons de confirmer une des valeurs de la feature ou capacité.
Comme le montre la capture d'écran, il est aussi possible de choisir une valeur différente.
Si les valeurs ne sont pas satisfaisantes, vous pourrez la modifier directement dans la table sw_data_confpermission_overloadprofilemapping avant d’appliquer la migration.
de quel manière vous souhaiter migrer chaque élément : 
Puis nous vous proposons ensuite de pouvoir choisir un nouveau nom pour chacun de ses éléments qui n’a pas été indiqué comme étant à rendre obsolète.
Puis dans le cas ou vous auriez choisis de migrer l'élément en tant que Variable ou Feature, nous vous proposerons de choisir sa valeur :
Dans la cas d’une variable qui peut contenir n’importe quel type de valeur, deux écran se présenteront à vous :
1er cas une seul valeur différente trouvé en base pour l’ancien élément :
2ème cas plusieurs valeur différentes trouvé pour l’ancien élément :
dû à une limitation technique de vscode, et afin de permettre de saisir une toute autre valeur que la liste de valeur disponible nous avons utiliser un contournement en ajoutant à la liste de sélection une valeur “(new value)” qui aura pour effet de clore cette 1er fenêtre à sélection multiple et ouvrira à la place un champ de saisie libre :
Dans le cas d’une feature, les seule valeurs autorisé seront 0 ou 1 car il permettront de déterminer lors de la migration si la fonctionnalité est active ou non :
Ensuite si vous choisissez de migrer un élément en tant que Feature ou Capacité il vous sera possible de la rattaché à une Feature Parente à l’aide d’une liste de toute les autre feature existante :
Dans la console, le récapitulatif sera affiché comme ceci
...
Dès que tous les éléments sont traités, nous les insérons en base dans la table sw_data_confpermission_overloadprofilemapping. Patienter jusqu’au prochain message indiquant que l’opération s’est terminée.
Que vous fassiez une erreur, que vous indiquiez vos choix ou non, tous les éléments seront injectés dans la table sw_data_confpermission_overloadprofilemapping.
Cette table permettra de vérifier ce qui sera migré et le modifier.
Pour mieux saisir le fonctionnement de la table de mapping, nous la détaillons sur cette page :
Table de mappingEtape 7 8 : Migrer votre projet
Lorsque vous avez bien exporté votre configuration spécifique, que vous avez fait les choix liés aux éléments spécifiques de votre projet et que vous avez vérifié la table sw_data_confpermission_overloadprofilemapping, vous êtes prêt à lancer la migration des données, ainsi que la configuration spécifique de votre projet.
Concernant les données :Un message s’assurera que la table sw_data_confpermission_overloadprofilemapping a bien été consultée et validée.
Vous avez le choix de ne pas le faire de suite.
Puis, un message vous alertera que la migration de la configuration est sur le point de s’effectuer.
Vous avez le choix de seulement générer un rapport à titre de consultation, soit de migrer et générer le rapport.
Etape 8 9 : Migration de la configuration en cours
Migration en cours. Consultez la console pour avoir l’avancement.
Etape 9 10 :
Lecture du rapport et vérifications finales.
Pour comprendre comment lire le rapport, référez-vous à cette page :
Rapport de migration
Exemple de rapport :
...
Etapes de migration lorsque
...
la base de donnée de votre projet est déjà
...
migrée
Etape 1 :
Depuis VSCode, executer la commande (ctrl+shift+P) Divalto : Migrate current project Etape 2 :
Une confirmation sera demandée par l’extension. Réponder Répondez oui pour continuer vers la migration du projet Etape 3 :
showAllreadyMigratedMessageAsync
Votre projet sera considéré comme déjà migré.
Répondez I confirm that i want to restart the migration pour confirmer
Etape 4 :
askMigrateDataAgainAsync
Dans ce cas, un message vous demandera si vous désirez quand même migrer votre configuration.
R2pondez Migrate again pour démarrer la migration de configuration
Etape 5 :askMigrateConfigurationAgainAsync
| Remarque |
|---|
Etape |
...
5 : |
...
Exporter la configuration spécifique Un message conseillera ensuite d’exporter la configuration spécifique du projet avant de démarrer |
...
la migration pour s’assurer d’en garder une copie et de pouvoir l’appliquer au besoin ou la consulter à tout moment du processus. |
...
|
...
1 ensuite. |
...
|
Etape 6 :
Migration en cours
Puis, un message vous alertera que la migration de la configuration est sur le point de s’effectuer.
Vous avez le choix de seulement générer un rapport à titre de consultation, soit de migrer et générer le rapport.
Configuration : Informations et particularités
...