Konfigurationszuordnung während der Migration der Produktkonfiguration
Bei der Migration der Produktkonfiguration werden verschiedene Konfiguration zugeordnet.

Dieser Artikel beschreibt die Migration von Profilkonfigurationen. Wenn Sie Ihre Anwendungen auf die aktuellste Version migrieren möchten, verwenden Sie WebSphere Application Server Migration Toolkit. Weitere Informationen finden Sie unter Migration Toolkit on WASdev.
sptcfgEine Migration bedeutet, die Konfiguration eines früheren Release von WebSphere Application Server in ein neues Release zu kopieren.
Es sind zahlreiche Migrationsszenarien möglich. Die Migrationstools ordnen Objekte und Attribute, die in der Version, von der Sie die Migration durchführen, vorhanden sind, den entsprechenden Objekten und Attributen in der Umgebung mit Version 9.0 zu.
Die Migrationstools übertragen den Wert aus dem alten Release in die Umgebung mit Version 9.0.
Die Migrationstools konvertieren entsprechende Befehlszeilenparameter in JVM-Einstellungen (Java™ Virtual Machine) in der Serverprozessdefinition. Die meisten Einstellungen werden direkt zugeordnet. Einige Einstellungen werden nicht migriert, weil keine entsprechenden Rollen in der Konfiguration von WebSphere Application Server Version 9.0 vorhanden sind, die Einstellungen eine andere Bedeutung haben oder anderen Geltungsbereichen zugewiesen sind.
Informationen zum Ändern der Prozessdefinitionseinstellungen finden Sie im Artikel Einstellungen für Prozessdefinition im Information Center. Informationen zum Ändern der JVM-Einstellungen finden Sie unter Java virtual machine settings.
- In Version 7.0 oder höher hat ein generischer Server einen eigenen Typ mit dem Namen GENERIC_SERVER. Bei der Migration wird diese Konvertierung zwar durchgeführt, aber die externen Ressourcen auf die der generische Server verweist, können nicht exakt migriert werden. Nach der Migration der Einstellungen für den generischen Server müssen Sie zusätzliche Aktionen ausführen. Falls die alte Ressource, die der generische Server verwaltet hat, nicht in der alten Installation von WebSphere Application Server enthalten ist, führen Sie die folgenden Aktionen aus:
Falls die alte Ressource, die der generische Server verwaltet hat, nicht in der alten Installation von WebSphere Application Server enthalten ist, sind keine weiteren Aktionen erforderlich.
Sie können einen Knoten mit WebSphere Application Server Version 7.0 oder höher, der zu einer Zelle gehört, migrieren, ohne den Knoten aus der Zelle zu entfernen.
Migrieren Sie zuerst den Deployment Manager, bevor Sie in der Zelle Basisknoten migrieren.
Wichtig: Verwenden Sie denselben Zellennamen, wenn Sie WebSphere Application Server Network Deployment von Version 7.0 oder höher auf Version 9.0 migrieren. Sollten Sie einen anderen Zellennamen verwenden, können eingebundene Knoten nicht erfolgreich in die Zelle mit WebSphere Application Server Network Deployment Version 9.0 migriert werden.Wenn Sie einen Knoten mit dem Basisprodukt WebSphere Application Server, der in eine Zelle eingebunden ist, auf Version 9.0 migrieren, wird auch der Node Agent auf Version 9.0 migriert. Eine Zelle kann einige Knoten mit Version 9.0 und einige Knoten mit Version 7.0 oder höher enthalten.
- Beim Migrieren aller Richtliniendateien, die in Version 7.0 oder höher installiert sind, kopiert WebSphere Application Server Version 9.0 die Einstellungen wie folgt in die Richtliniendateien von Version 9.0:
Bei der Migration werden Dateien von Verzeichnissen der Vorversion in die Konfiguration von WebSphere Application Server Version 9.0 kopiert.
Beim Migrieren aller Eigenschaftendateien, die in Version 7.0 oder höher installiert sind, kopiert WebSphere Application Server Version 9.0 die Einstellungen in die Eigenschaftendateien von Version 9.0.
Von J2C-Ressourcen referenzierte RAR-Dateien werden migriert, wenn diese RAR-Dateien in der früheren Installation von WebSphere Application Server enthalten sind. In diesem Fall werden die RAR-Dateien in das entsprechende Verzeichnis der neuen Installation von WebSphere Application Server kopiert. RAR-Dateien für relationale Ressourcenadapter werden nicht migriert.
Migration von Clusterressourcen:WebSphere Application Server Version 6.0 hat das Konzept der Ressourcen auf Clusterebene eingeführt. Diese werden in Dateien des Typs resourcexxx.xml unterhalb der Clusterverzeichnisse. Beispiel:<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar"> ... </resources.j2c:J2CResourceAdapter>
Wenn Sie eine Ressource auf Clusterebene verwenden, muss diese Ressource sich in jedem Cluster-Member (Knoten) an derselben Position befinden. Im obigen Beispiel muss daher für jedes Cluster-Member die RAR-Datei im Verzeichnis ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar installiert sein. ${WAS_INSTALL_ROOT} wird in jedem Cluster-Member zur exakten Position aufgelöst.
Bei der Migration eines Deployment Manager migrieren die Tools die Clusterdateien im Deployment Manager, einschließlich der Dateien des Typs resourcexxx.xml.
Bei der Migration eines eingebundenen Knotens verarbeiten die Tools jeden J2C-Adapter.
Migration von RAR-Dateien von Version 7.0 auf Version 9.0:
Bei der Migration von Version 7.0 auf Version 9.0 werden Dateien wie die RAR-Dateien von WAS_INSTALL_ROOT nach WAS_INSTALL_ROOT und von USER_INSTALL_ROOT nach USER_INSTALL_ROOT kopiert.
Wenn beispielsweise eine RAR-Datei im Verzeichnis WAS_INSTALL_ROOT für Version 7.0 vorhanden ist, kopieren die Migrationstools die Datei nicht automatisch von WAS_INSTALL_ROOT in USER_INSTALL_ROOT. Dadurch wird die Integrität der J2C-Ressourcen auf Clusterebene aufrechterhalten.
Wenn Sie einen Pfad zu einer RAR-Datei (z. B. archivePath="C:/WAS/installedConnectors/x2.rar") in Version 7.0 fest codiert haben, können die Migrationstools von Version 9.0 das Attribut "archivePath" nicht entsprechend ändern, da andernfalls alle anderen Cluster-Member, die nicht migriert wurden, beschädigt würden.Die Beispiele aus früheren Versionen werden nicht migriert. Es gibt äquivalente Beispiele in WebSphere Application Server Version 9.0, die Sie installieren können.
Die Java-2-Sicherheit ist standardmäßig aktiviert, wenn Sie die Sicherheit in WebSphere Application Server Version 9.0 aktivieren. Für die Java-2-Sicherheit müssen Sie explizit Sicherheitsberechtigungen erteilen.
Wenn Sie eine Migration auf WebSphere Application Server Version 9.0 durchführen und dabei die Unterstützung der Scriptkompatibilität einschließen bzw. ausschließen möchten, führt das zu folgenden Ergebnissen.Weitere Informationen zur Migration Ihrer Sicherheitskonfigurationen auf Version 9.0 finden Sie im Artikel "Sicherheitsaspekte bei Migration, Koexistenz und Interoperation" in der Dokumentation.
In WebSphere Application Server for z/OS werden Ausgaben für stdin, stdout und stderr standardmäßig nach SYSOUT übertragen. Wenn sie in das Konfigurationsverzeichnis einer früheren Version umgeleitet werden, müssen Sie in der JCL von Version 9.0 möglicherweise eine Änderung vornehmen.
Die Migrationstools versuchen, vorhandene Auslagerungs- und Arbeitsverzeichnisse zu migrieren. Andernfalls werden die entsprechenden Standardeinstellungen von Version 9.0 verwendet.
Wenn Benutzer-IDs für WebSphere Application Server for z/OS Ausgangsverzeichnisse im Konfigurationsverzeichnis einer früheren Version haben, müssen Sie sie vor der Migration so aktualisieren, dass sie in einem anderen Verzeichnis gespeichert werden.
Fehler vermeiden: Die Verwendung gemeinsamer Verzeichnisse durch verschiedene Versionen in einem Koexistenzszenario kann zu Problemen führen.gotcha
Die Migrationstools migrieren alle Ports. Sie müssen alle Portkonflikte auflösen, bevor Sie Server gleichzeitig ausführen können.
Anmerkung: Wenn in der zu migrierenden Konfiguration bereits Ports definiert sind, beheben die Migrationstools die Portkonflikte in der Konfiguration von Version 9.0 und protokollieren die Änderungen für Ihre Überprüfung.Sie müssen für jeden Port Aliasnamenseinträge virtueller Hosts manuell hinzufügen. Weitere Informationen finden Sie im Artikel "Virtuelle Hosts konfigurieren" in der Dokumentation.
Die Spezifikationsstufe von Java Platform, Enterprise Edition (Java EE), die in WebSphere Application Server Version 7.0 implementiert ist, erfordert Verhaltensänderungen im Web-Container, damit der Inhaltstyp festgelegt werden kann. Wenn der Autor eines Standardservlets den Inhaltstyp nicht festlegt, kann der Web-Container keinen Standardinhaltstyp mehr festlegen. Außerdem gibt der Web-Container auf den Aufruf hin einen "Nullwert" zurück. Dies kann dazu führen, dass einige Browser die Tags des Web-Containers falsch anzeigen. Bei der Migration von Unternehmensanwendungen wird die IBM® Erweiterung "autoResponseEncoding" für Webmodule auf "true" gesetzt, um dieses Problem zu vermeiden.