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.
sptcfgBei der Migration wird immer ein einzelnes Profil auf ein anderes einzelnes Profil auf demselben IBM i-Server kopiert. 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.
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.
Wenn für den Parameter -setPorts während des Aufrufs von WASPostUpgrade der Wert generateNew oder ein Portwert festgelegt wird, wird der Portwert aber jedem Anwendungsserver zugeordnet, der auf Version 9.0 migriert wird.
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.
Es gibt verschiedene Methoden, um unterschiedliche Ebenen der Java-2-Sicherheit in Version 9.0 zu definieren. Eine Methode besteht darin, die Datei was.policy als Teil der Anwendung zu erstellen, um alle Sicherheitsberechtigungen zu aktivieren. Die Migrationstools rufen den Befehl wsadmin auf, um bei der Migration von Unternehmensanwendungen eine vorhandene Datei was.policy zum Verzeichnis properties von Version 9.0 hinzuzufügen.
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 der Regel befinden sich diese Verzeichnisse im Verzeichnis logs unterhalb des Profilverzeichnisses von WebSphere Application Server. Standardmäßig werden Dateien aus stdin, stdout und stderr für WebSphere Application Server Version 9.0 im Verzeichnis logs des Profilverzeichnisses von WebSphere Application Server gespeichert. Das Protokollverzeichnis (logs) für das Standardprofil ist beispielsweise /QIBM/UserData/WebSphere/AppServer/V80/Base/profiles/default/logs.
Die Migrationstools versuchen, vorhandene Auslagerungs- und Arbeitsverzeichnisse zu migrieren. Andernfalls werden die entsprechenden Standardeinstellungen von Version 9.0 verwendet.
Fehler vermeiden: Die Verwendung gemeinsamer Verzeichnisse durch verschiedene Versionen in einem Koexistenzszenario kann zu Problemen führen.gotcha
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.