Talend „Job Design Patterns“ und Best Practices: Teil 4

Auf unserer langen „Talend Job Design Patterns und Best Practices“-Reise kommen wir jetzt an einen überaus interessanten Punkt. Aus meinem Vorhaben, ein paar nützliche Inhalte bereitzustellen, ist am Ende doch ein etwas umfangreicheres Projekt geworden. Der anhaltende Erfolg der vorherigen Blogeinträge dieser Reihe (bitte lesen Sie Teil 1, Teil 2 und Teil 3, falls noch nicht geschehen), die Technical Boot Camp-Präsentationen (vielen Dank an alle Teilnehmer) und die Bereitstellung dieses Materials für Kunden hat zu einer internen Transformationsanfrage geführt. So befinden sich etwa mehrere Webinare zu dieser Reihe in Planung, die wir in naher Zukunft veröffentlichen möchten. Bitte haben Sie aber noch etwas Geduld, da wir dafür Zeit und Ressourcen brauchen; das erste Webinar wird hoffentlich Anfang 2017 verfügbar sein. Ich freue mich auf jeden Fall sehr darauf – vor allem aber freue ich mich über das große Interesse meiner Leser.

Wie versprochen, schauen wir uns jetzt erst mal ein paar zusätzliche Best Practices für Talend Job Design Patterns an. Doch zunächst möchte ich Sie an eine einfache Tatsache erinnern, die oft übersehen wird: Weil Talend ein Java-Code-Generator ist, können wir durch die Erstellung von Entwicklungsleitlinien den Java-Code, der mittels Job Design Patterns generiert wird, stärken und optimieren. Es liegt auf der Hand: Gut konzipierte Jobs, die sauberen Java-Code generieren, indem Sie diese Konzepte für Ihre „Leinwand“ nutzen, bieten die besten Voraussetzungen, um gute Ergebnisse zu erzielen. Ich nenne das erfolgsorientierte Projekte.

Erfolgsorientierte Talend-Projekte

Die Erstellung von Talend-Jobs kann sehr einfach, aber auch sehr komplex sein. Das Geheimnis für eine erfolgreiche Implementierung liegt darin, sich gute Praktiken anzugewöhnen und diszipliniert umzusetzen.

Von den Grundregeln, die wir zu Beginn dieser Reihe besprochen haben, bis zum jetzigen Zeitpunkt, lag mein Ziel immer darin, eine offene Diskussion über diese Best Practices für solide, nützliche Job Design Patterns mit Talend anzuregen. Die meisten Anwendungsfälle profitieren von einem modularen Jobdesign und einer Parent-/Child-Orchestrierung und wenn Projekte genügend wiederverwendbaren Code enthalten, lässt der Erfolg nicht lange auf sich warten. Natürlich ist es gut, wenn Sie Ihren eigenen Weg gehen, aber achten Sie dabei immer auf Einheitlichkeit.

Database-Development-Life-Cycle – DDLC

Moment mal! Vielleicht geht es nicht nur um das Jobdesign; was ist mit den Daten? Wir verarbeiten doch Daten, oder? Daten sind meist in einer Datenbank gespeichert. Aber brauchen Datenbanken Best Practices? Eine rhetorische Frage? Datenmodelle (Schemata) ändern sich im Laufe der Zeit, daher müssen auch Datenbankdesigns einen Lebenszyklus haben! Macht Sinn, oder?

Wir Entwickler müssen uns darauf einstellen, dass sich Datenbanken ständig weiterentwickeln. Wir kommen gut mit unserem SDLC-Prozess zurecht, daher sollte es nicht so schwer sein zu akzeptieren, dass wir auch einen Database-Development-Life-Cycle benötigen. Für mich ist das eigentlich ganz simpel. Eine Datenbank muss für jede Umgebung (DEV/TEST/PROD) folgende Features unterstützen:

• Neuinstallation: basierend auf der aktuellen Version des Schemas
• Upgrade: Entfernen/Erstellen/Ändern von Datenbankobjekten durch ein Versionsupgrade
• Datenmigration: durch ein radikales „Upgrade“ (Teilen von Tabellen)

Es ist sehr wichtig, den Datenbanklebenszyklus und seine Auswirkungen auf Jobdesigns genau zu kennen. Die Versionierung Ihres Datenbankmodells ist entscheidend. Hierfür empfehle ich eine feste Abfolge. Veranschaulichen Sie die Designs mit Diagrammen. Erstellen Sie ein Datenwörterbuch oder ein Glossar und protokollieren Sie alle Änderungen. Ich werde in Kürze einen separaten ausführlichen Blogeintrag zu diesem Thema verfassen. Schauen Sie also wieder vorbei. Halten Sie sich in der Zwischenzeit an den folgenden Prozess bei der Erstellung von Datenbankmodellen. Man braucht dafür viel Disziplin, aber es funktioniert!

Weitere Best Practices für Jobdesigns

Also gut. Hier sind weitere Job Design Patterns und Best Practices, die Sie sofort nutzen und umsetzen können! Diese haben mehr mit Talend-Features zu tun, die Sie möglicherweise kennen oder vielleicht auch seltener verwenden. Jedenfalls hoffe ich, dass Sie sie nützlich finden.

8 weitere Best Practices:

tMap-Lookups

Wie viele von Ihnen bereits wissen, wird die grundlegende tMap-Komponente umfassend in Talend-Jobs verwendet. Das liegt an ihren leistungsstarken Transformationsfunktionen.

Der häufigste Verwendungszweck der tMap-Komponente ist das Mappen eines Datenflussschemas aus einem Quellinput in ein Zieloutput. Ganz einfach, oder? Das ist es wirklich! Wir können auch mehrere Quell- und Zielschema-Datenflüsse integrieren, was uns vielfältige Optionen eröffnet, um diese Datenflüsse je nach Bedarf zusammenzuführen und/oder zu teilen. Dabei können wir auch Transformationsausdrücke integrieren, die bestimmen, welche eingehenden Daten nachfolgend verteilt werden und auf welche Weise dies geschieht. Ausdrücke innerhalb einer tMap-Komponente können im Quell- oder Zielschema vorkommen. Sie lassen sich auch mithilfe von Variablen anwenden, die in der tMap-Komponente definiert sind. Wie Sie all das machen, können Sie im Talend Components Reference Guide nachlesen. Denken Sie daran: Aus großer Kraft folgt große Verantwortung!

Eine weitere tolle Nutzungsmöglichkeit der tMap-Komponente ist die Integration von Lookups, die mit dem Quelldatenfluss verbunden sind. Es gibt zwar weder für die Anzahl an Lookups, die Sie für eine tMap-Komponente anwenden können, noch für den Umfang der Lookup-Daten eine physische Begrenzung – aber man sollte dennoch ein paar praktische Aspekte beachten.

Sehen wir uns dieses einfache Beispiel an: zwei Zeilengeneratoren, wobei einer davon die Quelle, der andere der Lookup ist. Zur Laufzeit erfolgt zuerst die Lookup-Daten-Generierung und dann werden die Quelldaten verarbeitet.

Weil der Join in den Lookup-Daten auf Load Once eingestellt ist, werden alle Datensätze in den Speicher geladen und dann auf Basis des Ergebnissatzes der Quelldaten verarbeitet. Dieses Standardverhalten ermöglicht leistungsstarke Joins und kann sehr effizient sein.

Stellen Sie sich vor, wie viel Speicher beim Hochladen von Millionen Lookup-Zeilen oder Dutzenden von Spalten nötig ist. Was passiert, wenn mehrere Lookups mit je mehreren Millionen Zeilen erforderlich sind? Wie viel Speicher wird dann benötigt? Wenn viele Datensätze oder Hunderte von Spalten im Spiel sind, sollten Sie unbedingt Ihre Lookups im Auge behalten.

Wir haben es hier mit einem klassischen Dilemma zu tun: Speicher oder Performance? Zur Verfügung stehen drei Lookup-Modelle:

• Load Once – liest alle qualifizierten Datensätze in den Speicher ein
• Reload at each Row – liest nur die qualifizierte Zeile für jeden Quelldatensatz ein
• Reload at each Row (cache) – liest nur die qualifizierte Zeile für jeden Quelldatensatz ein, wobei sie gecacht wird

Lookup-Daten, die zur Quelle in den Speicher geladen wurden, können ohne Frage ziemlich schnell sein. Wenn aber Speicherbegrenzungen enorme Mengen an Lookup-Daten verhindern oder wenn Sie einfach nicht ALLE Lookup-Daten laden möchten (da der Anwendungsfall dies nicht erfordert), nutzen Sie das Reload at each Row-Lookup-Modell. Zum Glück gibt es einen Trick, damit es funktioniert.

Ändern Sie als Erstes innerhalb der tMap-Komponente den Lookup-Modus zu Read at each Row. Der untere Bereich wird erweitert, sodass der Input des bzw. der Key(s) (Schlüssel) möglich ist, die Sie für den Lookup brauchen. Fügen Sie die Schlüssel hinzu, die effektiv die globalen Variablen definieren, die außerhalb der tMap-Komponente verfügbar sind.

Nutzen Sie für die Lookup-Komponente die (datatype)globalMap.get(“key”)-Funktion in der „WHERE“-Klausel Ihrer SQL-Syntax, um den gespeicherten Schlüsselwert anzuwenden, der in der tMap auf dem Lookup-Datensatz definiert ist. Dies schließt den Lookup-Abruf für jeden aus der Quelle verarbeiteten Datensatz ab.

Fertig – zwei effiziente Lookups!

Globale Variablen

Es gibt mehrere Definitionen und Nutzungsmöglichkeiten für Global Variables. Entwickler erstellen sie ganz häufig und nutzen sie in Talend-Jobs; wir bezeichnen sie als Context Variables. Manchmal sind diese integriert (Built-In) (lokal gespeicherter Job) und manchmal sind sie im Project Repository als Kontextgruppen zu finden, die über viele verschiedene Jobs hinweg wiederverwendet werden können.

So oder so, das sind alles Global Variables, deren Wert zur Laufzeit
bestimmt wird und die innerhalb des Jobs, der sie definiert, an jeder beliebigen Stelle genutzt werden können. Dass Sie globale Variablen nutzen, erkennen Sie daran, dass context.varname in einer Komponente, einem Ausdruck oder einem Trigger eingebettet ist. Vergessen Sie nicht, häufig genutzte Variablen in ein Reference Project einzufügen, damit sie über alle Projekte hinweg verfügbar sind.

Talend bietet auch tSetGlobalVar- und tGlobalVarLoad-Komponenten, die Global Variables zur Laufzeit definieren, speichern und nutzen können. Die tSetGlobalVar-Komponente speichert ein Key-Value-Paar innerhalb von Jobs; dies ist, als würde man eine Context Variable nutzen, bietet aber eine größere Kontrolle (wie Fehlerbehebung). Sehen Sie sich mein Beispiel an: Hier wird ein einziger MAX(date)-Wert abgerufen und dann in einer nachfolgenden SQL-Abfrage genutzt, um einen zweiten Datensatz-Abruf zu filtern.

Um auf die globale Variable zuzugreifen, nutzen Sie die (datatype)globalMap.get(“key”)-Funktion in der SQL-WHERE-Klausel. Machen Sie sich mit dieser Funktion vertraut – sobald Sie ihre Vorteile kennen, wird sie Ihnen ohne Zweifel ans Herz wachsen!

Die tGlobalVarLoad-Komponente bietet ähnliche Funktionen für Big-Data-Jobs, in denen die tSetGlobalVar-Komponente nicht verfügbar ist. Im folgenden Beispiel wird ein aggregierter Wert berechnet und anschließend in einem nachfolgenden Read-Prozess genutzt, um festzustellen, welche Datensätze zurückgespielt werden müssen.

Wir sind noch nicht ganz mit diesem Thema fertig. Gut erkennbar ist noch eine Reihe von System Global Variables, die innerhalb eines Jobs verfügbar sind, dessen Werte von den Komponenten selbst bestimmt werden. Wir haben bereits über eine davon gesprochen – im ersten Teil dieser Reihe, als es um Best Practices zur Fehlerbehebung ging: CHILD_RETURN_CODE und ERROR_MESSAGE. Diese System Global Variables können in der Regel unmittelbar genutzt werden, nachdem die Komponente deren Wert eingestellt hat. Je nach Komponente sind verschiedene Systemvariablen verfügbar. Hier ist eine (unvollständige) Liste:

• ERROR_MESSAGE / DIE_MESSAGE / WARN_MESSAGE
• CHILD_RETURN_CODE / DIE_CODE / WARN_CODE / CHILD_EXCEPTION_STACK
• NB_LINE / NB_LINE_OK / NB_LINE_REJECT
• NB_LINE_UPDATED / NB_LINE_INSERTED / NB_LINE_DELETED
• global.projectName / global.jobName (diese befinden sich auf Systemebene; zu deren Nutzung brauche ich wohl nichts zu sagen)

Laden von Kontext

Kontextgruppen unterstützen ein hochgradig wiederverwendbares Jobdesign. Es gibt allerdings Fälle, in denen wir mehr Flexibilität benötigen. Nehmen wir mal an, dass Sie die Standardwerte für die Kontextvariablen extern pflegen möchten. Manchmal ist es sinnvoller, sie in einer Datei oder sogar in einer Datenbank zu speichern. Die externe Pflege dieser Werte kann ziemlich effektiv und sicherheitstechnisch sogar von Vorteil sein. Genau hier kommt die tContextLoad-Komponente ins Spiel.

Das obere Beispiel zeigt eine einfache Möglichkeit, Ihren Job so zu konzipieren, dass Kontextvariablen zur Laufzeit initialisiert werden. Die externe Datei, die zum Laden verwendet wird, enthält durch Komma getrennte Key-Value-Paare und überschreibt beim Einlesen die aktuellen Werte für die definierten Kontextvariablen innerhalb des Jobs. In diesem Fall werden die Details der Datenbankverbindung geladen, um die gewünschte Verbindung sicherzustellen. Hier haben Sie etwas Kontrolle über die Fehlerbehebung; in der Tat lässt sich für den Job auch hier unmittelbar ein programmatischer Exit einrichten: Die on Error. Diese Gelegenheit bietet sich nicht sehr oft. Natürlich kann die tContextLoad-Komponente eine Datenbank-Abfrage genauso einfach nutzen und ich kenne einige Kunden, die das genauso machen.

Darüber hinaus gibt es eine entsprechende tContextDump-Komponente, die die aktuellen Werte der Kontextvariablen in eine Datei oder Datenbank schreibt. Das ist extrem praktisch, wenn man hochgradig anpassbare Jobdesigns erstellt.

Dynamische Schemata

Ich werde häufig gefragt, wie man Jobs erstellt, die mit dynamischen Schemata zurechtkommen. Das ist keine einfache Frage, da es verschiedene Anwendungsfälle mit dynamischen Schemata gibt. Beim häufigsten Fall geht es darum, die Daten aus einer großen Anzahl von Tabellen in andere Tabellen oder sogar in ein anderes Datenbanksystem zu verschieben (sagen wir mal von Oracle in den MS SQL Server). Ein Job zur Verlagerung dieser Daten lässt sich ganz einfach erstellen, aber einen Job für jede einzelne Tabelle zu generieren, ist alles andere als praktisch. Was ist, wenn es Hunderte Tabellen gibt? Können wir nicht einfach einen einzigen Job für ALLE Tabellen erstellen? Leider stößt Talend hier ein wenig an seine Grenzen. Aber kein Grund zur Panik: Wir können das mit ZWEI Jobs regeln: ein Job, um die Daten zu dumpen, und ein weiterer, um die Daten zu laden. Geht doch, oder?

Bei meinem Beispieljob werden drei Verbindungen hergestellt: die ersten beiden, um die TABELLEN- und SPALTEN-Listen abzurufen, und die dritte, um die eigentlichen Daten abzurufen. Durch eine einfache Iteration jeder Tabelle (wobei deren Spalten gespeichert werden) kann ich Daten auslesen und in einer positionellen Flatfile speichern (DUMP-Prozess). Dazu verwende ich einfach die tSetDynamicSchema-Komponente. Bei ähnlichen Jobs wird im Prinzip dasselbe gemacht, nur dass die dritte Verbindung die positionelle Datei ausliest und im Zieldatenspeicher schreibt (LOAD-Prozess).

In diesem Szenario müssen Entwickler das Innenleben ihrer Host-Datenbank einigermaßen verstehen. Die meisten Systeme wie Oracle, MS SQL Server und MySQL haben Systemtabellen, die oft als Informationsschemata bezeichnet werden und Objektmetadaten über eine Datenbank einschließlich Tabellen und deren Spalten enthalten. Hier ist eine Abfrage, die eine vollständige Tabellen-/Spaltenliste aus meiner TAC-v6.1-MySQL-Datenbank extrahiert (gefällt Ihnen meine Lieblings-SQL-Syntax-Formatierung?):

Nutzen Sie für die Verbindung unbedingt Anmeldedaten, die SELECT-Berechtigungen für diese normalerweise geschützte Datenbank haben.

Ich verwende die tJavaFlex-Komponente, um durch die gefundenen Tabellennamen zu iterieren. Dabei speichere ich jeden Tabellennamen und richte eine Control Break-Flag ein, dann führe ich eine Iteration für jede gefundene Tabelle durch und rufe die sortierte Spaltenliste ab. Nach Anpassung an eventuelle Nullen in den Spaltenlängen ist das gespeicherte dynamische Schema abgeschlossen. Die Bedingung „IF“ prüft die Control Break-Flag, wenn sich der Tabellenname ändert, und startet den Dump-Prozess für die aktuelle Tabelle. Voilà!

Dynamische SQL-Komponenten

Dynamischer Code ist einfach klasse! Talend bietet mehrere Möglichkeiten, ihn zu implementieren. Beim vorherigen Jobdesign habe ich einen direkten Ansatz für den Abruf der Tabellen- und Spaltenlisten aus einer Datenbank genutzt. Talend bietet hostsystemspezifische Komponenten, die dasselbe tun. Diese t{DB}TableList- und t{DB}ColumnList-Komponenten (wo {DB} durch den Namen der Hostkomponente ersetzt wird) bieten einen direkten Zugriff auf die Informationsschema-Metadaten, ohne dass man irgendetwas darüber wissen muss. Diese Komponenten statt des vorher beschriebenen DUMP-/LOAD-Prozesses zu nutzen, könnte genauso gut funktionieren – aber wo bleibt da der Spaß?

Nicht bei allen SQL-Abfragen müssen Daten abgerufen oder gespeichert werden. Manchmal sind andere Datenbankprozesse erforderlich. Nutzen Sie die Komponenten t{DB}Row und t{DB}SP für diese Anforderungen. Mit der ersten können Sie praktisch alle SQL-Abfragen ausführen, die keinen Ergebnissatz liefern, wie etwa DROP TABLE. Mit der zweiten können Sie eine Stored Procedure ausführen.

Last, but not least haben wir die t{DB}LastInsertId-Komponente. Diese ruft die zuletzt eingefügte ID aus einer Datenbank-Outputkomponente ab. Das ist gelegentlich ganz praktisch.

CDC

Eine weitere häufige Frage: Unterstützt Talend CDC bzw. „Change Data Capture“? Die Antwort ist ein klares JA, nämlich durch Publish-/Subscribe-Mechanismen, die direkt mit dem entsprechenden Hostdatenbanksystem verbunden sind. Dabei sollte man beachten, dass nicht alle Datenbanksysteme CDC unterstützen. Hier finden Sie eine aktuelle Liste zur CDC-Unterstützung in Talend-Jobs:

Es sind drei CDC-Modi verfügbar:

• Trigger (Default) – nutzt DB-Host-Trigger, die Inserts, Updates und Deletes nachverfolgen
• Redo/Archive Log – nur mit Oracle 11g und früheren Versionen möglich
• XStream – nur mit Oracle 12 und OCI möglich

Da Sie wahrscheinlich den Trigger-Modus nutzen, lassen Sie uns einen Blick auf seine Architektur werfen:

Der Talend User Guide (Kapitel 11) bietet umfassende Informationen zum CDC-Prozess, zur Konfiguration und zur Nutzung innerhalb von Studio und mit Ihrem Hostdatenbanksystem. Das mag vom Konzept her ganz einfach sein, aber der Setup-Aufwand ist deutlich größer. Sie müssen sich zuerst ein klares Bild über Ihre Anforderungen, CDC-Modi und Jobdesign-Parameter machen und diese strukturiert in Ihren Entwicklungsleitlinien dokumentieren!

Einmal eingerichtet, bietet die CDC-Umgebung einen robusten Mechanismus, um nachgelagerte Zielsysteme (gewöhnlich Data-Warehouses) aktuell zu halten. Nutzen Sie die t{DB}CDC-Komponenten innerhalb Ihrer Talend-Jobs, um Daten zu extrahieren, die sich seit der letzten Extraktion geändert haben. CDC erfordert zwar etwas Zeit und Aufwand für die Konfiguration und Operationalisierung, ist aber insgesamt ein sehr nützliches Feature!

Benutzerdefinierte Komponenten

Auch wenn Talend mittlerweile gut über 1.000 Komponenten bietet, gibt es immer noch viele Gründe, Ihre eigenen zu erstellen. Talend-Entwickler „verkapseln“ häufig spezialisierte Funktionen innerhalb einer benutzerdefinierten Komponente. Einige erstellen eigene Komponenten und vermarkten sie als Produkte, während andere sie frei zugänglich auf der vor kurzem modernisierten Talend Exchange-Plattform veröffentlichen. Wenn eine Komponente nicht auf der Talend-Palette verfügbar ist, suchen Sie dort danach, vielleicht finden Sie genau das, was Sie brauchen. Sie benötigen dafür ein Talend Forge-Konto, aber wahrscheinlich haben Sie bereits eins erstellt.

Stellen Sie zunächst sicher, dass das Verzeichnis, in dem benutzerdefinierte Komponenten gespeichert werden, richtig eingestellt ist. Gehen Sie dazu auf das Preferences-Menü und wählen Sie einen Speicherort aus, der für alle Entwickler nachvollziehbar ist. Klicken Sie auf Applyund dann auf OK.

Suchen Sie die Exchange-Verbindung in der Menüleiste (hier können Komponenten ausgewählt und installiert werden). Wählen Sie beim ersten Mal Always run in Background aus und klicken Sie dann auf die Schaltfläche Run in Background, da es etwas dauert, die lange Liste verfügbarer Objekte hochzuladen. Von dieser Liste aus können Sie die gewünschten Objekte anzeigen/herunterladen (View/Download). Nachdem Sie eine Komponente herunterladen, klicken Sie auf Downloaded Extensions, um sie zur Nutzung in Studio zu installieren. Nach Fertigstellung wird die Komponente als Installed angezeigt und ist ab sofort auf der Palette verfügbar.

Nach der Installation sind Komponenten und die dazugehörigen Dateien manchmal nicht so leicht zu finden. Schauen Sie am besten an diesen zwei Orten nach:

{talend}/studio/plugins/org.talend.designer.components.exchange{v}{talend}/studio/plugins/org.talend.designer.components.localprovider{v}

Wenn Sie eine benutzerdefinierte Komponente erstellen möchten, wechseln Sie auf die Component Designer-Ansicht in Studio. Die meisten benutzerdefinierten Komponenten verwenden JavaJet, die Dateierweiterung für die Kapselung von Java-Code für die Eclipse-IDE. Für Anfänger steht ein praktisches Tutorial zur Erstellung benutzerdefinierter Komponenten zur Verfügung (How to create a custom component). Es ist zwar nicht mehr das neueste (ca. 2013 veröffentlicht), umfasst aber alle wichtigen Grundlagen. Außerdem gibt es auch Tutorials von Drittanbietern (einige werden in unserem Tutorial genannt). Meine Empfehlung: Talend by Example: Custom Components. Noch mehr Informationen zur Erstellung von Custom Components finden Sie in Google.

JobScript-API

In der Regel nutzen wir den Designer, um unseren Talend-Job zu erstellen, der dann wiederum den zugrunde liegenden Java-Code generiert. Haben Sie sich je gefragt, ob sich Talend-Jobs auch automatisch erstellen lassen? Ja, das ist tatsächlich möglich! Öffnen Sie irgendeinen Ihrer Jobs. Unten im Canvas finden Sie drei Tabs: DESIGNER, CODE und JOBSCRIPT. Höchst interessant; wahrscheinlich haben Sie schon einmal auf den CODE-Tab geklickt, um den generierten Java-Code zu prüfen. Haben Sie auch mal auf den JOBSCRIPT-Tab geklickt? Wenn ja, wussten Sie überhaupt, worum es sich handelt? Die meisten von Ihnen wahrscheinlich nicht. Dieser Tab zeigt das Skript zum Jobdesign. Werfen Sie das nächste Mal einen genaueren Blick darauf. Kommt Ihnen etwas bekannt vor, das mit Ihrem Jobdesign zu tun hat? Bestimmt sogar ...

Sie denken sich vielleicht, was das soll! Lassen Sie mich etwas sagen: Ich nehme an, dass Sie Metadaten zu Ihrem Jobdesign erstellen und pflegen und über eine Prozess-Engine (die Sie erstellt haben) laufen lassen, um ein optimal formatiertes JobScript zu generieren; eventuell passen Sie wichtige Elemente an, um mehrere Permutationen des Jobs zu erstellen. Das ist wirklich interessant!

Im Projekt-Repository finden Sie im CODE>ROUTINES-Bereich den Job Scripts-Ordner. Erstellen Sie ein neues JobScript (ich nenne meins test_JobScript). Öffnen Sie einen Ihrer Jobs und kopieren Sie die JobScript-Tab-Inhalte, fügen Sie sie in die JobScript-Datei ein und speichern Sie diese. Klicken Sie mit der rechten Maustaste auf das JobScript und wählen Sie Generate Job. Schauen Sie jetzt im Job Designs-Ordner nach – dort finden Sie einen frischgebackenen Job. Stellen Sie sich vor, was Sie jetzt alles machen können! Nicht schlecht, oder?

Fazit

Puh, das wärs dann wohl! Nicht, dass es keine weiteren Best Practices für die Erstellung und Pflege von Talend-Jobdesigns gibt; ich bin mir ziemlich sicher, dass es noch viele andere gibt. Fürs Erste möchte ich es aber bei interessanten Community-Gespräche belassen – ich denke, wir sind uns alle einig, dass diese Sammlung (insgesamt 32) mehr als genug für erfolgsorientierte Projekte mit Talend bietet.

Freuen Sie sich auf meinen nächsten Blogeintrag in dieser Reihe: Wir werden ein wenig das Thema wechseln und darüber reden, wie wir all diese Best Practices in einem konventionellen Anwendungsfall nutzen können. Es geht um angewandte Technologien, robuste Methoden und ergebnisorientierte Lösungen! Die Basis, um diese Best Practices und Job Design Patterns zu nutzen. Bis zum nächsten Mal!