Key Visual - Manage Your Business Integration
 

Dez

12

Ein Serverumzug mit IBM Sterling Connect:Direct

By Christopher Pohl on Th, Dec/12/2013 : 13:59

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.



Margin
Blog-Autor
Christopher Pohl
Christopher Pohl
System Engineer
+49 221 97343-0
Margin
Informationen
7.0.1  7.0.2  8.0  Absatzmarkt  Active MQ  Active  Administration  Agile Lösungen  Agility  AMS  Analyst  Analytics  Anbindung  Anforderungen  Anwenderkonfernz  Apache  Application Server  API Management  API  AS2  ASP  Automatisierung  b2b  B2B Integration  Basic  Big Data  Blogreihe  Bluemix  Blueworks  BPM  Broker  BRMS  Bus  Business Process Management  Business Rules  Buzzword  Camel  Cast Iron  Cloud API  Cloud Computing  Cloud Integration  Cloud  Commerce  Compliance  Conference  Connect:Direct  CPLEX  CXF  DataPower  Decision Server Insights  Deployer  Deployment  Development  DFDL  Digitalisierte Prozesse  Digitalisierung  Domino  DSI  e-Fachverfahren  ersteinrichtung  Edi  Edition  Einführung  Einsatz  Entscheidung  Entwicklung  ESB  Excel  Fahrplanoptimierung  Features  Federated Connectivity  File Transfer  Filetransfer  Finance  FTE  gentran  gis  Geschäftsprozesse  Go Live  Google  Governance  Hardware ESB  Hosting  Hybrid-Cloud  Hybrid Cloud  Hybrid  IBM Blueworks  IBM BPM  IBM Integration Bus  IBM InterConnect  IBM  ILOG DOC  ILOG LNP  ILOG Transportation Analyst  ILOG  Impact  Infrastruktur  Installation  Integration as a Service  Integration Bus  Integration  Integrator  Interoperabilität  IT-Business-Alignment  Konfiguration  Linear  LNP  Logistik  monitoring  M2M  Manage File Transfer  Management  Marktplatz  Mathematik  Mediation  Message Broker  Messages  Messagesight  Messaging  MFT  Migration  Modellierung  MQ  MQTT  Multicast  Muster  Nachlese  Neuerungen in V7.0.1  Neuerungen  off-premise  on-premise  ODM  ODME  Öffentliche Verwaltung  Open Source  Operational Decision Management  Optimierung  OPL  OSGi  Outsourcing  PaaS  Pattern Integration  Pattern  Patterns  Performance  Portfolio  Praxis  Private  Process Server  Produktionsplanung  Prozessautomatisierung  Prozessintegration  Prozessmodelierung  Prozessoptimierung  PureSystem  Qualität  Real Time  Regelmanagement  Rollen  Routenplanung  Routing  ROI  SaaS API  SaaS Integration  SaaS  Salesforce  Schwerpunktanalyse  Script  SCM  Security  Service Federation Management  Servicemix  SFM  SI  Slotting  SoapUI  SOA Cloud Symposium  SOA  SPSS  Standard  Standardplattform  Standardtool  Standortoptimierung  Sterling Integrator  Sterling  SugarCRM  Symposium  Template  TIP  TM1  TOSCA  Transportation  Transportoptimierung  Übersicht  Umstieg  Unix  Update  vergleich  Vorteile  worklight  workload  wtc  Wartung  Websphere  Websphere: Rollen  WebService Security  WebSphere Enterprise Service Bus  WebSphere ESB  WebSphere MessageBroker  WebSphere Technical Conference  WebSphere  WESB  Workloads  WODM  XAR