WBM Migration mit Windchill+
Verwenden Sie das Modul Windchill Bulk Migrator (WBM) für die Migration. In diesem Thema werden die verschiedenen Aktivitäten mit Windchill Bulk Migrator (WBM) erläutert.
Voraussetzungen
Ein WBM Migrationsszenario hat einige Besonderheiten, aber es basiert konsistent auf den Konzepten, die in den anderen Abschnitten in diesem Hilfe-Center entwickelt wurden.
• Ein WBM Migrationsszenario ist ein erweitertes Windchill+ Szenario, das die Migrations- und QS-Umgebungen umfasst. Die Umgebungslandschaft ist wie folgt:
• Die WBM Migration nutzt ein automatisiertes Framework, das speziell für Windchill+ entwickelt wurde. In der Migrationsumgebung ist Backend-Zugriff weder erforderlich noch gewährt.
• Jede Migration ist eindeutig. In diesem Abschnitt werden die Dienste beschrieben, die auf Windchill+ verfügbar sind, um die meisten WBM Migrationsszenarien zu unterstützen. Je nach Komplexität müssen Sie als Kunde oder Partner jedoch das Migrationsprojekt entwerfen, planen und an spezifische Anforderungen anpassen. Beispielsweise müssen Sie die Anzahl der Proben, Voraussetzungen und weitere erforderliche Aufgaben, die vor Ort ausgeführt werden müssen, festlegen.
• Die Strukturierung der zu migrierenden Metadaten erfordert eine Datenbank. Es wird davon ausgegangen, dass eine lokale Staging-Datenbank verwendet wird, um mehrere Transformationen zu vermeiden. Sie müssen die Oracle-Datenbank verwenden. Die Verwendung der Oracle-Datenbank ist entsprechend den Windchill Versionsanforderungen erforderlich. Die Datenbankstruktur muss den Windchill WBM Staging-Datenbankanforderungen entsprechen.
• Es wird empfohlen, lokal ein separates Datenbankschema für die WBM Staging-Datenbank zu erstellen.
• Windchill ist mit einem Konvertierungsdienstprogramm vom Legacy-Datenmodell für das Änderungsmanagement zum neuen flexiblen Datenmodell übergegangen, da Windchill+ den Modus Gemischt nicht unterstützt. Daher muss vor der Durchführung einer Massenmigration mit Windchill Bulk Migrator das Quellsystem in den Modus Flexibel konvertiert werden. Weitere Informationen finden Sie unter Removal of Legacy Links from Windchill 13.0.2.0.
Migrationsumgebung
Eine Migrationsumgebung ist ein Ort, an dem ein präskriptiver Prozess des Zusammenführens von Code, Konfiguration und Daten stattfindet. Verwenden Sie Windchill Bulk Migrator (WBM) zusätzlich zum Einreichen eines Build-Pakets für die Migration, um die Staging-Daten zu senden. Diese Daten werden zur Auswertung in die Migrations-Staging-Datenbank geladen. Das Verschieben von Code, Konfiguration und Daten ist Teil des grundlegenden operationellen Windchill+ Frameworks. Sie generieren z.B. Daten aus System A und legen sie an einem Speicherort ab. Anschließend migriert Windchill+ automatisch alles in System B.
Senden Sie die Build-Pakete nach der Migration in die QS-Umgebung und dann in die Produktionsumgebung.
WBM Migrationsaktivitäten
Beachten Sie die folgenden Informationen in Bezug auf WBM Migrationsaktivitäten:
Vor der Go-Live-Phase
Das System verwendet die Integrationsumgebung, um alle Codeänderungen zu integrieren und eine Reifeebene des Builds zu erreichen, bevor die Migrations-Auslastungstests gestartet werden. Der Prozess zum Bereitstellen eines Builds ähnelt dem Prozess, der im Thema Paket einreichen und erhöhen beschrieben wird.
Führen Sie die folgenden Schritte aus:
1. Senden Sie eine Build- und Manifestdatei mit deploy_pipe : int. Weitere Informationen finden Sie unter Deploying Code and Configuration Package (auf Englisch).
2. Schließen Sie den Zyklus von Integrations- und Funktionsakzeptanztest (FAT) ab. Am Ende des Testzyklus ist die Aufgabe abgeschlossen, und der vorherige Status der Umgebung wird wiederhergestellt.
 | Wenn dieser Schritt nicht innerhalb von sieben Tagen abgeschlossen wird, wird der vorherige Status der Umgebung wiederhergestellt. |
Schritte in der Migrationsumgebung
Die Migrationsumgebung wird für Auslastungstests verwendet. Führen Sie die folgenden Schritte aus:
1. Laden Sie die Staging-Datenbankausgabe mit AzCopy in den Speicherbereich hoch.
Weitere Informationen finden Sie unter den folgenden Links:
2. Öffnen Sie eine Serviceanfrage, um den Import der Staging-Datenbankausgabe anzufordern. Weitere Informationen finden Sie unter Serviceanfrage öffnen.
3. Stellen Sie den Build bereit. Der Prozess zum Bereitstellen eines Builds ähnelt dem Prozess, der im Thema Paket einreichen und erhöhen beschrieben wird. Dieses Thema gilt für die Bereitstellung eines Builds in der Migrationsumgebung.
4. Senden Sie eine Build- und Manifestdatei mit deploy_pipe : mig. Weitere Informationen finden Sie unter Deploying Code and Configuration Package (auf Englisch).
| | Standardmäßig wird die während dieses Schritts erstellte Sicherung für die Migrationsumgebung 30 Tage beibehalten. |
5. Öffnen Sie eine Serviceanfrage, um das Laden auszuführen.
6. Rufen Sie im Falle einer Inhaltsmigration die Inhaltszuordnungsdatei aus dem Speicherkonto ab, und bereiten Sie ein Skript zum Kopieren von Inhalten vor. Öffnen Sie anschließend eine Serviceanfrage mit dem angehängten Skript, um die endgültige Inhaltsübertragung auszuführen. Weitere Informationen finden Sie unter Serviceanfrage öffnen.
7. Schließen Sie den Migrationstestzyklus ab. Am Ende des Testzyklus wird der leere Status der Umgebung durch eine der folgenden Aktionen wiederhergestellt, die über eine Serviceanfrage angefordert werden (in der bevorzugten Reihenfolge):
◦ Aus der Produktionsumgebung erneut hosten
◦ Wiederbereitstellung (wird nur für die erste Migration verwendet, nicht für nachfolgende Datenmigrationen)
Schritte in der QS-Umgebung
Die QS-Umgebung wird für Benutzerakzeptanztests verwendet. Führen Sie die folgenden Schritte aus:
1. Wiederholen Sie denselben Prozess mit dem neuesten Status der in die Staging-Datenbank importierten Daten.
◦ Senden Sie eine Build- und Manifestdatei mit deploy_pipe : pipeline.
| | Standardmäßig wird die während dieses Schritts durchgeführte Sicherung für die QS-Umgebung 30 Tage lang beibehalten. |
2. Öffnen Sie eine Serviceanfrage, um die Ausführung des Ladevorgangs in der QS-Umgebung anzufordern. Weitere Informationen finden Sie unter Serviceanfrage öffnen.
3. Rufen Sie im Falle einer Inhaltsmigration die Inhaltszuordnungsdatei aus dem Speicherkonto ab, und bereiten Sie ein Skript zum Kopieren von Inhalten vor. Öffnen Sie anschließend eine Serviceanfrage mit dem angehängten Skript, um die endgültige Inhaltsübertragung auszuführen. Weitere Informationen zum Erstellen einer Inhaltszuordnungsdatei finden Sie unter WBM Phasen.
4. Schließen Sie den UAT-Testzyklus ab. Sie haben bis zu 30 Tage Zeit, um eine der folgenden Entscheidungen zu treffen:
◦ Wenn der Testzyklus erfolgreich ist, wird die Aufgabe genehmigt, und nur der Build wird auf die Produktionsumgebung erhöht.
◦ Wenn der Testzyklus nicht erfolgreich ist:
▪ Die Aufgabe kann zurückgewiesen werden, und die Umgebung wird auf den vorherigen Status zurückgesetzt.
▪ Die Aufgabe kann genehmigt werden, und der Build wird auf die Produktionsumgebung erhöht. Ein nachfolgender Build kann eingereicht werden, um Fehler zu beheben.
◦ Wenn der Testzyklus nicht innerhalb von 30 Tagen abgeschlossen wird, wird die Umgebung automatisch auf den vorherigen Status zurückgesetzt. Sie müssen die Aufgabe genehmigen, um die Umgebung beizubehalten.
| | Wenn ein weiteres vollständiges Laden der QS erforderlich ist, wird die Umgebung durch eine der folgenden Aktionen, die mithilfe einer Serviceanfrage angefordert werden (in bevorzugter Reihenfolge), auf einen leeren Status zurückgesetzt: • Aus der Produktionsumgebung erneut hosten. • Wiederbereitstellung (nur bei erstmaliger Migration, nicht für nachfolgende Datenmigration). |
Wenn das Deltaladen für den Go-Live geplant ist, muss das Laden unabhängig von der Produktion erfolgen. Öffnen Sie eine Serviceanfrage, um eine Ladeausführung in der Produktionsumgebung anzufordern oder wiederholen zu lassen. Weitere Informationen finden Sie unter Serviceanfrage öffnen.
Go-Live-Phase
• Zu diesem Zeitpunkt befindet sich der zuvor genehmigte Build bereits in den QS- und Produktionsumgebungen.
• Darüber hinaus kann das Laden vorheriger Daten in der Produktionsumgebung verfügbar sein.
• Wenn während der Go-Live-Umstellung keine Build-Einreichungen erforderlich sind (oder wenn Sie das erforderliche Go-Live-Build im Voraus eingereicht haben), führen Sie die folgenden Schritte aus:
1. Laden Sie den neuesten Staging-Datenbankausgabe in das Speicherkonto hoch.
2. Öffnen Sie eine Serviceanfrage, um einen Import der neuesten Staging-Datenbank anzufordern.
3. Öffnen Sie eine Serviceanfrage, um das Laden in die Produktionsumgebung auszuführen.
4. Öffnen Sie im Falle einer Inhaltsmigration nach der Skripterstellung eine Serviceanfrage für die endgültige Inhaltsübertragung.
• Wenn eine Build-Einreichung erforderlich ist, befolgen Sie den im Abschnitt "Schritte in der QS-Umgebung" beschriebenen Prozess für die Build-Einreichung und -Erhöhung. Führen Sie anschließend die Produktionsaktivitäten und Serviceanfragen wie im Abschnitt "Schritte in der QS-Umgebung" beschrieben aus.
• Sobald der Go-Live von Ihnen bestätigt wurde, ist es erforderlich, die Produktionsumgebung erneut in den QS- und Integrationsumgebungen zu hosten (und in der Migrationsumgebung, wenn eine spätere Migration geplant ist). Eine Serviceanfrage muss für das erneute Hosten von Aktivitäten geöffnet werden.
Phase ausführen
• Nach einem erfolgreichen Go-Live empfiehlt PTC dringend, die Änderungen in Ihre Entwicklungsumgebungen zu propagieren, da alle Umgebungen aus der Produktionsumgebung erneut gehostet werden.
◦ Das Datenmodell ist das Minimum, das erforderlich ist, und muss als Ausgangspunkt für Ihre Entwicklungsumgebung verwendet werden.
◦ Sie können den neuesten Build wiederverwenden.
• Bei nachfolgenden Migrationen muss der im Abschnitt "Vor dem Go-Live" beschriebene Prozess wiederholt werden.
| | Sie sollten die Aktualisierungsaktivitäten für die Umgebung während der Projektkonstruktion und -planung sorgfältig überdenken, um den Verlust vorhandener Daten zu vermeiden. |
Abschließende Überlegungen
• Für eine Migration in großem Umfang und zur Verringerung der Auswirkungen während der Go-Live-Umstellung wird dringend empfohlen, die Migrationsaktivitäten so zu konstruieren, dass das Deltaladen möglich ist.
• Alle Migrationsprojekte sind eindeutig. Sie müssen Aktivitäten wie gründliche Planung, Umfangsverwaltung, Risiko und Abhängigkeiten verwalten, um sicherzustellen, dass Migrationsprojekte erfolgreich sind. Diese Aktivitäten gewährleisten ein korrektes Migrationsdesign und eine reibungslose Go-Live-Umstellung.
• Die Migrationstests werden häufig unterschätzt. Für einfache Migrationsprojekte empfiehlt PTC, mit drei Testmigrationszyklen zu beginnen. Mit zunehmender Komplexität können Sie die Implementierung weiterer Zyklen planen.