Bei der Vorbereitung des ICS-Systems auf einen Upgrade haben Sie zwei Möglichkeiten, um die ICS-Datenbank zu migrieren. Sie können eine Datenbankmigration an gleicher Stelle vornehmen oder aber eine Datenbankmigration mit einer anderen Position ausführen. Eine Datenbankmigration an gleicher Stelle bedeutet, dass Sie das alte Repository erneut verwenden und den Upgrade des Repositorys von ICS beim ersten ICS-Serverstart vornehmen lassen. Eine Datenbankmigration mit einer anderen Position bedeutet, dass Sie beim Upgrade eine ganz neue und leere Repositorydatenbank verwenden.
Der Upgrade des InterChange Server-Systems mit einer Datenbankmigration in einer anderen Position umfasst die folgenden Schritte: Wenn Sie eine Datenbankmigration an gleicher Stelle verwenden, sind die Änderungen in den Anweisungen durch die Angabe "Datenbankmigration an gleicher Stelle" kenntlich gemacht.
Mit einer Sicherung des InterChange Server-Systems können Sie alle Dateien wiederherstellen, die bei der Installation der neuen Version möglicherweise versehentlich überschrieben wurden. Bevor Sie die Upgrade-Prozedur ausführen, sichern Sie daher sowohl statische als auch dynamische Daten (also änderbare Daten, die Sie unabhängig von Upgrades regelmäßig sichern). Beispiele für statische und dynamische Daten finden Sie in Tabelle 15.
So sichern Sie das System:
repos_copy -sWICS -oRepository430.txt -uadmin -pnull
Bei Version 4.1.1 erstellt das Dienstprogramm repos_copy eine Sicherung der Repositoryobjekte in einer Datei *.txt oder *.in.
Bei Version 4.2.2 und höheren Versionen erstellt das Dienstprogramm repos_copy eine Sicherung der Repositoryobjekte in einer Datei *.jar.
PRODUKTVERZ\mqseries\crossworlds_mq.tst
IBM empfiehlt die Erstellung einer Systemdatensicherung für das gesamte Produktverzeichnis von InterChange Server.
Tabelle 15 fasst die Sicherung der unterschiedlichen ICS-Komponenten
zusammen.
Tabelle 15. Sicherungsmethoden für InterChange Server-Daten
Vor einem Upgrade des InterChange Server-Systems auf Version 4.3 müssen Sie sicherstellen, dass sich das System im internen Wartestatus befindet. Dies bedeutet, dass alle laufenden Ereignisse abgeschlossen und alle unbestätigten Transaktionen aufgelöst sein sollten, bevor Sie die Umgebung sichern und die Upgrade-Prozedur ausführen.
So können Sie das InterChange Server-System in den internen Wartestatus versetzen:
Informationen zur ordnungsgemäßen Beendigung eines aktiven Systems finden Sie im Handbuch System Administration Guide.
Die folgenden Schritte stellen die geeignete Reihenfolge für die Deinstallation von Software anderer Anbieter dar:
Falls InterChange Server-Komponenten als Services ausgeführt werden, deinstallieren Sie diese Services vor dem Upgrade. Da sich das neue Release in einer anderen Position befindet, sind vorhandene Servicedefinitionen falsch. Nach Abschluss des Upgrades finden Sie in "Optionen für die erweiterte Konfiguration" Anweisungen für die Konfiguration von InterChange Server-Komponenten als Services.
Die folgenden Schritte stellen die geeignete Reihenfolge für die Installation der InterChange Server-Komponenten dar.
Falls Sie eine Migration von einer früheren Version von InterChange Server ausführen, prüfen Sie, ob Sie auch einen Upgrade der Datenbanksoftware vornehmen müssen. Eine Liste der unterstützten Datenbanksoftware finden Sie im Abschnitt mit den Softwarevoraussetzungen (siehe Softwarevoraussetzungen). Vergleichen Sie die Version der vorhandenen Datenbanksoftware mit der Version, die von Version 4.3 des Produkts unterstützt wird.
Falls Sie einen Upgrade der Datenbanksoftware vornehmen müssen, achten Sie darauf, dass der Datenbankadministrator die folgenden Schritte ausführt:
Anweisungen zur Sicherung und zum Upgrade der Datenbanksoftware finden Sie in der Dokumentation des Datenbankservers. Weitere Informationen zur Migration der Datenbank können Sie unter Schritt 8 - Repository laden nachlesen.
Bei einem Upgrade von WebSphere MQ können Sie eine der folgenden Methoden anwenden:
Achten Sie bei der Installation von WebSphere 5.3 darauf, die angepasste Installation und die Option für das Einschließen von Java Messaging auszuwählen. Bei Auswahl der Option für die Standardinstallation werden die erforderlichen Dateien für Java Messaging nicht installiert. Ausführliche Anweisungen finden Sie unter WebSphere MQ installieren.
Ausführliche Anweisungen finden Sie unter Upgrade für WebSphere MQ vornehmen.
Sobald Sie den Upgrade der WebSphere MQ-Software vorgenommen haben, müssen Sie die Software für die Verwendung mit InterChange Server konfigurieren. Weitere Informationen enthält die Beschreibung unter WebSphere MQ konfigurieren.
Das WebSphere InterChange Server-System setzt für die Verarbeitung der Kommunikation zwischen ICS und seinen Clients (z. B. Connectors, Tools von WebSphere Business Integration, SNMP-Agenten und Zugriffsclients) nicht mehr den Object-Request-Broker (ORB) von VisiBroker ein. Stattdessen verwendet das InterChange Server-System jetzt den IBM Java ORB. Das ICS-Installationsprogramm installiert den IBM Java ORB automatisch als Teil der JRE (Java Runtime Environment).
InterChange Server verwendet zur Bereitstellung des Namensservices anstelle von VisiBroker Smart Agent nun den IBM Transient Naming Server. Um einen Upgrade des Systems auf die Verwendung des neuen Namensservers vorzunehmen, führen Sie eine der folgenden Aktionen aus (welche Aktion zu verwenden ist, hängt davon ab, ob VisiBroker Smart Agent auf derselben Maschine wie der IBM Transient Naming Server installiert ist und auf dieser Hostmaschine verbleiben muss):
Die Verwendung der Eigenschaften für die Konfiguration des IBM Java ORB wurde in den Startscripts festgelegt, die von der Installation bereitgestellt werden. Falls Ihre ICS-Vorgängerversion von 4.3 die Inprise VisiBroker-Software verwendete und Sie Eigenschaften für den VisiBroker-ORB angepasst haben, müssen Sie ähnliche Änderungen unter Umständen auch an den neuen Scripts vornehmen, um die Migration von 4.3 auf den IBM ORB zu ermöglichen. Weitere Informationen zu den Eigenschaften von IBM ORB und ihren VisiBroker-Entsprechungen finden Sie unter 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 16 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.3 vorhanden, die auf Eigenschaften des VisiBroker-ORB verweisen, ersetzen Sie sie durch ihre IBM ORB-Entsprechungen, die in Tabelle 16 aufgeführt sind.
Tabelle 16. IBM ORB-Eigenschaften und ihre VisiBroker-Entsprechungen
IBM ORB-Eigenschaft | VisiBroker-Entsprechung | 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. Der VisiBroker-Eigenschaftsname OAport wird 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. Der VisiBroker-Eigenschaftsname OAthreadMaxIdle wird 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.3 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.
Zusätzliche Informationen zum Upgrade finden Sie unter Upgrade der Serverscripts vornehmen und Komponentenupgrades abschließen.
Anmerkungen:
Vergewissern Sie sich, dass der Warteschlangenmanager und das Empfangsprogramm betriebsbereit sind.
Anweisungen zum Starten von InterChange Server finden Sie unter "InterChange Server einrichten".
In der Datei InterchangeSystem.log im Verzeichnis PRODUKTVERZ können Sie überprüfen, ob der Start erfolgreich ausgeführt wurde.
Laden Sie die Repository-Datei aus der Vorgängerversion mit dem Befehl repos_copy. Geben Sie beispielsweise Folgendes ein, wenn für den ICS-Namen der Wert "WICS", für den Benutzernamen/das Kennwort der Wert "admin/null" und eine Repository-Datei namens "repos_backup.jar" verwendet werden (verwenden Sie bei einem Upgrade von 4.1.1 die Datei "repos_backup.in"):
repos_copy -sWICS_NAME -irepos_backup.jar -uadmin - pnull
Weitere Informationen zum Repository finden Sie unter Upgrade des Repositorys vornehmen.
Bei einem Upgrade ausgehend von ICS 4.1.1 müssen Sie mit den folgenden Schritten einen Upgrade der alten DLMs und Collaborations für die Tools ausführen.
Weitere Informationen zu ICLs finden Sie unter Import in ICL ausführen.
Bei Servern mit einer Version 4.2.x sind diese Schritte nicht erforderlich.
Um den Erfolg des Upgrades zu prüfen, müssen Sie sich vergewissern, ob das Repositoryschema erstellt wurde und ob alle Objekte erfolgreich geladen worden sind. Dies stellen Sie sicher, indem Sie Folgendes prüfen:
Falls Sie im bereits vorhandenen InterChange Server-System angepasste Dateien erstellt hatten, müssen Sie prüfen, ob die folgenden Dateien einen Upgrade erfordern:
Alle Startscripts wurden geändert, damit der Umstieg vom VisiBroker-ORB auf den IBM Java ORB und die Unterstützung der IBM JRE ermöglicht wird. Hierzu gehören die folgenden Änderungen:
Falls Sie Startscripts aus einer Vorgängerversion von 4.3 angepasst haben, müssen Sie ähnliche Änderungen an den neuen Scripts von Version 4.3 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 im folgenden Verzeichnis:
PRODUKTVERZ/bin
Alle Systemumgebungsvariablen werden nun in einer einzigen Datei CWSharedEnv 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 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.
Das InterChange Server-Repository ist eine Datenbank, die Metadaten über die InterChange Server-Komponenten enthält. Das ICS-Installationsprogramm nimmt keinen automatischen Upgrade für den Inhalt des ICS-Repositorys vor. Wenn Sie 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:
Für jede einzelne (nicht separat installierte) ICS-Komponente, deren Installation Sie auswählen, kopiert das Installationsprogramm automatisch die entsprechenden Eingabedateien in das Verzeichnis PRODUKTVERZ\repository. Diese Eingabedateien enthalten die Repositoryobjekte für die neuen Komponenten, die Sie zusammen mit dem Release 4.3 installiert haben.
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.
In der System Manager-Sicht "InterChange Server - Komponentenverwaltung" können Sie die Komponenten ansehen, die in den Server geladen wurden.
Bei einem Upgrade ausgehend von der InterChange Server-Version 4.1.1, der einen Upgrade der Datenbanksoftware einschließt, sollte der Datenbankadministrator den neuen Datenbankserver installiert und alle für die ICS-Datenbanken erforderlichen Änderungen (inklusive des ICS-Repositorys) verarbeitet 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 die Verarbeitung von bereits vorhandenen Repositoryobjekten sind in den folgenden Abschnitten beschrieben.
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 die obigen 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 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 -pnull -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 in Schritt 1 - 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 noch 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.