Datum
12.12.2013
Dieser Beitrag wurde verfasst von:
Für einen Serverumzug kann es verschiedene Gründe geben – vielleicht haben sich die Performance-Anforderungen geändert, es wurde von Miet- auf eigene Server umgestellt oder es gab schlicht ein passenderes Angebot. Oft müssen bestehende Software und deren Funktionen bei der Umstellung migriert werden. Doch reicht es nicht aus, das alte System einfach zu kopieren oder seine Komponenten neu zu installieren. Sie müssen an die neue Umgebung angepasst werden. Um einen Überblick zu bekommen und den Aufwand besser einschätzen zu können, möchte ich Ihnen einige der wichtigsten Praktiken bei der Migration von IBM Sterling Connect:Direct vorstellen.
IBM Sterling Connect:Direct (C:D) benötigt zum Austausch von Dateien eine C:D-Serverinstanz auf jeder Seite, die an dem Austausch beteiligt ist. Diese Instanzen sind durch so genannte Nodes beschrieben, die Informationen über die Netzwerkumgebung beinhalten. Der Austausch selbst wird dabei durch C:D-Prozesse gestartet und reguliert, die wiederum die nötigen Informationen über die Herkunft der zu verwendenden Dateien, die einzelnen Arbeitsschritte und das Ziel der Datei beinhalten. Diese Prozesse können darüber hinaus über die API-Schnittstellen auch andere Programme und deren Funktionen ansprechen.
Klare Leitlinie: Die Worksheets
Die Installation von C:D auf dem neuen Server ist schnell erledigt. Die eigentliche Herausforderung besteht darin, die einzelnen Komponenten entsprechend zu konfigurieren. Dazu nutze ich gerne die Worksheets. Die Vorlagen in dem „Getting Started Guide“ aus der Dokumentation entsprechen dabei immer der Version von C:D und der vorgesehenen Plattform. Dadurch kann ich schnell und einfach die wichtigsten Informationen zusammentragen, was mir die Arbeit immens erleichtert.
Unter anderem füge ich hier die Informationen über die lokalen User oder die neue TCP/IP Adresse ein. Die Informationen über Remote-User und Remote-Nodes sowie Zielordner und andere relevante Parameter, die gleich geblieben sind, übernehme ich aus den alten Konfigurationsdateien.
Jetzt kann ich genau einschätzen, ob es mehr Aufwand bedeutet, die Informationen in die neue Konfigurationsdatei einzutragen oder die neuen Werte für die geänderten Parameter in der alten Konfigurationsdatei anzupassen und diese zu übernehmen.
Auch für die Prozesse lässt sich dieses Prozedere verwenden. Wir können die Informationen über den Aufbau und die Struktur der enthaltenen Statements aus den alten Prozessen entnehmen und in die neuen Prozesse übertragen, oder wir übernehmen die alten Prozesse und ändern diese entsprechend ab. Gleiches gilt für eventuelle Batch-Jobs und andere Skripte, die gegebenenfalls an die neue Umgebung angepasst werden müssen.
Durch das Zusammentragen der Informationen in die Worksheets kann ich mir also nicht nur die Arbeit erleichtern, sondern auch jede Menge Zeit einsparen.
Der Betrieb
Nun sind wir in der Lage dazu, IBM Sterling Connect:Direct in der neuen Umgebung wie gewohnt in Betrieb und die benötigten Prozesse wieder aufzunehmen. Damit diese nicht nur wie gewohnt gestartet, sondern auch ordentlich ausgeführt werden können, fehlt allerdings noch ein entscheidender Schritt:
Der Datenaustausch zwischen den einzelnen Sterling Connect:Direct Instanzen erfolgt über die bereits genannten Nodes. Damit diese untereinander Daten austauschen können, müssen sie sich gegenseitig „bekannt“ sein. Das bedeutet, dass jede Node Informationen über die Spezifikationen derjenigen Node braucht, zu der sie Daten senden oder von der sie Daten empfangen möchte.
Eine einfache Grafik verdeutlicht das Problem.
Zu den relevanten Spezifikationen gehören der Nodename, die TCP/IP-Adresse und die dazugehörigen Ports, über die eine Node erreichbar und eindeutig identifizierbar ist. Die Informationen über die Remote-Nodes, mit denen wir Daten austauschen möchten, haben wir bereits der alten Konfiguration entnommen.
Wenn die neue Node auf dem neuen Server den gleichen Namen und die gleiche IP-Adresse hat wie zuvor und dabei dieselben Ports benutzt werden können, wird diese auch von den Remote-Nodes wieder erkannt und die Verbindung kann wie gewohnt aufgenommen werden. Wenn sich jedoch einer dieser Parameter geändert hat, dann müssen diese Informationen zu den Konfigurationen der Remote-Nodes hinzugefügt werden. Gleiches gilt für die Angaben über Dateipfad und Dateinamen der zu übertragenden Daten sowie deren Zielverzeichnisse.
Dazu müssen wir alle Informationen über Änderungen in diesen Bereichen den Handelspartnern mitteilen, damit diese die Konfiguration ihrer C:D-Instanzen entsprechend anpassen.
Nachdem sichergestellt ist, dass alle nötigen Änderungen durchgeführt wurden, können die C:D-Prozesse, die den Austausch steuern, gestartet werden und die Daten werden wie gewohnt automatisch, sicher und effizient übertragen.
Dieses ist natürlich nur eine vereinfachte Darstellung der benötigten Schritte, aber ich hoffe, dass Sie einen Eindruck über den Umfang einer solchen Unternehmung bekommen konnten. Weitere Punkte und eine detailliertere Anleitung finden Sie im IBM Information Center. Wenn Sie hierzu Fragen haben oder wir Sie bei einem solchen oder ähnlichen Szenario unterstützen können, dann kommen Sie gerne auf uns zu: Wir freuen uns auf Ihre Herausforderung.
Autor
Wolfgang Schmidt