Migration de WBM avec Windchill+
Utilisez le module Windchill Bulk Migrator (WBM) pour la migration. Cette rubrique décrit les différentes activités de Windchill Bulk Migrator (WBM).
Configuration requise
Un scénario de migration WBM présente certaines spécificités, mais il est construit de manière cohérente à partir des concepts développés dans les autres sections de ce Centre d'aide.
• Un scénario de migration WBM est un scénario Windchill+ avancé impliquant les environnements de migration et d'assurance qualité. Le paysage de l'environnement est le suivant :
• La migration WBM s'appuie sur une infrastructure automatisée spécifiquement conçue pour Windchill+. Aucun accès au système principal n'est requis et accordé sur l'environnement de migration.
• Chaque migration est unique. Cette section décrit les services disponibles sur Windchill+ pour prendre en charge la majorité des scénarios de migration WBM. Toutefois, en tant que client ou partenaire, vous devez concevoir et planifier le projet de migration et l'ajuster aux exigences spécifiques, en fonction de sa complexité. Par exemple, le nombre de répétitions, les conditions requises et les tâches supplémentaires obligatoires à effectuer sur site, etc.
• La structuration des métadonnées devant être migrées nécessite une base de données. Pour éviter plusieurs transformations, il est supposé qu'une base de données intermédiaire sur site est utilisée. Vous devez utiliser la base de données Oracle. L'utilisation de la base de données Oracle est nécessaire en fonction des exigences de version de Windchill. La structure de base de données doit respecter les exigences de base de données intermédiaire WBM de Windchill.
• Il est recommandé de créer un schéma de base de données distinct sur site pour la base de données intermédiaire WBM.
• Windchill est passé du modèle de données hérité de gestion des modifications au nouveau modèle de données flexible, à l'aide d'un utilitaire de conversion, car Windchill+ ne prend pas en charge le mode Mixte. Par conséquent, avant d'exécuter un processus de migration en bloc Windchill avec Windchill Bulk Migrator, le système source doit être converti en mode Flexible. Pour plus d'informations, consultez la rubrique Removal of Legacy Links from Windchill 13.0.2.0.
Environnement de migration
Un environnement de migration est un emplacement où se produit un processus prescriptif de regroupement du code, de la configuration et des données. Outre la soumission d'un lot de build pour migration, utilisez Windchill Bulk Migrator (WBM) pour soumettre les données intermédiaires. Ces données sont chargées dans la base de données intermédiaire de migration pour évaluation. Le déplacement du code, de la configuration et des données fait partie intégrante de l'infrastructure opérationnelle de base Windchill+. Par exemple, si vous générez des données à partir du système A et que vous les placez dans un emplacement, Windchill+ migre automatiquement toutes les données dans le système B.
Après la migration, soumettez vos lots de build à l'environnement d'assurance qualité, puis à l'environnement de production.
Activités de migration WBM
Tenez compte des informations suivantes relatives aux activités de migration WBM :
Avant l'étape de mise en service
Le système utilise l'environnement d'intégration pour intégrer toutes les modifications de code et atteindre un niveau de maturité avec la build avant de commencer le test de charge de migration. Le processus de déploiement d'une build est similaire à celui décrit dans la rubrique Soumission et promotion de votre lot.
Effectuez les étapes suivantes :
1. Soumettez une build et un fichier de manifeste avec deploy_pipe : int. Pour plus d'informations, consultez la rubrique Deploying Code and Configuration Package (en anglais).
2. Terminez le cycle de test d'intégration et d'acceptation fonctionnelle (FAT). A la fin du cycle de test, la tâche est terminée et l'environnement revient à son état précédent.
 | Si cette étape n'est pas effectuée dans les sept jours, l'environnement revient à son état précédent. |
Etapes de l'environnement de migration
L'environnement de migration est utilisé pour le test de charge. Effectuez les étapes suivantes :
1. Chargez le vidage de base de données intermédiaire dans la zone de stockage à l'aide d'AzCopy.
Pour plus d'informations, consultez les liens suivants :
2. Ouvrez une demande de service pour demander l'importation du vidage de base de données intermédiaire. Pour plus d'informations, consultez la rubrique Ouverture d'une demande d'intervention.
3. Déployez la build. Le processus de déploiement d'une build est similaire à celui décrit dans la rubrique Soumission et promotion de votre lot. Cette rubrique s'applique au déploiement d'une build dans l'environnement de migration.
4. Soumettez une build et un fichier de manifeste avec deploy_pipe : mig. Pour plus d'informations, consultez la rubrique Deploying Code and Configuration Package (en anglais).
| | Par défaut, pour l'environnement de migration, la sauvegarde créée au cours de cette étape est conservée pendant 30 jours. |
5. Ouvrez une demande d'intervention pour exécuter le chargement.
6. En cas de migration du contenu, récupérez le fichier de mappage du contenu à partir du compte de stockage et préparez un script de copie de contenu. Ensuite, ouvrez une demande d'intervention avec le script joint pour exécuter le transfert de contenu final. Pour plus d'informations, consultez la rubrique Ouverture d'une demande d'intervention.
7. Terminez le cycle de test de migration. A la fin du cycle de test, l'environnement est rétabli à l'état vide, par le biais de l'une des actions suivantes demandées via une demande d'intervention (dans l'ordre recommandé) :
◦ Réhébergement à partir de l'environnement de production
◦ Réapprovisionnement (utilisé uniquement pour la migration initiale, non utilisé pour les migrations ultérieures de données)
Etapes de l'environnement d'assurance qualité
L'environnement d'assurance qualité est utilisé pour les UAT. Effectuez les étapes suivantes :
1. Répétez le même processus avec le dernier état des données importées dans la base de données intermédiaire.
◦ Soumettez une build et un fichier de manifeste avec deploy_pipe : pipeline.
| | Par défaut, pour l'environnement d'assurance qualité, la sauvegarde effectuée au cours de cette étape est conservée pendant 30 jours. |
2. Ouvrez une demande d'intervention pour demander l'exécution du chargement sur l'environnement d'assurance qualité. Pour plus d'informations, consultez la rubrique Ouverture d'une demande d'intervention.
3. En cas de migration du contenu, récupérez le fichier de mappage du contenu à partir du compte de stockage et préparez un script de copie de contenu. Ensuite, ouvrez une demande d'intervention avec le script joint pour exécuter le transfert de contenu final. Pour plus d'informations sur la création d'un fichier de mappage de contenu, consultez la rubrique Etapes WBM.
4. Terminez le cycle de test UAT. Vous disposez de 30 jours maximum pour prendre l'une des décisions suivantes :
◦ Si le cycle de test réussit : la tâche est approuvée et seule la build est promue vers l'environnement de production.
◦ Si le cycle de test ne réussit pas :
▪ La tâche peut être rejetée, et l'environnement est restauré à l'état précédent.
▪ La tâche peut être approuvée et la build est promue vers l'environnement de production. Une build ultérieure peut être soumise pour corriger les bogues.
◦ Si le cycle de test n'est pas terminé dans les 30 jours, l'environnement est automatiquement restauré à son état précédent. Pour conserver l'environnement, vous devez approuver la tâche.
| | Si un autre chargement complet d'assurance qualité est requis, l'environnement est restauré à l'état vide, via l'une des actions suivantes demandées à l'aide d'une demande d'intervention (dans l'ordre préférentiel) : • Réhébergement à partir de l'environnement de production. • Réapprovisionnement (uniquement pour la migration initiale, ne pas utiliser pour la migration ultérieure des données). |
En option, si le chargement delta est prévu pour la mise en service, le chargement doit être effectué en production indépendamment. Ouvrez une demande d'intervention pour demander ou répéter une exécution de chargement sur l'environnement de production. Pour plus d'informations, consultez la rubrique Ouverture d'une demande d'intervention.
Etape de mise en service
• Au cours de cette étape, la build précédemment approuvée se trouve déjà dans les environnements d'assurance qualité et de production.
• En outre, le chargement précédent des données peut être disponible dans l'environnement de production.
• Si aucune soumission de build n'est requise lors de la conversion pour la mise en service (ou si vous avez soumis la build requise pour la mise en service au préalable), procédez comme suit :
1. Chargez le dernier vidage de base de données intermédiaire sur le compte de stockage.
2. Ouvrez une demande d'intervention pour demander l'importation de la dernière base de données intermédiaire.
3. Ouvrez une demande d'intervention pour exécuter le chargement sur l'environnement de production.
4. En cas de migration de contenu, après la création du script, ouvrez une demande d'intervention pour le transfert de contenu final.
• Si une soumission de build est requise, suivez le processus décrit dans la section Etapes de l'environnement d'assurance qualité pour la soumission et la promotion de build. Ensuite, exécutez les activités de production et les demandes d'intervention, comme décrit dans la section Etapes de l'environnement d'assurance qualité.
• Une fois que vous avez confirmé la mise en service, il est obligatoire de réhéberger l'environnement de production vers l'assurance qualité et l'intégration (et la migration si une migration ultérieure est planifiée). Une demande d'intervention doit être ouverte pour les activités de réhébergement.
Etape d'exécution
• Une fois la mise en service réussie, tous les environnements étant réhébergés à partir de l'environnement de production, PTC recommande vivement de propager les modifications dans vos environnements de développement.
◦ Le modèle de données est le minimum requis et doit être utilisé comme point de départ dans votre environnement de développement.
◦ Vous pouvez réutiliser la dernière build.
• S'il existe des migrations ultérieures, le processus décrit dans la section Avant la mise en service doit être répété.
| | Pour éviter toute perte de données existantes, vous devez examiner attentivement les activités d'actualisation de l'environnement au cours des étapes de conception et de planification du projet. |
Considérations finales
• Pour une migration à grande échelle et pour atténuer l'impact lors de la conversion pour la mise en service, il est fortement recommandé de concevoir vos activités de migration afin de permettre le chargement du delta.
• Tous les projets de migration sont uniques. Pour garantir le succès des projets de migration, vous devez effectuer des activités telles qu'une planification forte, l'évaluation et la gestion des risques et des dépendances. Ces activités garantissent une conception de migration appropriée et une conversion pour une mise en service fluide.
• Les tests de migration sont souvent sous-estimés. Pour les projets de migration simples, PTC recommande de commencer par trois cycles de tests de migration. A mesure que la complexité augmente, vous pouvez planifier l'implémentation d'un plus grand nombre de cycles.