Architektur ist in ETL-Umgebungen extrem wichtig, um eine leistungsfähige und erweiterbare Verarbeitungsumgebung für die Data Warehouse-Prozesse zu schaffen. Die Gedanken und die Zeit, die man in die Architektur vorab investiert, zahlen sich – meiner Erfahrung nach – mehrfach aus. Dies gilt sowohl für die globale ETL-Architektur als auch im Kleinen bei einzelnen ETL-Jobs. Wiederverwendbarkeit und generische Ansätze seien hier mal als Stichpunkte genannt und dazu gehört auch ein sinnvoller Einsatz von Parametern. In DataStage existieren dazu mehrere Möglichkeiten, angefangen von globalen Parametern, wie auch lokalen Parametern bis hin zu Parameter Sets. Um eben diese soll es in diesem Blogartikel gehen.
Ein Parameter Set ist eine Gruppierung von Parametern, um es einmal einfach zusammenzufassen. Diese Gruppierung macht besonders dann Sinn, wenn die Parameter korreliert sind. Ein gutes Beispiel dafür sind die Verbindungsdaten zu einer Datenbank: Der Datenbankname, die User ID und das Passwort sind korreliert und werden immer in Kombination benötigt, um eine erfolgreiche Verbindung zu definieren. Dies kann dann auch noch mit Schemanamen etc. ergänzt werden.
Wo liegt der Vorteil?
Dieses Parameter Set ist ein DataStage Objekt und kann so als Ganzes einem Job zugeordnet werden. Statt vier einzelne Parameter kann das Parameter Set in einem Schritt zugeordnet werden. Aber nicht nur das, auch beim Jobstart kann man eine gültige Wertekombination in einem Schritt auswählen (sofern diese vordefiniert wurde). Das verhindert Flüchtigkeitsfehler, indem man evtl. einen falschen User für die konkrete Datenbankverbindung auswählt.
Apropos vordefiniert – auch das ist ein wesentlicher Vorteil von Parameter Sets, denn es lassen sich verschiedene Werte-Kombinationen vorab hinterlegen und einem Namen zuordnen. Dieser kann dann beim Aufruf gewählt werden und es werden automatisch die unter diesem Namen vordefinierten Werte eingetragen.
Unser Tipp: In der Projektstruktur im Designer ist standardmäßig kein vordefinierter Platz für Parameter Sets vorgesehen. Es empfiehlt sich einen Ordner ParameterSets anzulegen, damit jeder Entwickler sich schnell ein Bild schaffen kann, welche Parameter Sets im Projekt definiert sind. Dies vermeidet unnötige redundante Definitionen und stärkt die Wiederverwendung.
Die Anlage eines Parameter Sets funktioniert einfach über das Menü: File – New – Other – Parameter Set, wie auch in dem folgenden Bild gezeigt.
Dem Job kann man es über die Job Properties zuordnen, dafür gibt es einen extra Button Add Parameter Set… der dann einen Dialog zeigt mit den gefilterten Strukturen, die Parameter Sets beinhalten.
Unser Tipp: Noch einfacher und schneller geht es, indem man das Parameter Set einfach aus dem Repository per Drag & Drop auf den geöffneten Job zieht.
Weitere Details für Interessierte
Abbildung 1 zeigt die Defaultwerte eines Parameter Sets – diese werden standardmäßig verwendet, auch wenn beim Start keine explizite Auswahl stattfindet. Wenn Sie diese Funktionalität verwenden, sollten sie nicht vergessen, bei Änderung einer Parameterausprägung alle Jobs zu kompilieren, die dieses Parameter Set verwenden.
Lassen Sie die Defaultwerte leer und legen dafür ein oder mehrere Value Files an (siehe Abbildung 2), ist kein Re-Compile nötig bei Änderungen – aber beim Start muss dann immer ein Value-File ausgewählt werden, um eine gültige Werte-Kombination zu bekommen.
Die sogenannten Value-Files, die oben in Abbildung 2 gezeigt werden, liegen als einfache Textfiles im DataStage Projektpfad (<InformationServer-Installationspfad>\Server\Projects\<Projektname>\ParameterSets\PS_Db2_SAMPLE\).
Somit könnten diese auch beispielsweise über einen weiteren DataStage Job dynamisch erzeugt werden und so als Übergabe von Daten aus einem Datenstrom an einen weiteren Job als Parameter innerhalb eines Parameter Sets dienen. Den Möglichkeiten sind fast keine Grenzen gesetzt.
Viel Spaß beim Ausprobieren und Nutzen von Parameter Sets – wenn Sie weitere Anregungen oder Hilfe brauchen, erreichen sie mich unter kontakt@mip.de.
Ein Parameter Set ist eine Gruppierung von Parametern, um es einmal einfach zusammenzufassen. Diese Gruppierung macht besonders dann Sinn, wenn die Parameter korreliert sind. Ein gutes Beispiel dafür sind die Verbindungsdaten zu einer Datenbank: Der Datenbankname, die User ID und das Passwort sind korreliert und werden immer in Kombination benötigt, um eine erfolgreiche Verbindung zu definieren. Dies kann dann auch noch mit Schemanamen etc. ergänzt werden.
Wo liegt der Vorteil?
Dieses Parameter Set ist ein DataStage Objekt und kann so als Ganzes einem Job zugeordnet werden. Statt vier einzelne Parameter kann das Parameter Set in einem Schritt zugeordnet werden. Aber nicht nur das, auch beim Jobstart kann man eine gültige Wertekombination in einem Schritt auswählen (sofern diese vordefiniert wurde). Das verhindert Flüchtigkeitsfehler, indem man evtl. einen falschen User für die konkrete Datenbankverbindung auswählt.
Apropos vordefiniert – auch das ist ein wesentlicher Vorteil von Parameter Sets, denn es lassen sich verschiedene Werte-Kombinationen vorab hinterlegen und einem Namen zuordnen. Dieser kann dann beim Aufruf gewählt werden und es werden automatisch die unter diesem Namen vordefinierten Werte eingetragen.
Unser Tipp: In der Projektstruktur im Designer ist standardmäßig kein vordefinierter Platz für Parameter Sets vorgesehen. Es empfiehlt sich einen Ordner ParameterSets anzulegen, damit jeder Entwickler sich schnell ein Bild schaffen kann, welche Parameter Sets im Projekt definiert sind. Dies vermeidet unnötige redundante Definitionen und stärkt die Wiederverwendung.
Die Anlage eines Parameter Sets funktioniert einfach über das Menü: File – New – Other – Parameter Set, wie auch in dem folgenden Bild gezeigt.
Dem Job kann man es über die Job Properties zuordnen, dafür gibt es einen extra Button Add Parameter Set… der dann einen Dialog zeigt mit den gefilterten Strukturen, die Parameter Sets beinhalten.
Unser Tipp: Noch einfacher und schneller geht es, indem man das Parameter Set einfach aus dem Repository per Drag & Drop auf den geöffneten Job zieht.
Weitere Details für Interessierte
Abbildung 1 zeigt die Defaultwerte eines Parameter Sets – diese werden standardmäßig verwendet, auch wenn beim Start keine explizite Auswahl stattfindet. Wenn Sie diese Funktionalität verwenden, sollten sie nicht vergessen, bei Änderung einer Parameterausprägung alle Jobs zu kompilieren, die dieses Parameter Set verwenden.
Lassen Sie die Defaultwerte leer und legen dafür ein oder mehrere Value Files an (siehe Abbildung 2), ist kein Re-Compile nötig bei Änderungen – aber beim Start muss dann immer ein Value-File ausgewählt werden, um eine gültige Werte-Kombination zu bekommen.
Die sogenannten Value-Files, die oben in Abbildung 2 gezeigt werden, liegen als einfache Textfiles im DataStage Projektpfad (<InformationServer-Installationspfad>\Server\Projects\<Projektname>\ParameterSets\PS_Db2_SAMPLE\).
Somit könnten diese auch beispielsweise über einen weiteren DataStage Job dynamisch erzeugt werden und so als Übergabe von Daten aus einem Datenstrom an einen weiteren Job als Parameter innerhalb eines Parameter Sets dienen. Den Möglichkeiten sind fast keine Grenzen gesetzt.
Viel Spaß beim Ausprobieren und Nutzen von Parameter Sets – wenn Sie weitere Anregungen oder Hilfe brauchen, erreichen sie mich unter kontakt@mip.de.
