Best Practices für die Einarbeitung in Connect:Direct

    und Erfahrungen aus einem Kundenszenario (Wissensbeitrag)

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

    Programmiercode auf einem Rechner

    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.

    Welchen Unterschied machten diese Informationen und Eindrücke?

    • Die Erfahrungswerte der Kundenprojekte halfen in den letzen Wochen in der Bewertung einer Kundensituation zum Thema Business Process Management.
    • Die Integration von ILOGs Businnes Rules Management System (neben den Optimization Tools und Supply Chain Management  Lösungen) stellen einen guten Erweiterungsansatz für einen Kunden und dessen WebSphere Middleware dar – um dessen Fachbereich, die wahren Prozessinhaber, die automatisierten Abläufe dynamisch und flexibel anpassen zu lassen.
    • Zudem wurden die Neuerungen oder deren Vorabversionen als Patches im Betrieb eines Kunden genutzt und
    • natürlich die persönlichen Kontakte zu den Entwicklern in de nweltweiten IBM Labors im Nachgang intensiviert.

    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.

    Arbeit am Laptop

    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
    Analysemöglichkeiten

    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.

    Autor

    Wolfgang Schmidt
    GeschäftsführerX-INTEGRATE Software & Consulting GmbHKontakt