In PowerCenter liest der Integration Service beim Start eines Workflows die Parameterdatei und belegt damit auch die Workflow-Variablen. Diese $$-Variablen kann man im Workflow direkt verwenden, etwa in einem Decision Task, in einem Assignment oder in einer Link-Bedingung. Wie geht man aber vor, wenn ein IDMC-Taskflow anhand eines Werts aus der Parameterdatei verzweigen oder einen Wert an seine Tasks weiterreichen soll? In diesem Artikel zeige ich euch zwei Wege: das Parameterset und ein Dummy-Mapping mit In-out-Parametern.

Was der Taskflow von der Parameterdatei sieht

Eine Parameterdatei in der IDMC kann einen Abschnitt für einen Taskflow haben, zum Beispiel [DWH].[Orchestrierung].[tf_DWH_Nachtlauf]. Die Werte darin gelten für alle Tasks, die dieser Taskflow startet. Der Taskflow selbst liest die Datei aber nicht. Laut Doku muss man sie dafür mit der ParamSetCli als Parameterset in die Cloud hochladen. Erst dann landen die Werte in den Eingabefeldern des Taskflows.

Den zweiten Weg gibt es ohne Parameterset: Ein Mapping Task liest die Parameterdatei, übernimmt die Werte in In-out-Parameter, und der Taskflow liest diese nach dem Lauf aus. Beide Wege im Überblick:

Die Parameterdatei erreicht den Taskflow entweder als Parameterset über die Eingabefelder des Start-Schritts oder über einen Dummy-Mapping-Task, dessen In-out-Parameter nach dem Data Task bereitstehen; danach nutzen Decision, Assignment, Data Task und Notification die Werte
Zwei Wege von der Parameterdatei in den Taskflow.

Weg 1: das Parameterset

Wie man die ParamSetCli einrichtet und Parametersets verwaltet, habe ich im Artikel über Parametersets und Parameterdateien ausführlich beschrieben. Hier geht es nur darum, wie die Werte im Taskflow ankommen. In meinem Beispiel sieht das Parameterset so aus:

#USE_SECTIONS
[GLOBAL]
$$Mail_An=dwh-team@example.com
[DWH].[Orchestrierung].[tf_DWH_Nachtlauf]
$$Modus=DELTA
$$Ladedatum=2026-10-09
$$Tage_zurueck=3

Hochgeladen wird die Datei auf dem Linux-Server, auf dem die ParamSetCli liegt:

./paramsetcli.sh runParamSetCli -a upload -un nachtlauf.params -pd /data/informatica/params -pf nachtlauf.params -f

Im Taskflow trägt man auf der Registerkarte Start des Start-Schritts im Feld Parameter Set den Namen nachtlauf.params ein. Anschließend legt man unter Input Fields für jeden Parameter ein Eingabefeld an. Das Feld heißt wie der Parameter, nur ohne die beiden Dollarzeichen, in meinem Beispiel also Mail_An, Modus, Ladedatum und Tage_zurueck. Danach veröffentlicht man den Taskflow.

Alle Werte im Parameterset sind Strings. Ob ein Eingabefeld vom Typ Integer oder Date den String selbst umwandelt, steht nicht in der Doku. Ich lege die Felder deshalb als Text an und wandle sie im Ausdruck um, wo ich eine Zahl oder ein Datum brauche.

Werte im Taskflow verwenden

Im Expression Editor spricht man ein Eingabefeld mit $input. und dem Feldnamen an, also $input.Ladedatum. Variablen stehen ohne Anführungszeichen, Texte in einfachen oder doppelten Anführungszeichen. Die Ausdrücke sind XQuery 3.0, ergänzt um eigene Funktionen von Informatica wie util:toInteger oder util:iif.

Decision

Am einfachsten verzweigt man über Field. Man wählt das Eingabefeld Modus aus und legt einen Pfad mit der Bedingung Equals und dem Wert VOLL an. Alles andere läuft in den Pfad Otherwise, der immer der letzte Pfad sein sollte. Die Pfade werden nämlich von oben nach unten geprüft, und der erste Treffer gewinnt.

Für Zahlenvergleiche nimmt man Formula. Weil der Wert als Text ankommt, wandelt man ihn vorher um und vergleicht mit der Bedingung Greater than gegen 0:

util:toInteger($input.Tage_zurueck)

util:toInteger liefert übrigens 0, falls der Wert Buchstaben enthält. Ein Tippfehler im Parameterset führt also nicht zu einem Fehler, sondern in den falschen Pfad.

Assignment

Mit einem Assignment setzt man ein temporäres Feld oder ein Eingabefeld. In meinem Beispiel baut ein temporäres Feld Dateiname aus Modus und Ladedatum den Namen einer Exportdatei zusammen. Als Wert wählt man Formula:

util:iif($input.Modus = 'VOLL', 'kunden_voll.csv', concat('kunden_', $input.Ladedatum, '.csv'))

Data Task

Die meisten Werte sollen am Ende in einem Mapping Task ankommen. Dafür öffnet man im Data-Task-Schritt die Input Fields, klickt auf Add und wählt unter Input Parameters den Parameter des Mapping Tasks aus. Unter Edit stellt man die Quelle auf Field und wählt das Eingabefeld des Taskflows, etwa Ladedatum. Auf demselben Weg lassen sich auch Verzeichnis und Name der Parameterdatei des Mapping Tasks überschreiben.

Hinweis: Setzt man denselben Parameter sowohl in einem Assignment als auch im Data Task, gilt laut Doku der Wert aus dem Data Task.

Notification und Command Task

In Feldern mit der Quelle Content schreibt man den Ausdruck in geschweifte Klammern. Den Empfänger einer Notification setzt man so auf { $input.Mail_An }. Beim Command Task können Skriptname, Argumente und Arbeitsverzeichnis ebenfalls aus einem Feld oder einer Formel kommen. Geschweifte Klammern im Skript oder in den Eingabefeldern muss man dort verdoppeln, weil sie in XQuery Sonderzeichen sind.

Weg 2: Dummy-Mapping mit In-out-Parametern

Falls Parametersets in eurer Organisation nicht freigeschaltet sind oder die Datei auf dem Secure Agent bleiben soll, gibt es einen zweiten Weg. Er nutzt die In-out-Parameter eines Mapping Tasks. In-out-Parameter sind eigentlich persistente Task-Variablen, etwa für das inkrementelle Laden. Für unseren Zweck zählt ihre Reihenfolge bei der Wertermittlung. Zur Laufzeit sucht der Mapping Task den Wert in dieser Reihenfolge:

  1. Wert aus der Parameterdatei
  2. gespeicherter Wert aus dem letzten Lauf
  3. Standardwert im Mapping
  4. Standardwert des Datentyps

Ein Wert in der Parameterdatei schlägt also alles andere. Verwendet das Mapping keine Variablenfunktion wie SetVariable, bleibt dieser Startwert auch der Wert, den der Task am Ende meldet.

Mapping und Mapping Task

Im Dummy-Mapping legt man für jeden Wert, den der Taskflow braucht, einen In-out-Parameter an, in meinem Beispiel Modus und Ladedatum vom Typ String. Bei String-Parametern stehen als Aggregationstyp nur Max oder Min zur Wahl, für unseren Zweck spielt er keine Rolle. Als Retention Policy würde ich Never wählen. Falls ein Wert einmal in der Datei fehlt, nimmt der Task dann den Standardwert und nicht still den Wert vom letzten Lauf. Fachlich muss das Mapping nichts tun.

Im Mapping Task mt_Parameter_lesen stellt man auf der Registerkarte Runtime Options die Parameterdatei ein, mit der Option Local zum Beispiel /opt/infaagent/apps/Data_Integration_Server/data/userparameters/nachtlauf.params. Die Datei kann dieselbe sein, die auch die übrigen Tasks des Taskflows verwenden. Steht der Wert im Abschnitt des Taskflows, gilt er für alle Tasks, die dieser Taskflow startet, also auch für den Dummy-Task:

#USE_SECTIONS
[DWH].[Orchestrierung].[tf_DWH_Nachtlauf]
$$Modus=DELTA
$$Ladedatum=2026-10-09

Im Taskflow

Der Dummy-Task ist der erste Data-Task-Schritt im Taskflow, in meinem Beispiel dt_Parameter_lesen. Unter Input Fields überschreibt man die In-out-Parameter dort nicht, sonst stünde der Wert aus dem Taskflow in Konkurrenz zur Datei. Welcher dann gewinnt, beschreibt die Doku nicht.

Nach diesem Schritt stehen die Werte bereit. In einer Decision wählt man unter Field den Schritt dt_Parameter_lesen, dann InOut Parameters und dann Modus. Den Wert kann man auch an weitere Data Tasks weitergeben. Vor dem Dummy-Schritt gibt es den Wert noch nicht, denn laut Doku liest der Taskflow einen In-out-Parameter erst, nachdem der Data Task gelaufen ist.

Einige Regeln aus der Doku gelten für diesen Weg zusätzlich:

  • Datetime-Parameter erscheinen im Taskflow als String.
  • Ein Wert darf höchstens 4000 Zeichen lang sein.
  • Laufen mehrere Instanzen desselben Mapping Tasks gleichzeitig, sind die Ergebnisse der In-out-Parameter nicht vorhersagbar. Falls euer Taskflow parallel laufen kann, würde ich deshalb Weg 1 nehmen.
  • Im SQL ELT Mode gibt es keine In-out-Parameter.
  • Fügt man einen In-out-Parameter hinzu oder ändert ihn, muss man den Mapping Task im Data-Task-Schritt neu auswählen.

Welcher Weg wann?

Parameterset Dummy-Mapping
Ablage der Datei Repository von Informatica in der Cloud Secure Agent oder Cloud-Speicher (S3, ADLS Gen2, GCS)
Pflege ParamSetCli, nach jeder Änderung neu hochladen Datei direkt bearbeiten
Werte verfügbar ab dem Start erst nach dem Dummy-Data-Task
Voraussetzung ggf. Freischaltung durch Informatica, ParamSetCli nicht mit SAML-Benutzer keine
Zusatzaufwand ein Eingabefeld je Parameter Mapping, Mapping Task, ein In-out-Parameter je Wert, ein zusätzlicher Joblauf
Gleichzeitige Läufe unkritisch problematisch

Ich würde, wo es geht, das Parameterset nehmen. Die Werte stehen ab dem ersten Schritt zur Verfügung, und man spart sich den zusätzlichen Task. Das Dummy-Mapping ist eine gute Lösung, solange Parametersets nicht freigeschaltet sind oder alle Werte in einer einzigen Datei auf dem Secure Agent bleiben sollen.

Stolperfallen

Ein paar Punkte sind mir bei der Recherche aufgefallen, die man kennen sollte:

  • Fehlt beim Parameterset für einen Parameter das Eingabefeld, bricht der Taskflow laut Knowledge Base mit „Unexpected exception found“ ab.
  • Hat ein Eingabefeld keinen Wert im Parameterset, bekommt es den Standardwert seines Typs, bei Text also null. Das fällt erst im späteren Schritt auf.
  • Der Wert umfasst alles nach dem Gleichheitszeichen, auch Leerzeichen am Ende der Zeile. DELTA mit Leerzeichen ist für die Decision nicht gleich DELTA.
  • util:isNull wertet einen leeren String nicht als NULL. Wer auf fehlende Werte prüft, sollte beide Fälle abdecken.
  • Ist das Parameterset beim Start nicht im Repository vorhanden, schlägt der Taskflow fehl.

Quellen

Wie ihr seht, kommt man in der IDMC auf zwei Wegen an die Werte der Parameterdatei, auch wenn der Taskflow sie nicht selbst liest. Falls ihr Fragen dazu habt oder gerade PowerCenter-Workflows umstellt, schreibt mir gerne.