Für bestimmte InterChange Server-Komponenten sind zusätzliche Tasks
erforderlich, damit der Upgrade abgeschlossen werden kann. Die
folgenden Abschnitte beschreiben, wie Sie diese Upgrades vollständig
beenden:
- 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 der InterChange Server-Version 4.1.1
führen Sie die Schritte in diesem Abschnitt aus, um die bereits vorhandenen
ICS-Komponenten in eine ICL (Integration Component Library -
Integrationskomponentenbibliothek) zu importieren.
- Bei einem Upgrade von den InterChange Server-Versionen
4.2.0, 4.2.1 oder 4.2.2 ist ein
Import von ICS-Komponenten in eine ICL nicht erforderlich, weil die
bereits vorhandenen ICLs weiterhin existieren. Fahren Sie mit den
Anweisungen unter Upgrades von Collaborationschablonen und Zuordnungen vornehmen fort.
Ab Version 4.2.0.x erfolgt die Entwicklung von
ICS-Komponenten nicht mehr (wie in der Version 4.1.1) in der
ICS-Instanz, sondern lokal. Daher müssen Sie bei einem Upgrade
ausgehend von Version 4.1.1 eine ICL erstellen. Dies
führen Sie auf der Windows-Maschine, auf der die Tools ausgeführt werden, in
System Manager aus. Die ICL enthält die InterChange
Server-Komponenten. Anweisungen zur Erstellung von ICLs enthält das
Handbuch System Integration Guide. Nachdem Sie eine ICL
(oder mehrere ICLs) erstellt haben, können Sie Komponenten aus dem InterChange
Server-Repository auf der UNIX-Maschine importieren.
- Anmerkung:
- Es empfiehlt sich, die ICS-Komponenten einzeln zu importieren, da der Import
eines großen Datenblocks viel Zeit in Anspruch nehmen und Speicherfehler in
System Manager verursachen kann. Falls Sie ungewöhnlich viele
Komponenten verwenden, kann eine weitere Untergliederung des Importprozesses
ebenfalls sinnvoll sein. Die empfohlene Reihenfolge für den
Komponentenimport ist in Tabelle 33 angegeben.
Tabelle 33. Importreihenfolge für ICS-Komponenten
Reihenfolge
| ICS-Komponente
| Importschritte
|
1
| Geschäftsobjekte
|
Importieren Sie die bereits vorhandenen Geschäftsobjektdefinitionen aus dem
ICS-Repository in System Manager in eine ICL. Detaillierte Angaben zum
Importieren von Komponenten mit dem System Manager-Assistenten "Komponenten
importieren" finden Sie im Handbuch Implementation Guide for WebSphere
InterChange Server.
|
2
| Zuordnungen
| Upgrades von Collaborationschablonen und Zuordnungen vornehmen
|
3
| Collaborationschablonen und -objekte
| Upgrades von Collaborationschablonen und Zuordnungen vornehmen
|
4
| Connectors
| Connector-Upgrades abschließen
|
5
| Beziehungen
|
Importieren Sie die bereits vorhandenen Beziehungsdefinitionen aus dem
ICS-Repository in System Manager in eine ICL. Detaillierte Angaben zum
Importieren von Komponenten mit dem System Manager-Assistenten "Komponenten
importieren" finden Sie im Handbuch Implementation Guide for WebSphere
InterChange Server.
|
Die Anweisungen in diesem Abschnitt müssen nur bei einem Upgrade ausgehend
von Version 4.1.1 ausgeführt werden.
Nach dem Upgrade des ICS-Repositorys können Sie den Upgrade von bereits
vorhandenen Zuordnungen und Collaborationschablonen vornehmen. Dies
umfasst die folgenden Schritte:
Sie müssen unbedingt Ihre bereits vorhandenen Java-Klassendateien
(.class) für Zuordnungen und Collaborationschablonen prüfen,
um sicherzustellen, dass der Code mit der neuen Version kompatibel ist.
- Anmerkung:
- Vergewissern Sie sich, dass sich die Klassendateien im geeigneten Verzeichnis
der neuen Version befinden:
Prüfen Sie, ob die bereits vorhandenen Java-Klassendateien den folgenden
Code enthalten:
- Falls angepasster Code in Zuordnungen und Collaborations
VisiBroker-spezifische CORBA-Erweiterungen verwendet, funktioniert dieser Code
unter dem IBM Java ORB nicht. Sie müssen diesen Code in einen
herstellerneutralen Java-Code ändern. Falls eine Collaboration oder
eine Zuordnung angepasste IDLs mit entsprechenden Stubs verwendet, müssen Sie
diese Stubs mit dem Compiler idlj erneut kompilieren. Der
Compiler idlj wird für alle Plattformen mit dem JDK ausgeliefert
und befindet sich auf der JDK-CD.
- Anmerkung:
- Der Compiler idlj, der mit dem JDK von Sun oder HP heruntergeladen
wird, ist mit dem IBM ORB möglicherweise nicht kompatibel. Verwenden
Sie das auf der JDK-CD bereitgestellte Tool.
- Das IBM JDK ist als Java-kompatibel zertifiziert und sollte keine Probleme
bei der Ausführung von zuvor kompilierten Collaboration- und Zuordnungsklassen
verursachen. Falls Collaborations oder Zuordnungen jedoch angepassten
Code enthalten, der für das JDK von Sun spezifisch ist, müssen Sie diesen Code
in einen herstellerneutralen Java-Code ändern.
Beim Ändern von Java-Klassendateien müssen Sie den Code erneut kompilieren
und die zugeordnete Komponente im ICS-Repository erneut implementieren.
Informationen zum Kompilieren von Zuordnungen enthält das Handbuch Map
Development Guide. Angaben zur Kompilierung von
Collaborationschablonen finden Sie im Handbuch Collaboration Development
Guide. Weitere Informationen zur erneuten Implementierung enthält
der Abschnitt Implementierung auf ICS vornehmen.
- 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 der InterChange Server-Version 4.1.1
führen Sie die Schritte in diesem Abschnitt aus, um das Format der bereits
vorhandenen Collaborationschablonen und Zuordnungen zu konvertieren.
- Bei einem Upgrade ausgehend von den InterChange Server-Versionen
4.2.0, 4.2.1 oder 4.2.2 ist es
nicht erforderlich, das Format von Collaborationschablonen oder
Zuordnungen zu konvertieren. Fahren Sie mit den Anweisungen unter Connector-Upgrades abschließen fort.
Collaborationschablonen und Zuordnungen, die mit älteren Versionen der
InterChange Server-Software als dem Release 4.2.0 erstellt
wurden, müssen in ein neues Format konvertiert werden, das mit der aktuellen
Software kompatibel ist. In dem neuen Format werden alle Informationen
zu Collaborations und Zuordnungen als Teil der Definition für
Collaborationschablonen und Zuordnungen im Repository gespeichert.
- Anmerkung:
- Collaborationschablonen und Zuordnungen, die mit älteren Versionen der
InterChange Server-Software als dem Release 4.0.0 erstellt
wurden, verwenden Collaborationmodelldateien
(collaborationname.clm) und
Zuordnungsentwurfsdateien
(zuordnungsname.dlm), die nicht mehr
benötigt werden. Bitten Sie die technische Unterstützung von IBM um
Hilfe.
So konvertieren Sie Collaborationschablonen und Zuordnungen in das neue
Format:
- Importieren Sie die bereits vorhandenen Zuordnungen und Schablonen aus dem
ICS-Repository in System Manager (ausgeführt auf einer verbundenen
Windows-Maschine) in eine ICL (Integration Component Library -
Integrationskomponentenbibliothek). Detaillierte Angaben zum
Importieren von Komponenten mit dem System Manager-Assistenten "Komponenten
importieren" finden Sie im Handbuch Implementation Guide for WebSphere
InterChange Server.
- Anmerkung:
- Der Assistent "Komponenten importieren" ermittelt alle Zuordnungen und
Collaborationschablonen mit einem älteren Format als Version
4.2. In diesem Fall wird angefragt, ob sie konvertiert werden
sollen. Damit Zuordnungen und Collaborationschablonen in das Format von
Version 4.3 konvertiert werden, müssen Sie darauf achten, dass die
Markierungsfelder "Zuordnungen" und "Collaborationschablonen" ausgewählt
sind.
- Falls Sie die importierten Zuordnungen und Collaborationschablonen
aufgrund von Upgrades der Klassendateien (siehe Upgrade von Klassendateien von Komponenten vornehmen) noch nicht kompiliert haben, führen Sie die Kompilierung
nun durch. Anweisungen zum Kompilieren von Zuordnungen enthält das
Handbuch Map Development Guide (Entwicklung von
Zuordnungen). Angaben zur Kompilierung von Collaborationschablonen
finden Sie im Handbuch Collaboration Development Guide (Entwicklung
von Collaborations).
- Implementieren Sie die Zuordnungen und Collaborationschablonen nach dem
Upgrade im ICS-Repository auf der UNIX-Maschine. Verwenden Sie hierbei
die Option für das Überschreiben. Weitere Informationen finden Sie
unter Implementierung auf ICS vornehmen.
Dieser Abschnitt beschreibt die Schritte für den Upgrade eines
Connectors auf die Version 4.3 von InterChange Server:
- Installieren Sie die relevanten Adapter.
- Nehmen Sie einen Upgrade des Connectors auf den Integrationsbroker
vor:
- Falls Sie Startscripts für Connectors angepasst haben, müssen Sie
möglicherweise einen Upgrade dieser Scripts ausführen. Weitere
Informationen finden Sie unter Upgrade der Connectorstartscripts vornehmen.
- Prüfen Sie den Connector-Upgrade. Weitere Informationen finden Sie
unter Connectorkonfiguration prüfen.
Damit WebSphere Business Integration Adapters mit InterChange Server
verwendet werden kann, müssen Sie Version 2.6 von WebSphere Business
Integration Adapters installieren. Bei einer neuen Installation können
Sie jedoch nicht einfach alle vorhandenen Adapterverzeichnisse (die
Verzeichnisse in den Unterverzeichnissen des Verzeichnisses
PRODUKTVERZ/connectors) kopieren, da es gemeinsam
genutzte Komponenten gibt, die vom Installationsprogramm für WebSphere
Business Integration Adapters bereitgestellt werden. Weil nicht mehr
alle Adapter mit einem einzigen Installationsprogramm installiert werden
können, müssen Sie jeden relevanten Adapter mit seinem eigenen
Installationsprogramm installieren.
- Anmerkung:
- Wenn Sie InterChange Server als Integrationsbroker verwenden, müssen Sie das
Produkt für das Adapter-Framework nicht separat installieren. Das
Adapter-Framework ist in der Installation von InterChange Server
enthalten.
Ausführlichere Anweisungen zur Installation von Adaptern finden Sie in den
einzelnen Adapterhandbüchern.
Wenn die ICS-Konfigurationsdatei (InterchangeSystem.cfg)
Informationen zu Connectoragenten enthält, wird für jeden angegebenen
Connector eine separate connectorspezifische Konfigurationsdatei
erstellt.
- Der Pfad zur Konfigurationsdatei wurde geändert. Daher müssen Sie
den vollständig qualifizierten Pfad zu dieser Datei in der Zeile des
angepassten Connector-Startscripts angeben, die das Script
start_adapter.sh aufruft. Hierzu verwenden Sie die
Option -c wie folgt:
start_adapter.sh -dconnectorname -nconnectorname
-cvollständig_qualifizierter_name_der_neuen_konfigurationsdatei
- Um eine Connectordefinition nach dem Upgrade in das Repository
aufzunehmen, öffnen Sie die neue Connectordefinitionsdatei, die mit Ihrem
Connector bereitgestellt wird (normalerweise lautet der Name der Datei
connectorname.txt) im Connector Configurator (auf
der verbundenen Windows-Maschine, auf der die Tools ausgeführt werden).
Legen Sie bei geöffneter Datei im Connector Configurator die
Connectoreigenschaften fest, und wählen Sie dann die Option "Speichern in
Projekt" aus, um die Konfiguration in System Manager zu speichern. Von
System Manager aus können Sie die neue Connectorkonfiguration in InterChange
Server implementieren. Dieser Vorgang ist im Handbuch
Implementation Guide for WebSphere InterChange Server
beschrieben.
- Anmerkung:
- Um sicherzustellen, dass die neuesten Eigenschaften für den Connector nach
dem Upgrade verwendet werden, lesen Sie die Angaben im entsprechenden
Adapterhandbuch nach.
So können Sie Ihre Connectors von einem WebSphere-Nachrichtenbroker
(entweder MQ Integrator, MQ Integrator Broker oder Business Integration
Message Broker) auf das Release 4.3 des InterChange Server-Systems
migrieren (einige Schritte müssen auf einer verbundenen Windows-Maschine
vorgenommen werden, auf der die Tools ausgeführt werden):
- Erstellen Sie mit dem Tool "System Manager" eine neue
Integrationskomponentenbibliothek.
- Überprüfen Sie mit dem Tool "Connector Configurator", ob alle in der
lokalen Konfiguration angegebenen Warteschlangen für InterChange Server gültig
sind.
- Führen Sie mit Connector Configurator Folgendes für jede
Connectordefinitionsdatei aus:
- Ändern Sie die Connectoreigenschaft DeliveryTransport von
"WebSphere Message Broker-JMS" in JMS.
- Ändern Sie die Eigenschaft RepositoryDirectory in
REMOTE.
- Nehmen Sie einen Upgrade der Connectoreigenschaften vor:
- Fügen Sie connectorspezifische Eigenschaften hinzu, oder entfernen Sie
sie. Um sicherzustellen, dass nach dem Upgrade die neuesten
connectorspezifischen Eigenschaften für den Connector verwendet werden, lesen
Sie die Angaben im zugehörigen Adapterhandbuch nach.
- Vergewissern Sie sich, dass alle entsprechenden Standardeigenschaften
einen Wert haben. Um sicherzustellen, dass nach dem Upgrade die neusten
Standardeigenschaften für den Connector verwendet werden, lesen Sie die
Angaben im Anhang mit den Standardeigenschaften des zugehörigen
Adapterhandbuchs nach.
- Speichern Sie die Connectordefinition in der
Integrationskomponentenbibliothek. Wählen Sie hierzu in Connector
Configurator die Option "Speichern in Projekt" aus.
- Nehmen Sie mit dem Tool "Business Object Designer" einen Upgrade der
Geschäftsobjektdefinitionsdateien (.xsd) vor, damit die
Informationen zur Ländereinstellung enthalten sind.
- Speichern Sie die Geschäftsobjektdefinition in der
Integrationskomponentenbibliothek. Wählen Sie hierzu in Business Object
Designer die Option "Speichern in Projekt" aus.
- Implementieren Sie die aktualisierte Connectorkonfiguration über System
Manager in InterChange Server. Dieser Vorgang ist im Handbuch
Implementation Guide for WebSphere InterChange Server
beschrieben.
Alle Startscripts von InterChange Server wurden geändert, damit die
Migration vom VisiBroker-ORB auf den IBM Java ORB ermöglicht wird.
Falls Sie Startscripts für Connectors einer Vorgängerversion von
4.2.2 geändert haben, müssen Sie an den neuen Startscripts
ebenfalls entsprechende Änderungen vornehmen.
Im Release 4.2.2 wurde eine Struktur für die
Startscripts eingeführt, die im Wesentlichen in den folgenden Punkten geändert
wurde:
- Alle Systemumgebungsvariablen sind neu und 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. Weitere Informationen zur Datei
CWSharedEnv.sh enthält das Handbuch System
Administration Guide.
- Zum Starten eines Connectors verwenden Sie das Startscript
start_connectorname.sh, das die
connectorspezifischen Informationen enthält. Dieses Script
start_connectorname.sh ruft wiederum die Datei
start_adapter.sh auf, die die allgemeinen Einstellungen für
alle Connectors enthält. Sie konfiguriert die Adapterumgebung und ruft
den Connector auf.
- Anmerkung:
- Die meisten von IBM gelieferten Adapter verwenden diese neue Struktur noch
nicht für ihre Startscripts. Die Startscripts dieser von IBM
gelieferten Adapter müssen nicht geändert werden. Sie sollten nur die
Startscripts für angepasste Adapter ändern.
Falls Sie in einem Vorgängerrelease von 4.2.2
Connectorstartscripts angepasst haben, sollten Sie diese Scripts erneut
untersuchen und sicherstellen, dass die Anpassungen in dieser neuen Struktur
der Startscripts, die auch durch Version 4.3 verwendet wird, in der
korrekten Datei angegeben sind.
- Anmerkung:
- Vergewissern Sie sich, dass in den Connectorstartscripts die Dateien
.jar in den Variablen CLASSPATH (oder JCLASSES) für alle
angepassten Datenhandler enthalten sind, die vom Connector verwendet
werden. Achten Sie insbesondere auf die Reihenfolge, in der die
Datenhandler in der Variablen CLASSPATH aufgelistet sind. Falls Sie
z. B. den XML-Datenhandler verwenden, achten Sie darauf, dass
die Datei CwXMLDataHandler.jar vor der Datei
CwDataHandler.jar angegeben ist. Beide dieser Dateien
.jar enthalten eine Datei xml.class, und
es muss sichergestellt sein, dass die in
CwXMLDataHandler.jar enthaltene Datei aufgerufen
wird.
Nachdem Sie alle Connectoränderungen oder -Upgrades vorgenommen haben,
müssen Sie sicherstellen, dass der Connector für die neue Umgebung korrekt
konfiguriert ist. Gehen Sie hierzu folgendermaßen vor:
- Prüfen Sie, ob der Connector den richtigen Benutzernamen und das richtige
Kennwort (sofern es geändert wurde) hat und ob er auf das korrekte System
zeigt.
- Prüfen Sie, ob jeder Connector auf die entsprechende Anwendung zeigt und
die geeigneten Einstellungen verwendet. Hierzu nehmen Sie einen Test
mit dem Datenbankverwaltungstool oder der Anwendung vor.
Sie müssen einen Upgrade der Zugriffsclients vornehmen, damit diese mit dem
IBM Java ORB (bzw. einer anderen gewünschten ORB-Implementierung, die
mit CORBA 2.3 kompatibel ist) verwendet werden kann. Der
ORB-Hersteller kann Ihnen mitteilen, ob der ORB mit CORBA 2.3
kompatibel ist. Im weiteren Verlauf dieses Abschnitts wird davon
ausgegangen, dass Sie mit dem IBM Java ORB arbeiten.
So führen Sie einen Upgrade eines Zugriffsclients, der gegenwärtig den
VisiBroker-ORB verwendet, auf die Verwendung des IBM Java ORB aus:
- Die frühere Version der Datei für den Interoperabilitätsobjektverweis
(.ior), die mit dem VisiBroker-ORB generiert und auf die
Maschine mit dem Zugriffsclient kopiert wurde, muss durch eine Datei
.ior ersetzt werden, die der IBM Java ORB nach dem Start von
InterChange Server generiert.
- Die Datei AccessInterfaces.idl muss mit dem Compiler
idlj erneut kompiliert werden. Verwenden Sie den Compiler
idlj, der auf der JDK-CD bereitgestellt wird.
- Anmerkung:
- Falls Sie das JDK von Sun oder HP heruntergeladen haben, ist der enthaltene
Compiler idlj möglicherweise nicht mit dem IBM ORB
kompatibel. Verwenden Sie den Compiler idlj, der auf der
JDK-CD bereitgestellt wird.
- Der Code im Zugriffsclient muss den IBM ORB anstelle des VisiBroker-ORB
initialisieren. Beispielsweise müssen in dem Codeausschnitt, der aus
dem Servletbeispiel des Handbuchs Access Development Guide stammt,
zwei CORBA-Initialisierungseigenschaften geändert werden, damit die Verwendung
des IBM ORB anstelle des VisiBroker-ORB wiedergegeben wird. Dies wird
im Folgenden veranschaulicht (Änderungen sind durch Fettschrift
gekennzeichnet):
Properties orbProperties=new java.util.Properties();
orbProperties.setProperty("org.omg.CORBA.ORBClass",
"com.inprise.vbroker.orb.ORB");
orbProperties.setProperty("org.omg.CORBA.ORBSingletonClass",
"com.inprise.vbroker.orb.ORBSingleton");
org.omg.CORBA.ORB orb =
org.omg.CORBA.ORB.init((String[])null, orbProperties);
Nach einer korrekten Aktualisierung sieht der Code für den Clientzugriff
wie folgt aus:
Properties orbProperties=new java.util.Properties();
orbProperties.setProperty("org.omg.CORBA.ORBClass",
"com.ibm.CORBA.iiop.ORB");
orbProperties.setProperty("org.omg.CORBA.ORBSingletonClass",
"com.ibm.rmi.corba.ORBSingleton");
org.omg.CORBA.ORB orb =
org.omg.CORBA.ORB.init((String[])null,orbProperties);
Falls der Zugriffsclient aus einem Servlet heraus verwendet wird, ist der
IBM ORB in der Laufzeit von WebSphere Application Server enthalten.
Daher sind die folgenden Änderungen erforderlich:
- Entfernen Sie alle Verweise auf VisiBroker-Dateien
.jar aus dem Klassenpfad.
- Kompilieren Sie die Datei AccessInterfaces.idl wie oben
beschrieben erneut.
- Stellen Sie sicher, dass der Servlet-Code nicht den VisiBroker-ORB,
sondern den IBM ORB initialisiert (siehe oben).
Wenn WebSphere Access for EJB verwendet wird, ist der IBM Java ORB in der
Laufzeit von WebSphere Application Server enthalten. In diesem Fall
müssen zur Änderung lediglich die Verweise auf VisiBroker-Dateien
.jar aus dem Klassenpfad entfernt werden, weil die JAR-Datei
von Access for EJB alle anderen erforderlichen Artefakte wie beispielsweise
die kompilierte IDL und die Session-Bean enthält.
Falls Sie weitere Komponenten erstellt haben, die angepasste Dateien
.jar enthalten (z. B. Datenhandler), müssen
Sie die angepassten Dateien .jar in die entsprechende
Position der neuen Verzeichnisstruktur kopieren. Normalerweise befinden
sich angepasste Dateien .jar im Unterverzeichnis
lib des Produktverzeichnisses.
- Anmerkung:
- Sie müssen außerdem sicherstellen, dass diese angepassten Dateien
.jar in den entsprechenden Startscripts aufgeführt
sind. Weitere Informationen finden Sie unter Upgrade der Serverstartscripts vornehmen.
Aufgrund interner Datenstrukturänderungen im SNMP-Agenten für das
Release 4.3 wird die alte Statusdatei (sts) nicht mehr erkannt.
Die Statusdatei enthält Informationen zu den Community-Namen des Agenten (die
wie Kennwörter eingesetzt werden), zu Zielen für die Trap-Weiterleitung, zu
ICS-Zielverbindungen sowie zum
Benutzernamen und zum Kennwort für die RBAC-Sicherheit. Nach dem
Upgrade auf den SNMP-Agenten des Release 4.3 müssen Sie den
SNMP-Konfigurationsmanager ausführen und die Informationen, die zuvor in der
Statusdatei gespeichert waren, erneut eingeben.
Außerdem müssen Sie die jeweils mit dem SNMP-Agenten verwendete
Verwaltungskonsole manuell rekonfigurieren, da sich die MIB-Datei
ändert. Anhand der MIB-Datei ermittelt die Verwaltungskonsole, welche
Arten von Informationen durch den SNMP-Agenten bereitgestellt werden.
Diese Datei wurde im Release 4.3 geändert. Daher müssen
Benutzer, die den neuen SNMP-Agenten verwenden, die neue MIB-Datei in ihre
Verwaltungskonsole laden.
- Anmerkung:
- Da das Format der Konfigurationsdatei gleich geblieben ist, sich der
Name der Datei jedoch von cwsnmpagent.cfg in
wbi_snmpagent.cfg geändert hat, wird dringend empfohlen, mit
dem SNMP-Konfigurationsassistenten eine neue Version zu erstellen. Dies
muss unbedingt vor dem Starten des SNMP-Agenten erfolgen.
Wenn Sie System Monitor verwenden, werden vorhandene Sichten und
Überwachungen so migriert, dass sie mit der ICS-Version 4.3 kompatibel
sind. Diese Migration erfolgt automatisch, sobald sich der Benutzer an
System Monitor anmeldet.
- 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 der InterChange Server-Version 4.1.1
müssen Sie Benutzerprojekte für Ihre ICS-Komponenten erstellen. Fahren
Sie mit den Anweisungen unter Projekte erstellen fort.
- Wenn Sie einen Upgrade ausgehend von Version 4.2.0,
4.2.1 oder 4.2.2 von InterChange Server ausführen
und vorhandene Benutzerprojekte exportiert haben (siehe Vorhandene Projekte migrieren), führen Sie die Schritte unter Vorhandene Projekte importieren aus, um alle vorhandenen Benutzerprojekte
zu importieren. Waren noch keine Projekte vorhanden, können Sie die
Schritte im Abschnitt Projekte erstellen ausführen.
Falls Sie Ihre vorhandenen Benutzerprojekte exportiert hatten, können Sie
sie importieren, sobald ICS aktiv ist. Stellen Sie eine Verbindung von
System Manager (ausgeführt auf einer verbundenen Windows-Maschine) zu Ihrer
ICS-Instanz her, und gehen Sie folgendermaßen vor:
- Erweitern Sie den Ordner "Benutzerprojekte", klicken Sie mit der rechten
Maustaste auf "InterChange Server - Projekte", und wählen Sie die Option
"Lösung importieren" aus.
- Wählen Sie die Ordnerposition aus, die Sie beim Export aus der
Vorgängerversion von 4.3 erstellt haben.
- Prüfen Sie, ob alle Benutzerprojekte erfolgreich importiert worden
sind.
Es empfiehlt sich, für jede Schnittstelle ein Projekt sowie ein separates
Projekt für allgemeine Komponenten (z. b. Metaobjekte und
Connectors) zu erstellen. Stellen Sie eine Verbindung von System
Manager (ausgeführt auf einer verbundenen Windows-Maschine) zu Ihrer
ICS-Instanz her, und gehen Sie folgendermaßen vor:
- Klicken Sie mit der rechten Maustaste auf "Benutzerprojekte", und wählen
Sie die Option "Neues Benutzerprojekt" aus.
- Ordnen Sie dem Benutzerprojekt einen Namen zu. Dieser Name sollte
die Schnittstelle eindeutig kennzeichnen.
- Anmerkung:
- Der Name eines Benutzerprojektes kann nicht mit dem Namen eines vorhandenen
Benutzerprojekts oder eines vorhandenen ICL-Projekts identisch sein.
- Wählen Sie die Komponenten für das Benutzerprojekt aus. Bei diesem
Schritt wird für jede erforderliche Komponente ein Direktaufruf
erstellt. Die Komponenten selbst verbleiben in der ICL.
Weitere Informationen zur Erstellung von Projekten finden Sie im Handbuch
Implementation Guide for WebSphere InterChange Server.
- 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 der InterChange Server-Version 4.1.1
führen Sie die Schritte in diesem Abschnitt aus, um ihre bereits vorhandenen
ICS-Komponenten im neuen Repository zu implementieren.
- Bei einem Upgrade ausgehend von den InterChange Server-Versionen
4.2.0, 4.2.1 oder 4.2.2 müssen Sie
Collaborationschablonen oder Zuordnungen nur dann implementieren, wenn Sie die
Klassendateien geändert haben (siehe Upgrade von Klassendateien von Komponenten vornehmen). Zur Implementierung von Collaborationschablonen
oder Zuordnungen führen Sie die Schritte in diesem Abschnitt aus.
Fahren Sie andernfalls mit den Anweisungen unter Upgrade prüfen fort.
Sobald die ICL und die Benutzerprojekte auf einer verbundenen
Windows-Maschine in System Manager definiert worden sind, können Sie die
Komponenten im InterChange Server-Repository auf der UNIX-Maschine
implementieren. Falls Sie keine Änderungen an den ICS-Komponenten
vorgenommen haben, müssen außer Zuordnungen und Collaborationschablonen keine
anderen Komponenten erneut implementiert werden.
Gehen Sie bei einer bestehenden Verbindung von System Manager zur
ICS-Instanz folgendermaßen vor:
- Klicken Sie mit der rechten Maustaste auf das Benutzerprojekt, und wählen
Sie die Option "Benutzerprojekt implementieren" aus.
- Wählen Sie in der Dropdown-Liste der registrierten und verbundenen
ICS-Instanzen die ICS-Zielinstanz für die Implementierung aus.
- Stoppen Sie InterChange Server, und führen Sie einen Neustart aus.
Ausführliche Angaben zur Implementierung von Komponenten auf dem Server
enthält das Handbuch Implementation Guide for WebSphere InterChange
Server.
