Mit tFileFetch kann man in seinen ETL-Prozessen auf beliebige HTTP-Server zugreifen, entweder um Dateien herunterzuladen, oder Daten zu übermitteln. Auch der Upload von Dateien ist dabei möglich. Ausserdem bietet tFileFetch auch den lesenden Zugriff auf Dateien auf einem FTP- sowie auf einem Samba (SMB)-Server. FTP und SMB-Zugriff werde ich jedoch in diesem Beitrag außenvorlassen.

Die Komponente tFileFetch, deren Name zugegebenermaßen nicht unbedingt auf die ganze dahinterliegende Funktionalität schließen lässt, befindet sich im Bereich Internet der Komponenten-Palette.

Wenn das Protokoll http ausgewählt ist, kann man zum einen Dateien und Seiten aus Talend herunterladen und zum anderen auch HTML-Formulare ausfüllen, ja sogar Dateien hochladen.

Im Feld URI muss man dazu die vollständige Adresse samt Protokoll (also http://) angeben. Das Destination Directory sollte auf das Verzeichnis zeigen, in dem das Ergebnis des Aufrufs abgelegt werden soll. Je nachdem, ob man nun eine Datei herunterlädt, eine Seite aufruft oder ein Formular abschickt, wird das Ergebnis des Aufrufs dort unter dem entsprechenden Namen abgelegt (also bei http://www.meinserver.de/xyz/index.html als index.html).
Möchte man dies nicht, so kann man im Feld Destination Filename auch einen eigenen Namen explizit vergeben.

Beim Zugriff auf HTTP-Server werden für das Öffnen eines Dokuments normalerweise die Methode GET und beim Versenden von Formulardaten die Methode POST verwenden. Auch wenn es noch weitere Zugriffsmethoden (wie z.B. PUT oder DELETE) gibt, werden diese von tFileFetch nicht unterstützt. Der Zugriff über GET bedingt, dass evtl. zu übertragende Formulardaten in der URL übergeben werden. Daher ist der Upload von Dateien nur mit POST möglich. Auch ist die Anzahl der Zeichen, die in einer URL enthalten sein dürfen auf unter 4000 beschränkt. Aus diesem Grund ist standardmäßig die Checkbox POST method aktiviert. Möchte man keine Formulardaten an den Server übermitteln, empfiehlt es sich daher, diese Checkbox abzuwählen.

In der Tabelle Parameters können die einzelnen Formularfelder in Form von Key-Value-Paaren ausgefüllt werden. Für jedes Feld fügt man einfach mit dem grünen Plus eine neue Zeile in der Tabelle hinzu. Die Spalte Name muss den Feldbezeichner enthalten während in Value der zu übertragende Wert eingetragen wird.

Möchte man Dateien mit dem Formular hochladen, so muss dies im Reiter Advanced settings eingerichtet werden. Hat man die Checkbox Upload ausgewählt, so erscheint darunter eine Tabelle. In dieser Tabelle trägt man nun wieder die Namen der File-Upload-Felder ein und unter File den absoluten Pfad zur Datei.

Beim Upload von Dateien ist es erforderlich, dass die Übertragungsmethode POST unter Basic settings aktiviert ist.

Ist beim Zugriff auf die angegebene URI eine HTTP-Authentifizierung erforderlich, so kann man die entsprechende Checkbox anwählen und dann den Benutzernamen und das Passwort angeben.

Seit der Version 3.2 von Talend Open Studio und Talend Integration Suite lassen sich Proxy-Einstellungen job-weit mit der Komponente tSetProxy einrichten, daher verzichte ich auf die Beschreibung der Proxy-Settings in tFileFetch.

Beim Zugriff auf einen Server kann natürlich auch einmal ein unerwünschter Zustand eintreten, wie z.B. eine Überlastung oder Downtime des Servers. Damit der Talend-Prozess dann nicht endlos wartet, bis seine Anfrage beantwortet wird, gibt es das Feld Timeout. Hier kann man die maximale Zeit, die die Komponente geduldig auf Response wartet, in Millisekunden angeben.

In diesem Beispielszenario wird ein Formular per POST an eine URL geschickt und, mit den per File-Upload übermittelten Transaktionen, aus der Datei transaktionen_2009_11.csv, eine CSV-Datei erzeugt. Diese wird als Ergebnis des Aufrufs im Verzeichnis /var/temp/result/ als umsaetze.csv abgelegt.

Da es sich bei dieser URL um einen geschützten Bereich auf dem Web-Server handelt, werden der Benutzername und das Passwort für die Authentifizierung mit übertragen. War der Aufruf erfolgreich, so werden die heruntergeladenen Daten mit der Komponente tFileInputDelimited eingelesen und mit tMysqlOutput in die Zieltabelle einer MySQL-Datenbank übertragen.

Aber auch eine Spam-Maschine lässt sich mit dieser Komponente relativ schnell und unkompliziert erstellen. Nur wie das geht werde ich hier sicherlich nicht vormachen.

Possibly related posts: (automatically generated)

• Related posts on komponente
• Hirnfasching.de» Blogarchiv » Neues aus den Niederlanden
• Alexander Ambronn » Coaching bei Umstrukturierungen stoppt …
• Rolf.Aschenbeck » Blog Archiv » Riesterrente rechnet sich nicht

• Related posts on Talend
• BonitaSoft announces OEM partnership with eXo Platform
• Behind the Scenes with Bonita #3 (9 November -> 15 November 2009 …

• Related posts on Tutorial
• Flash As3 Scrollpane Component Tutorial: Scrolling Custom …
• Hd Tutorial: Itunes 9 Account – No Credit Card | MortgageRatesAholic

Beim Design von Datenintegrationsprozessen macht man sich oftmals viele Gedanken im Vorfeld. So werden Schwächen in der Datenqualität meist schon vorab ermittelt (z.B. mit Talend Open Profiler) und dann im ETL-Prozess eine entsprechende Optimierung umgesetzt.

Auch zur Laufzeit auftretende Fehler, wie der Klassiker, die NullPointer-Exception werden bereits berücksichtigt und z.B. mit tSchemaComplianceCheck verhindert. Aber eine Prüfung auf Verfügbarkeit eines entfernten Rechners (z.B. dem Datenbank- oder dem FTP-Server) wird eher selten explizit vorgenommen. Meistens laufen die entsprechenden Komponenten dann eben in eine entsprechende Exception und der Prozess wird (durchaus auch kontrolliert) beendet.

Dumm nur, wenn bis dahin schon andere System angezapft oder z.B. temporäre Dateien angelegt wurden. Viel Aufwand, der letztlich umsonst war und u.U. aber entsprechende Last verursacht hat.

Mit tServerAlive hat man die Chance, diese unnötige Last zu vermeiden. tServerAlive befindet sich in der Komponenten-Palette im Bereich Misc bzw. Verschiedenes. Die Komponente tServerAlive pingt ein entferntes System entweder über das Ping- oder das Telnet-Protokoll an.

Erhält tServerAlive im definierten Zeitraum (siehe das Feld Timeout) keine entsprechende Antwort vom Zielsystem, so ist das Ergebnis des Aufrufs false und wird in der globalMap abgelegt. Antwortet der angepingte Rechner hingegen, so schreibt tServerAlive true in die globalMap (z.B. tServerAlive_1_SERVER_ALIVE_RESULT).
Der Zugriff auf das Ergebnis erfolgt dann einfach via ((Boolean)globalMap.get(“tServerAlive_1_SERVER_ALIVE_RESULT”)).

Dieses Szenario pingt meinen Server an. Das Ergebnis des Ping-Versuchs wird mit Hilfe von tFixedFlowInput in einen künstlich generierten Datensatz übertragen.

Hier sieht man den vollständigen Zugriff auf das Ergebnis, in Form eines Boolean-Objekts (true/false), aus der globalMap.

Dieser Datensatz wird anschließend mit tLogRow auf die Konsole ausgegeben. Wie dieser Output dann aussieht, zeigt das Bild links.

Somit hat man ein einfaches Instrument an der Hand, um sicherzustellen, das entfernte Systeme, auf welche man in seinen ETL-Jobs zugreifen möchte, auch wirklich verfügbar sind.

Oder man programmiert sich mit tServerAlive und einer tInfiniteLoop einen Wächter, der einfach in regelmäßigen Intervallen prüft, ob noch alle Systeme laufen und ggfs. eine Status-EMail verschickt.

Possibly related posts: (automatically generated)

• Related posts on komponente
• Wir haben das Rauchverbot gelockert, so please stop smoking …
• In Israel wurde der Raketenabwehrschild der NATO geschmiedet und …
• Social Media – Spiegel der Gesellschaft « Totterturm

• Related posts on Talend
• BonitaSoft announces OEM partnership with eXo Platform
• Behind the Scenes with Bonita #3 (9 November -> 15 November 2009 …
• ETL – Talend

• Related posts on Tutorial
• Cabinetry Manufacturing Tutorial for Beginners | Fix My Cabinet
• Forex Basics: An Exchange Rates Tutorial
• Putting Your Website Online – Website Tutorial | Linghartz Agency …