Vorhandenes ICS-System vorbereiten

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.

  1. Schritt 1 - InterChange Server-System sichern
  2. Schritt 2 - System in internen Wartestatus versetzen
  3. Schritt 3 - InterChange Server und Software anderer Anbieter deinstallieren
  4. Schritt 4 - InterChange Server und Software anderer Anbieter installieren
  5. Schritt 5 - Upgrade des Object-Request-Brokers vornehmen
  6. Schritt 6 - Upgrade von InterChange Server vornehmen
  7. Schritt 7 - InterChange Server und Software anderer Anbieter starten
  8. Schritt 8 - Repository laden
  9. Schritt 9 - Spezielle Upgrade-Prozeduren für die Migration von Version 4.1.1
  10. Schritt 10 - Upgrade prüfen

Schritt 1 - InterChange Server-System sichern

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:

Tabelle 15 fasst die Sicherung der unterschiedlichen ICS-Komponenten zusammen.

Tabelle 15. Sicherungsmethoden für InterChange Server-Daten
Datentyp Sicherungsmethode
Statische Daten

Repository
Verwenden Sie das Dienstprogramm repos_copy, um einige oder alle der angepassten InterChange Server-Komponenten zu sichern. Weitere Informationen finden Sie in der Beschreibung der Sicherung von InterChange Server-Komponenten des Handbuchs System Administration Guide.

Java- Klassendateien (.class) und Nachrichtendateien (.msg) von angepassten Collaborations Schließen Sie das Unterverzeichnis collaborations im Verzeichnis PRODUKTVERZ in die Systemdatensicherung ein:
PRODUKTVERZ\collaborations
 

Java-Klassendateien (.class) von angepassten Zuordnungen
Damit diese Dateien bei der Systemdatensicherung berücksichtigt werden, müssen Sie sicherstellen, dass das folgende Verzeichnis in der Systemsicherung angegeben ist:
PRODUKTVERZ\DLMs
 

Angepasste Connectors Nehmen Sie das folgende Verzeichnis in die Systemdatensicherung auf: PRODUKTVERZ\connectors\connectorname (hierbei steht connectorname für den Namen des angepassten Connectors)

Angepasste Startscripts Falls Sie angepasste Startscripts verwenden, müssen Sie sicherstellen, dass diese bei der Systemdatensicherung berücksichtigt werden.

ICS-Konfigurationsdatei (InterchangeSystem.cfg) Nehmen Sie die ICS-Konfigurationsdatei, die sich im Verzeichnis PRODUKTVERZ befindet, in die Systemdatensicherung auf.
Dynamische Daten

Querverweis-, Fehlerereignis- und Beziehungstabellen Verwenden Sie das Datenbanksicherungsprogramm für die Datenbank. Weitere Informationen finden Sie in der Beschreibung der Sicherung von InterChange Server-Komponenten des Handbuchs System Administration Guide.

Ereignisarchivierungstabellen für Connectors Verwenden Sie das Datenbanksicherungsprogramm für die Datenbank, die diese Tabellen enthält.

Protokolldateien Nehmen Sie das folgende Verzeichnis in die Systemdatensicherung auf:
PRODUKTVERZ
 

Schritt 2 - System in internen Wartestatus versetzen

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:

  1. Übergeben Sie fehlgeschlagene Ereignisse erneut, oder löschen Sie die Ereignisse (dieser Schritt ist optional). Sie können fehlgeschlagene Ereignisse auch in den Upgrade auf ICS einschließen und nach dem Systemupgrade verarbeiten.
  2. Beenden Sie alle Adapterabfragen von Ereignistabellen, indem Sie die Eigenschaft PollFrequency auf No setzen.
  3. Lassen Sie alle Ereignisse (inklusive aller laufender Ereignisse) das System durchlaufen. Alle unbestätigten Transaktionen müssen aufgelöst werden.
  4. Stoppen Sie die Collaborations. Diese Task stellt sicher, dass während des Upgrades keine Ereignisse InterChange Server passieren.
  5. Löschen Sie den Inhalt der Warteschlangen, indem Sie alle alten Ereignisse aus den Warteschlangen entfernen.
    Anmerkung:
    Führen Sie Schritt 5 nur dann aus, wenn Sie Ihre fehlgeschlagenen Ereignisse nicht verarbeiten und die Ereignisse erneut durch die Anwendung übergeben lassen wollen. Falls Sie den Upgrade von fehlgeschlagenen Ereignissen auswählen und den MQ-Transport verwenden, dürfen Sie den Inhalt der Warteschlangen NICHT LÖSCHEN. Sie sollten die Warteschlangen sichern und nach dem Upgrade wiederherstellen. Informationen zur Sicherung von Warteschlangen finden Sie in der Dokumentation von MQ.
  6. Beenden Sie InterChange Server und alle zugehörigen Komponenten.
  7. Beenden Sie die Datenbank.
  8. Beenden Sie den ORB (Visibroker) bei ICS-Versionen vor 4.2.2.
  9. Beenden Sie MQSeries.

Informationen zur ordnungsgemäßen Beendigung eines aktiven Systems finden Sie im Handbuch System Administration Guide.

Schritt 3 - InterChange Server und Software anderer Anbieter deinstallieren

Die folgenden Schritte stellen die geeignete Reihenfolge für die Deinstallation von Software anderer Anbieter dar:

  1. Deinstallieren Sie den ORB (Visibroker) (bei früheren Versionen als 4.2.2)
  2. Deinstallieren Sie InterChange Server (ICS).
  3. Deinstallieren Sie JDK.
  4. Löschen Sie Ihre Repositorytabellen. Die Tabellen werden im Rahmen des ICS-Upgrades wiederhergestellt.
    Anmerkung:
    Bei einem Upgrade mit Datenbank an gleicher Stelle dürfen Sie die Repositorytabellen nicht löschen, da Sie das Repository in der neuen Installation wiederverwenden werden.

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.

Schritt 4 - InterChange Server und Software anderer Anbieter installieren

Die folgenden Schritte stellen die geeignete Reihenfolge für die Installation der InterChange Server-Komponenten dar.

Wichtiger Hinweis:
Falls Sie einen Upgrade für Software anderer Anbieter ausführen müssen, lassen Sie vom Systemadministrator vor dem Upgrade unbedingt die Software sichern.

  1. Installieren Sie IBM JDK 1.4.2.
  2. Installieren Sie das Datenbankverwaltungssystem bzw. nehmen Sie einen Upgrade vor, und stellen Sie die Laufzeittabellen wieder her, wenn Sie die Laufzeitdaten beibehalten wollen.

    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.

  3. WebSphere MQ 5.3.02 (CSD07) muss installiert werden bzw. es muss ein Upgrade auf diese Version erfolgen.
    Wichtiger Hinweis:
    Ob Sie die Schritte in diesem Abschnitt ausführen müssen, ist von der aktuellen Version von InterChange Server abhängig:

    • Bei einem Upgrade von den InterChange Server-Versionen 4.2.0, 4.2.1 oder 4.2.2 ist ein Upgrade von WebSphere MQ nicht erforderlich.
    • Bei einem Upgrade von der InterChange Server-Versionen 4.1.1 führen Sie die Schritte in diesem Abschnitt aus, um WebSphere MQ auf die neue Version zu migrieren.

    Bei einem Upgrade von WebSphere MQ können Sie eine der folgenden Methoden anwenden:

    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.

  4. Installieren Sie InterChange Server in einem neuen Verzeichnis, also einem anderen Verzeichnis als die vorherige Version von ICS.

Schritt 5 - Upgrade des Object-Request-Brokers vornehmen

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):

Anmerkung:
Einen allgemeinen Überblick über den IBM Java ORB enthält das Handbuch System Administration Guide.

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.

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.

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

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.

Schritt 6 - Upgrade von InterChange Server vornehmen

Zusätzliche Informationen zum Upgrade finden Sie unter Upgrade der Serverscripts vornehmen und Komponentenupgrades abschließen.

Anmerkungen:

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

  2. Wenn Sie das Installationsprogramm auffordert, 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 von 4.3 verwendet haben. Dies ist erforderlich, damit die Portierbarkeit von fehlgeschlagenen Ereignissen gewährleistet werden kann.

  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:

Schritt 7 - InterChange Server und Software anderer Anbieter starten

  1. Führen Sie einen Warmstart der InterChange Server-Maschine aus.
  2. Starten Sie den Persistent Naming Server von IBM ORB, indem Sie die Stapeldatei "PersistentNameServer.bat" ausführen, die sich im Verzeichnis PRODUKTVERZ\bin befindet.
  3. Starten Sie IBM MQSeries.

    Vergewissern Sie sich, dass der Warteschlangenmanager und das Empfangsprogramm betriebsbereit sind.

  4. Starten Sie die Datenbank, wenn diese lokal ausgeführt wird.
  5. Bei einem Upgrade ausgehend von Version 4.1.1 kopieren Sie die Dateien ".class", ".java" und die Nachrichtendateien, die zuvor für DLMs und Collaborations gesichert wurden, in die entsprechenden Verzeichnisse. Dateien für DLMs kopieren Sie in die Verzeichnisse PRODUKTVERZ\DLMs\classes und PRODUKTVERZ\DLMs\messages. Dateien für Collaborations kopieren Sie in die Verzeichnisse PRODUKTVERZ\collaborations\classes und PRODUKTVERZ\collaborations\messages.
  6. Bei Migration mit Datenbank an gleicher Stelle: ICS muss auf die Datenbank zeigen, in der sich das Originalrepository befindet. Dies erreichen Sie entweder durch die Wiederverwendung der alten Datei "InterchangeSystem.cfg" oder durch die Festlegung der Datenbankparameter im ICS-Konfigurationsassistenten.
  7. Starten Sie InterChange Server.

    Anweisungen zum Starten von InterChange Server finden Sie unter "InterChange Server einrichten".

    Anmerkung:
    Der Servername muss derselbe wie in der Vorgängerversion sein, damit die Portierbarkeit von fehlgeschlagenen Ereignissen sichergestellt ist.

    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.

Schritt 8 - Repository laden

Anmerkung:
Dieser Schritt ist nicht erforderlich, wenn Sie einen Upgrade mit Datenbank an gleicher Stelle vornehmen.

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.

Schritt 9 - Spezielle Upgrade-Prozeduren für die Migration von Version 4.1.1

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.

  1. Führen Sie einen Warmstart des soeben installierten Servers aus.
  2. Stellen Sie in System Manager eine Verbindung zum Server her.
  3. Erstellen Sie eine temporäre ICL (Integration Component Library - Integrationskomponentenbibliothek), und importieren Sie alle Komponenten aus dem Server.
  4. Kompilieren Sie alle Zuordnungen und Collaborationschablonen.
  5. Erstellen Sie ein Projekt, und nehmen Sie alle Komponenten aus der zuvor erstellten ICL auf.
  6. Löschen Sie das Repository auf dem Server.
  7. Implementieren Sie das Projekt auf dem Server.

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.

Schritt 10 - Upgrade prüfen

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:

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

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:

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 im folgenden Verzeichnis:

PRODUKTVERZ/bin
 

Umgebungsvariablen prüfen

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.

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 sollte nicht erforderlich sein, falls das Schema nicht geändert wurde.

Upgrade des Repositorys vornehmen

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:

In der System Manager-Sicht "InterChange Server - Komponentenverwaltung" können Sie die Komponenten ansehen, die in den Server geladen wurden.

Bereits vorhandene Repositoryobjekte laden

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:

  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. Weitere Informationen finden Sie weiter unten im Abschnitt Repositorydatei vorbereiten.
    2. Löschen Sie alle Repositoryobjekte aus dem Repository.
    3. Laden Sie die bereits vorhandenen Objekte.

    Alle einzelnen Schritte für die Verarbeitung von bereits vorhandenen Repositoryobjekten sind in den folgenden Abschnitten beschrieben.

Repositorydatei vorbereiten

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 -pnull -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 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.

Anmerkung:
Die Importoperation lädt alle Repositoryobjekte, die in der Repositorydatei definiert sind, mit Ausnahme von Projektdefinitionen. Projektdefinitionen werden nicht mehr im Repository gespeichert. Sie werden nun über ICLs (Integration Component Libraries - Integrationskomponentenbibliotheken) und Benutzerprojekte definiert. Weitere Informationen finden Sie unter Vorhandene Benutzerprojekte importieren.

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.

Copyright IBM Corp. 1997, 2004