Nachdem das System in den internen Wartestatus versetzt und gesichert wurde, können Sie mit der Upgrade-Prozedur beginnen.
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.
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:
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:
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.
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. |
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.
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.
Falls Sie im bereits vorhandenen InterChange Server-System angepasste Dateien erstellt hatten, müssen Sie prüfen, ob die folgenden Dateien einen Upgrade erfordern:
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:
Falls Sie beispielsweise angepasste Datenhandler verwendet haben, nehmen Sie deren Dateien .jar in die Variable CLASSPATH auf.
Sobald Sie den Upgradeprozess und den Test abgeschlossen haben, können Sie die Option -design aus dem Serverstart entfernen, damit InterChange Server im Produktionsmodus gestartet wird.
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
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.
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.
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:
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.
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.
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:
Das Installationsprogramm kopiert automatisch die entsprechenden Eingabedateien für die verschiedenen ICS-Komponenten in das Verzeichnis PRODUKTVERZ und unterschiedliche Unterverzeichnisse von PRODUKTVERZ, einschließlich /repository (PRODUKTVERZ ist das Produktverzeichnis für das neue Release 4.3). Diese Eingabedateien enthalten die neuen Komponenten für das ICS-Release 4.3.
Falls Sie Ihr ICS-Repository mit dem Befehl repos_copy gesichert haben, sind eine oder mehrere Repositorydateien vorhanden, die die Repositoryobjekte für die Komponenten aus dem vorhandenen ICS-Vorgängerrelease enthalten.
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.
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:
PRODUKTVERZ/DLMs/classes/NativeMaps
PRODUKTVERZ/collaborations/classes/UserCollaborations
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.
Alle einzelnen Schritte für das Laden des Repositorys sind in den folgenden Abschnitten beschrieben.
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:
Wenn Sie Beziehungen importieren, müssen Sie sicherstellen, dass die folgenden Attribute für jede Beziehung in der Repositorydatei gültig sind:
Falls diese Attribute eine Datenbank angeben, die während des Imports von repos_copy in das ICS-Repository nicht gefunden werden kann, macht InterChange Server die gesamte Importoperation rückgängig. Falls Sie jedoch diese Attribute für alle Beziehungen löschen, verwendet InterChange Server das Repository als Standardbeziehungsdatenbank.
Datenbankverbindungspools im Format von Version 4.1.1 können nicht in das neue Repository importiert werden. Daher müssen Sie alle Verbindungspools aus der Repositorydatei löschen. Nach dem Upgrade der ICS-Instanz müssen Sie diese Verbindungspools auf einer verbundenen Windows-Maschine in System Manager erneut erstellen.
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:
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.
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.