Key Visual - Manage Your Business Integration
 

Sep

27

Best Practices für die Einarbeitung in Connect:Direct und Erfahrungen aus einem Kundenszenario

By Frederik Gierschner on Tu, Sep/27/2011 : 08:48

Anhand eines konkreten Szenarios stelle ich vor, wie eine Konfiguration aussehen kann und was bei der Einrichtung von Connect:Direct Clients und Servern zu berücksichtigen ist. Dieses Szeenario bezieht sich auf IBM Sterling Connect:Direct für UNIX.

Was ist bei der Installation zu beachten?

Bevor Connect:Direct genutzt werden kann, müssen die benötigten Komponenten installiert werden. Neben der Installation fällt für jeden Filetransfer Teilnehmer eine zusätzliche, initiale Konfiguration an, die etwas aufwendiger ist, als die Installation. Generell sollte man sich aber vor der Installation darüber Gedanken machen, welche Server miteinander über Connect:Direct kommunizieren sollen und in welche Richtung die zugeordneten Dateitransfers initiiert und durchgeführt werden. Hier haben sich ein Whiteboard und ein Interview mit den Applikationseignern vor Ort als gute Lösung erwiesen.

Für die Installation wird ein eigener User benötigt, der keine Superuser-Rechte hat. Es hat sich bewährt, dass man für Connect:Direct einen eigenen User mit Passwort anlegt. Um die Konfiguration erfolgreich zu beenden, wird allerdings das Superuser-Passwort benötigt. Connect:Direct nutzt standardmäßig zwei Ports. Der Port 1363 wird für Clientverbindungen genutzt, da er der API-Port ist. Der Port 1364 wird für Remotenode-Verbindungen genutzt. Dementsprechend muss zumindest der Port 1364 in Firewalls, bei netzwerkübergreifenden Kommunikationsszenarien, freigeschaltet werden. Dies ist ein häufiger Fehler, wegen dem keine Verbindung zu einer Remotenode hergestellt werden kann.

Während der Konfiguration ist zu beachten, dass man zuerst User von anderen Nodes auf einen lokalen User mappt, bevor man den lokalen User selber anlegt. Dieses Mapping muss ebenso auf den lokalen User durchgeführt werden. Er wird also auf sich selbst gemappt. Das klingt zuerst wenig plausibel, ist allerdings nur eine stringente Umsetzung des Benutzerrechtekonzepts.



Ob die Installation erfolgreich war, kann nun mittels des Sample-Prozess getestet werden, der von Connect:Direct generiert wurde. Öffnet man diesen Prozess mit einem Texteditor, zeigt sich, dass eine Datei von der lokalen Node wieder zur lokalen Node geschickt wird. Der Server fungiert also sowohl als P-, als auch als SNODE.

Als nächstes folgt die Erstellung eines eigenen Prozesses. Eine erste Hilfestellung bietet einem dabei der Sample Prozess. Zur Beschreibung komplexerer Prozesse, kann man auf das Customer Center zurückgreifen. Dort findet man zu vielen Funktionen ein Beispiel, dass man in seinen Prozess einbauen kann.

Abschließend muss man den File Agent noch installieren und konfigurieren. Dies geht ähnlich schnell, wie bei Connect:Direct selber. Da die Konfiguration über eine grafische Benutzeroberfläche erfolgt, wird ein X-Server benötigt. Möchte man nun einen Prozess aus dem File Agent heraus starten, ist es oft nötig Variablen an den Prozess zu übergeben, welche zum Beispiel den Pfad und den Dateinamen der gefundenen Datei beinhalten. Welche möglichen Übergabeparameter einem zur Verfügung stehen, lässt sich in der Dokumentation nachlesen.

Ein häufiger Fehler ist es, beim Kopierbefehl im Prozess den Pfad zur Datei nicht in Anführungszeichen zu schreiben. Übergibt nun der File Agent den Prozess an Connect:Direct, meldet der Server einen Syntaxfehler. Generell wird bei Fehlern eine Message-ID zurückgegeben, die einem bei der Fehlersuche behilflich ist. Alles in allem sind während der Installation die Dokumentation und das Customer Center wichtige Anlaufstellen.

Vorstellung des Kundenszenarios

Die Anforderungen des Kunden erforderten, dass beim Eintreffen einer Trigger-Datei eine andere Datei zu einer Remotenode kopiert wird. Sobald der Kopiervorgang erfolgreich abgeschlossen wäre, musste auf dem entfernten Server ein Script gestartet werden, welches die kopierte Datei verarbeitet. Die zu kopierende Datei heißt dabei immer gleich, hat aber eine Dateiendung, die inkrementiert wird (message.1, message.2, message.3, …).

Da nicht jede Datei kopiert werden sollte, hatte sich der Kunde bei seiner bisherigen Dateitransferlösung schon für eine Variante mit einer Trigger-Datei entschieden. Die Trigger-Datei hat dieselbe Dateiendung, trägt aber den Dateinamen „start“ (start.1, start.3, …). An die kopierte Datei sollte noch das Datum und die Uhrzeit gehangen werden, an dem sie zuletzt modifiziert wurden.

Programmablaufplan des Kundenszenarios

Vorgehen

Im File Agent werden zuerst die Verbindungsdaten zur Node und das Verzeichnis eingestellt, in welchem die Dateien später abgelegt werden. Ein Default Process ist nicht nötig.




Als nächstes wird eine Regel angelegt, die überprüft ob die gefundene Datei „start.“ beinhaltet. Dort wird auch der Prozess festgelegt, der aufgerufen wird, wenn die Rule zutrifft. Dem Prozess werden in der Zeile „Process arguments“ folgende Variablen mitgegeben:

  • &Sourcepath=%FA_PATH_FOUND. Pfad zu der Datei
  • &Extension=%FA_EXT_FOUND. Die Dateiendung; hier zum Beispiel .1
  • &Date=%FA_FDATE. Das Datum, an dem die Datei zuletzt modifiziert wurde
  • &Time=%FA_FTIME. Die Uhrzeit, zu der die Datei zuletzt modifiziert wurde


Der Connect:Direct Prozess FILES_TRIG.cd, der die Anforderungen aus dem Kundenszenario erfüllt:
FILES_TRIG process snode=geschaeftsnode

step01 copy
from
(
file = "&Sourcepathmessage&Ext"
pnode
)

ckpt = 2M
compress extended

to
(
file = "/home/verkaeufer/message&Ext_&Date_&Time"
snode
disp = rpl
)
step02 if (step01 lt 4) then
run job snode sysopts="/opt/VA/processFile
/home/verkaeufer/message&Ext_&Date_&Time"
eif
pend;

Um den File Agent zu starten, ruft man das cdfa Script auf, welches sich in dessen Installationsverzeichnis befindet. Mit dem Parameter -c ist es möglich zu bestimmen, welche Konfiguration zum Ausführen genutzt wird. Hier sollte man beachten, dass zwischen dem Parameter und dem Dateiname kein Leerzeichen stehen darf. Benutzt man diesen Parameter nicht, wird zuerst nach einer Konfiguration gesucht, die dem Computernamen entspricht, auf dem der File Agent läuft, und dann nach der Default Config.

Analysemöglichkeiten

Möchte man nun noch mehr Informationen zu Prozessen und Abläufen erhalten, gibt es mehrere Möglichkeiten, an diese zu gelangen. Einen Anlaufpunkt bieten die Logdateien von Connect:Direct, die man im Installationsverzeichnis unter work/nodename/ findet. Der File Agent hat ein separates Log, welches sich direkt in dessen Installationsverzeichnis befindet. Er lässt sich auch in einem Verbose-Modus starten, indem man an den cdfa-Befehl ein -v anhängt. Eine weitere Möglichkeit besteht darin, Statistiken über einen Client abzurufen. In dem CLI Client sind mögliche Befehle „sel stat pnum=2;“, beziehungsweisen „sel stat pnum=2 detail;“, wobei 2 die Nummer des Prozesses sein muss, von welchem man die Informationen benötigt. Hier bietet das IBM Sterling Control Center viele Vorteilen, da man gesammelt alle Informationen von mehreren Nodes an einer zentralen Stelle findet. Besonders bei großen Umgebungen, mit vielen Connect:Direct Servern, erleichtert es einem die Arbeit ungemein.

Fazit

Zusammenfassend lässt sich sagen, dass IBM Sterling Connect:Direct alle Anforderungen, die der Kunde gestellt hat, erfüllen konnte. Durch die vielen und ausführlichen Informationsquellen, wird einem die Fehlersuche bei möglichen Problemen erheblich erleichtert. Mittels einer guten Vorarbeit und ebenso guten Planung, konnten Schwierigkeiten vermieden werden, die bei der Einführung von Connect:Direct hätten auftreten können.


Margin
Blog-Autor
Frederik Gierschner
Frederik Gierschner
Software Engineer
+49 221 97343 121
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