Upgradeprozess starten

Nachdem das System in den internen Wartestatus versetzt und gesichert wurde, können Sie mit der Upgrade-Prozedur beginnen.

Anmerkung:
Eine Deinstallation der Vorgängerversion von InterChange Server vor der Installation von Version 4.3 ist nicht erforderlich. Wenn Sie sie trotzdem ausführen wollen, ist nun der geeignete Zeitpunkt gekommen. Details finden Sie unter InterChange Server deinstallieren. Wenn Sie jetzt keine Deinstallation ausführen wollen, ist es ratsam, die alte Version zu entfernen, nachdem Sie den Upgrade fertig gestellt haben, da die zugeordneten Dateien sehr umfangreich sind. Für die Installation von Version 4.3 sollten Sie selbst dann ein anderes Verzeichnis auswählen, wenn Sie zu diesem Zeitpunkt eine Deinstallation vornehmen.
Der Upgrade des Systems umfasst die folgenden Tasks:

Datenbank importieren

Falls Sie einen Upgrade der Datenbank vorgenommen hatten, lassen Sie vom DBA die gesicherten Datenbankinformationen und gespeicherten Prozeduren importieren. Entsprechende Anweisungen enthält die Dokumentation des Datenbankservers.

Neue Version von InterChange Server installieren

Nachdem Sie die Vorgängerinstallation von Version 4.3 gesichert haben, können Sie nun die neue Version von InterChange Server installieren. Anweisungen dazu, wie Sie die neue Version von InterChange Server installieren, finden Sie in InterChange Server, XML-Datenhandler, E-Mail-Adapter und weitere unterstützende Produkte installieren.

Anmerkungen:

  1. Während eines Upgrades müssen Sie die neue Version in einer anderen Position als die vorhandene Installation installieren.

  2. Wenn Sie vom Installationsprogramm aufgefordert werden, einen Namen für die ICS-Instanz zu vergeben, müssen Sie darauf achten, dass dieser Name der ICS-Instanz mit dem Namen identisch ist, den Sie in der Vorgängerversion verwendet haben. Dies ist erforderlich, damit die Portierbarkeit von fehlgeschlagenen Ereignissen gewährleistet werden kann. Bei einer Migration mit Datenbank an gleicher Stelle ist dieser Schritt nicht erforderlich.

  3. Um die ursprünglichen Konfigurationsdaten von InterChange Server zu erhalten, können Sie eine der folgenden Aktionen ausführen, nachdem das Installationsprogramm den Assistenten "InterChange Server - Konfiguration" aufgerufen hat:

Object-Request-Broker konfigurieren

Bei einem Upgrade ausgehend von der InterChange Server-Version 4.2.2 ist die Konfiguration des Object-Request-Brokers nicht erforderlich. Fahren Sie mit den Anweisungen unter Upgrade der Serverscripts vornehmen fort.

Wie schon im Release 4.2.2 von InterChange Server wird der VisiBroker-ORB durch den IBM Java ORB ersetzt. Unter Upgrade der Hardware und der unterstützenden Software vornehmen wurde bereits beschrieben, dass das ICS-Installationsprogramm den IBM Java ORB und den IBM Transient Naming Server im Rahmen des ICS-Installationsprozesses automatisch installiert. Sie müssen jedoch sicherstellen, dass der IBM Java ORB korrekt konfiguriert ist. Hierzu führen Sie die folgenden Tasks aus:

Upgrade der ORB-Eigenschaften vornehmen

Der VisiBroker-ORB enthielt verschiedene ORB-bezogene Eigenschaften für die Optimierung des ORB. Falls Sie diese Eigenschaften in angepassten Scripts oder einer Software verwendet haben, müssen Sie sicherstellen, dass diese Eigenschaften für den IBM Java ORB entsprechend festgelegt werden. Tabelle 32 enthält einige der Eigenschaften für den VisiBroker-ORB und ihre Namensentsprechungen im IBM Java ORB.

Sind angepasste Scripts aus Installationen mit einer Vorgängerversion von 4.2.2 vorhanden, die auf Eigenschaften des VisiBroker-ORB verweisen, ersetzen Sie sie durch ihre IBM ORB-Entsprechungen, die in Tabelle 32 aufgeführt sind.

Anmerkung:
In einige der Eigenschaftsnamen in Tabelle 32 wurden Zeilenumbrüche eingefügt, damit die Namen in die Tabellenzellen passen. Die tatsächlichen Eigenschaftsnamen enthalten weder Leerzeichen noch Zeilenumbrüche.

Tabelle 32. IBM ORB-Eigenschaften und ihre VisiBroker-Entsprechungen
IBM ORB-Eigenschaften VisiBroker-Entsprechungen Beschreibung
org.omg.CORBA.ORBInitialHost vbroker.agent.addr Gibt die IP-Adresse oder den Hostnamen der Maschine an, auf der der IBM Transient Naming Server (tnameserv) ausgeführt wird. Der Standardwert für diese Eigenschaft lautet localhost.
org.omg.CORBA.ORBInitialPort vbroker.agent.port Gibt den Port an, an dem der IBM Transient Naming Server empfangsbereit ist.
com.ibm.CORBA.ListenerPort vbroker.se.iiop_tp.scm.iiop_tp. listener.port Dies ist der Port, an dem der ORB-Server für eingehende Anforderungen empfangsbereit ist. Wenn diese Eigenschaft definiert ist, startet die Empfangsbereitschaft des ORB während ORB.init(). In der Standardeinstellung wird dieser Port dynamisch zugeordnet. Bei Version 4.3 wird der VisiBroker-Eigenschaftsname OAport auch weiterhin unterstützt.
com.ibm.CORBA.LocalHost vbroker.se.iiop_tp.host Diese Eigenschaft stellt den Hostnamen (oder die IP-Adresse) der Maschine dar, auf der der ORB ausgeführt wird. Der lokale Hostname wird vom serverseitigen ORB verwendet, um den Hostnamen des Servers in die IOR-Datei (Interoperability Object Reference) eines fernen Objekts zu stellen. Falls diese Eigenschaft nicht definiert ist, wird der lokale Host durch den Aufruf von InetAddress.getLocalHost(). getHostAddress(); abgerufen. Bei Version 4.3 wird der VisiBroker-Eigenschaftsname OAipAddr auch weiterhin unterstützt.
com.ibm.CORBA.ThreadPool. MaximumSize vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMax Gibt die maximale Anzahl von Threads an, die der Manager für die Serververbindungen erstellen kann. Der Standardwert 0 gibt an, dass keine Einschränkung gilt. Bei Version 4.3 wird der VisiBroker-Eigenschaftsname OAthreadMax auch weiterhin unterstützt.
com.ibm.CORBA.ThreadPool. InactivityTimeout vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMaxIdle Gibt in Sekunden den Zeitraum an, bevor ein inaktiver Thread zerstört wird. Bei Version 4.3 wird der VisiBroker-Eigenschaftsname OAthreadMaxIdle auch weiterhin unterstützt.
com.ibm.CORBA.BufferSize vbroker.orb.streamChunkSize Dies ist die Anzahl der Byte (als GIOP-Nachricht), die beim ersten Versuch aus einem Socket gelesen werden. Eine größere Puffergröße erhöht die Wahrscheinlichkeit, dass die gesamte Nachricht bei einem einzigen Versuch gelesen werden kann, wodurch die Leistung verbessert werden kann. Der Standardwert ist 2048.

Registrierte ICS-ORB-Komponenten angeben

In früheren InterChange Server-Versionen als 4.2.2 stellte der VisiBroker-ORB das Tool osfind bereit, um alle für InterChange Server registrierten Objekte anzugeben. Der IBM Java ORB stellt zu diesem Zweck das Tool CosNameServer_Dump zur Verfügung. Dieses Tool befindet sich im Verzeichnis PRODUKTVERZ/bin. Weitere Informationen enthält das Handbuch System Administration Guide.

Upgrade von Komponenten für hohe Verfügbarkeit vornehmen

Wie schon im Release 4.2.2 von InterChange Server wird der VisiBroker-ORB durch den IBM Java ORB ersetzt. Im Zuge dieser Änderung ersetzt der Transient Naming Server den VisiBroker Smart Agent, der zuvor für die hohe Verfügbarkeit verwendet wurde. Weitere Informationen zur Konfiguration des IBM ORB für eine Umgebung mit hoher Verfügbarkeit finden Sie unter Object-Request-Broker (ORB) installieren und konfigurieren.

Upgrade der Serverscripts vornehmen

Falls Sie im bereits vorhandenen InterChange Server-System angepasste Dateien erstellt hatten, müssen Sie prüfen, ob die folgenden Dateien einen Upgrade erfordern:

Upgrade der Serverstartscripts vornehmen

Wie im InterChange Server-Release 4.2.2 wurden alle Startscripts geändert, damit der Umstieg vom VisiBroker-ORB auf den IBM Java ORB und die Unterstützung der IBM JRE ermöglicht wird.

Falls Sie Serverstartscripts angepasst haben und den Upgrade auf 4.3 ausgehend von einem anderen Release als 4.2.2 ausführen, müssen Sie ähnliche Änderungen an den neuen Scripts vornehmen. Möglicherweise müssen Sie diese Startscripts folgendermaßen anpassen:

Anmerkung:
Auf die integrierte Testumgebung können Sie nun über einen einfachen Startbefehl zugreifen. Versetzen Sie ICS in den Testmodus, indem Sie die Option -test zur Startzeile im Serverstartscript hinzufügen. Weitere Details können Sie im Handbuch Implementation Guide for WebSphere InterChange Server nachlesen.

Upgrade der Toolkonfigurationsdatei vornehmen

Eine der Tasks in der Toolkonfigurationsdatei cwtools.cfg stellt angepasste Dateien .jar bereit, damit diese in die Kompilierung aufgenommen werden. Falls Sie angepasste Dateien .jar erstellt haben, müssen Sie diese angepassten Dateien zum Abschnitt codeGeneration in der Variablen CLASSPATH hinzufügen. Die Datei cwtools.cfg befindet sich auf der Windows-Maschine, auf der Ihre Tools ausgeführt werden, im folgenden Verzeichnis:

PRODUKTVERZ\bin
 

Umgebungsvariablen prüfen

Alle Systemumgebungsvariablen werden in einer einzigen Datei CWSharedEnv.sh festgelegt. Diese Datei wird von allen Startscripts während ihrer Aufrufprozedur gelesen. In dieser Datei sind die systemweiten Eigenschaften von ICS (z. B. für den IBM Java ORB) definiert. Im Rahmen des Upgradeprozesses müssen Sie sicherstellen, dass die folgenden systemweiten Eigenschaften korrekt festgelegt sind:

Weitere Informationen zur Datei CWSharedEnv.sh enthält das Handbuch System Administration Guide.

Auf angepasste Komponenten zugreifen

Wenn Sie mit vollständig angepassten Komponenten arbeiten, die Repositorytabellen verwenden (z. B. Scripts, Datenbanktabellen oder gespeicherte Prozeduren), müssen Sie auf jede Komponente zugreifen und prüfen, ob ein Upgrade erforderlich ist. Falls beispielsweise eine gespeicherte Prozedur eine Repositorytabelle verwendet, die im neuen Release geändert wurde, müssen Sie diese gespeicherte Prozedur so ändern, dass die neue Struktur der Repositorytabelle verwendet wird.

Anmerkung:
Die Änderung von Ereignistabellen oder Auslösern ist nicht erforderlich, falls das Schema nicht geändert wurde.

Neue Version nach dem Upgrade starten

Nachdem die Installation vollständig ausgeführt wurde, können Sie die neue Version von InterChange Server unter Verwendung der vorhandenen Version für das Repository starten, sofern die gesamte erforderliche unterstützende Software aktiv ist. Falls Sie einen Upgrade mit Datenbank an gleicher Stelle vorgenommen haben, muss ICS auf das Originalrepository zeigen. So starten Sie ICS:

  1. Es ist zwar nicht zwingend erforderlich, aber ratsam, einen Warmstart der Maschine auszuführen.
  2. Falls Sie bei der Installation einen Upgrade der Datenbank an gleicher Stelle vorgenommen haben, verwenden Sie erneut die vorherige Serverkonfigurationsdatei InterchangeSystem.cfg. Haben Sie den Upgrade der Datenbank mit einer anderen Position ausgeführt, verwenden Sie die neue Konfigurationsdatei, die vom Installationsprogramm generiert wurde. Kopieren Sie bei Verwendung der vorherigen Konfigurationsdatei die alte Konfigurationsdatei in das Verzeichnis PRODUKTVERZ der neuen Installation. Wenn Sie die neue Konfigurationsassistent verwenden, verwenden Sie den Assistenten für die Serverkonfiguration, um die Einstellungen entsprechend zu ändern. Bitte achten Sie darauf, dass der Servername mit der vorherigen Serverinstallation übereinstimmt, wenn Sie einen Upgrade von fehlgeschlagenen Ereignissen aus der alten ICS-Version vornehmen wollen.
  3. Stellen Sie sicher, dass die gesamte erforderliche unterstützende Software aktiv ist. Zur unterstützenden Software gehören:

    In den Abschnitten Unterstützende Software starten und IBM ORB Transient Naming Server starten ist beschrieben, wie Sie prüfen können, ob die unterstützende Software aktiv ist.

  4. Starten Sie InterChange Server.

    Anweisungen zum Starten von InterChange Server finden Sie unter InterChange Server starten und System Manager starten.

In der Datei InterchangeSystem.log im Verzeichnis PRODUKTVERZ können Sie überprüfen, ob der Start erfolgreich ausgeführt wurde.

Anmerkung:
Falls der Start von InterChange Server nach dem Upgrade des InterChange Server-Systems fehlschlägt, prüfen Sie in der vorliegenden Upgrade-Prozedur, ob Sie wirklich alle Anweisungen befolgt haben. Ist die Ursache des Fehlers anschließend weiterhin unbekannt, bitten Sie die technische Unterstützung von IBM um Hilfe, bevor Sie versuchen, Anpassungen vorzunehmen oder eine Sicherungskopie wiederherzustellen.

Upgrade des Repositorys vornehmen

Das InterChange Server-Repository ist eine Datenbank, die Metadaten über die InterChange Server-Komponenten enthält. Sie können den Upgrade mit Datenbank an gleicher Stelle oder in einer anderen Position ausführen. Das ICS-Installationsprogramm der Version 4.3 nimmt keinen automatischen Upgrade des Inhalts im ICS-Repository vor. Wenn Sie - bei einem Upgrade mit Datenbank an gleicher Stelle - ICS im vorherigen Schritt gestartet haben, nimmt ICS jedoch einen Upgrade des Schemas im Repository der Vorgängerversion von 4.3 vor und verwendet alle Änderungen aus Version 4.3. An dieser Stelle des Upgradeprozesses müssen Sie entscheiden, welche Objekte in das Repository geladen werden sollen:

Wichtiger Hinweis:
Falls Sie den Upgrade nicht mit Datenbank in gleicher Stelle vornehmen, laden Sie die vorhandenen Repositoryobjekte in das neue Repository von Version 4.3. Weitere Informationen finden Sie unter Bereits vorhandene Repositoryobjekte laden.

Auf einer verbundenen Windows-Maschine können Sie in der System Manager-Sicht "InterChange Server - Komponentenverwaltung" die Komponenten anzeigen, die in den Server geladen wurden.

Bereits vorhandene Repositoryobjekte laden

Die Schritte in diesem Abschnitt sind nur dann erforderlich, wenn Sie beim Upgrade von InterChange Server keinen Upgrade der Datenbank an gleicher Stelle vorgenommen haben.

Im Rahmen des ICS-Installationsprozesses haben Sie die Namen dieser ICS-Datenbanken im ICS-Konfigurationsassistenten angegeben. Als Sie die neue Version von ICS gestartet haben, hat der Server den Upgrade des Schemas in der Repositorydatenbank vorgenommen. Um dieses neue Repository zu initialisieren, müssen Sie nun die bereits vorhandenen Repositoryobjekte laden.

So bereiten Sie das Laden des Repositorys vor:

  1. Kopieren Sie die vorhandenen Java-Klassendateien (.class) für Zuordnungen und Collaborations in die neue Verzeichnisstruktur:

    Hierbei steht PRODUKTVERZ für das Produktverzeichnis des neuen Release 4.3. Dieser Schritt stellt sicher, dass die Dateien .class für die vorhandenen Zuordnungen und Collaborations in der neuen Verzeichnisstruktur von Version 4.3 enthalten sind.

  2. Stellen Sie sicher, dass alle vom ICS-System für Beziehungen und Datenbankverbindungen verwendeten Datenbanken aktiv sind. Achten Sie auch darauf, dass ICS aktiv ist.
  3. Laden Sie die bereits vorhandenen Repositoryobjekte:
    1. Bearbeiten Sie die Repositorydatei, um verschiedene Inkompatibilitäten zu korrigieren.
    2. Löschen Sie alle Repositoryobjekte aus dem Repository.
    3. Laden Sie die bereits vorhandenen Objekte.

    Alle einzelnen Schritte für das Laden des Repositorys sind in den folgenden Abschnitten beschrieben.

Repositorydatei vorbereiten

Die Schritte in diesem Abschnitt sind nur bei einem Upgrade ausgehend von Version 4.1.1 erforderlich.

Prüfen Sie die vorhandene Sicherungsdatei von repos_copy (diese Datei wird als Repositorydatei bezeichnet), und stellen Sie sicher, dass alle Werte für das neue Repository relevant sind. Erstellen Sie eine Sicherungskopie der vorhandenen Repositorydatei, und bearbeiten Sie die ursprüngliche Repositorydatei, um die folgenden Angaben zu korrigieren:

Anmerkung:
Wenn Sie nicht alle Repositoryobjekte aus der Datei mit den bereits vorhandenen Repositoryobjekten laden wollen, können Sie die nicht benötigten Objekte aus der Repositorydatei, die Sie in das Repository von Version 4.3 importieren, löschen.

Inhalt des neuen Repositorys löschen

Bevor Sie die bereits vorhandenen Repositoryobjekte importieren, müssen Sie alle doppelten Objekte, die im Repository der Version 4.3 möglicherweise bereits vorhanden sind, löschen. Dieser Schritt ist erforderlich, weil das Dienstprogramm repos_copy die Optionen -ar oder -arp (mit denen doppelte Objekte verarbeitet werden) beim Importieren eines älteren Formats in das Repository nicht erkennt. Falls ICS in der Repositorydatei doppelt vorhandene Objekte findet, wird die gesamte Importoperation rückgängig gemacht.

Verwenden Sie zum Löschen dieser Repositoryobjekte die Option -d des Dienstprogramms repos_copy. Der folgende Befehl repos_copy löscht beispielsweise den Inhalt des Repositorys:

repos_copy -sneue_ics-instanz -uadmin -ppasswd -d
 

Für die Angaben im obigen Befehl repos_copy gilt Folgendes:

Repositorydatei importieren

Um den Inhalt der Repositorydateien in das Repository zu laden, verwenden Sie das Dienstprogramm repos_copy. Wie unter InterChange Server-System sichern erläutert, sollten Sie die bereits vorhandenen Repositoryobjekte mit der Option -o des Dienstprogramm repos_copy exportiert haben, um eine oder mehrere Repositorydateien zu erstellen. Jetzt importieren Sie diese Repositoryobjekte in das neue Repository und verwenden hierbei die Option -i des Dienstprogramms repos_copy.

Anmerkung:
In Version 4.1.1 von InterChange Server wurden die Projektdefinitionen im Repository gespeichert. In Version 4.3 von InterChange Server werden Projektdefinitionen nicht mehr im Repository gespeichert. Sie werden nun über ICLs (Integration Component Libraries - Integrationskomponentenbibliotheken) und Benutzerprojekte definiert. Die Importoperation lädt alle Repositoryobjekte, die in der Repositorydatei definiert sind, mit Ausnahme von Projektdefinitionen. Weitere Informationen enthält das Handbuch Systeminstallation für Windows.

Beispiel: Sie verwenden die Repositorydatei Repository411.txt. Der folgende Befehl repos_copy lädt alle Repositoryobjekte, die in dieser Datei enthalten sind:

 repos_copy -iRepository411.txt -sservername -ubenutzername -pkennwort -r*
 

Für die Angaben im obigen Befehl repos_copy gilt Folgendes:

Nachdem die bereits vorhandenen Repositoryobjekte in das neue Repository aufgenommen wurden, müssen Sie zusätzliche Schritte ausführen, damit der Upgrade von Collaborationschablonen und Zuordnungen abgeschlossen werden kann. Weitere Informationen finden Sie unter Upgrades von Collaborationschablonen und Zuordnungen vornehmen.

Copyright IBM Corp. 1997, 2004