Wer aus der PowerCenter-Welt kommt, steuert Sessions und Workflows seit Jahren über Parameterdateien. Auch in der IDMC gibt es Parameterdateien, daneben aber noch die Parametersets, die ausschließlich für Taskflows gedacht sind. In diesem Artikel zeige ich euch, worin sich beide unterscheiden, welche Vor- und Nachteile die Parametersets haben und wie man sie mit der ParamSetCli verwaltet.

Grundlage sind die Informatica-Dokumentation und einige Artikel aus der Informatica Knowledge Base. Wo die Dokumentation schweigt und ich selbst Schlüsse ziehe, sage ich das dazu.

Parameterdateien in der IDMC

Eine Parameterdatei ist eine Textdatei mit Werten für die $$-Parameter eines Mappings. In einem anderen Artikel habe ich bereits beschrieben, wie man Parameterdateien in PowerCenter dynamisch erzeugt. In der IDMC ist der Aufbau sehr ähnlich:

#USE_SECTIONS
[GLOBAL]
$$Land=DE
[DWH].[Staging].[mt_Kunden_Laden]
$$Quelltabelle=KUNDEN_DELTA

Im Mapping Task legt man auf der Registerkarte Runtime Options fest, wo die Datei liegt. Bei der Option Local liegt sie auf dem Secure Agent, standardmäßig im Verzeichnis apps/Data_Integration_Server/data/userparameters unterhalb des Installationsverzeichnisses. Mit Cloud Hosted liest der Task die Datei über eine Connection aus Amazon S3, Azure Data Lake Storage Gen2 oder Google Cloud Storage. Diese Variante sieht die Doku zum Beispiel für Tasks in einer Serverless Runtime vor.

Abschnitte gibt es für einzelne Tasks, für Taskflows und global. Der engste Abschnitt gewinnt: Task vor Taskflow vor #USE_SECTIONS vor [GLOBAL]. Wichtig ist die erste Zeile. Fehlt #USE_SECTIONS, liest die IDMC nur den ersten globalen Abschnitt und ignoriert alle weiteren.

Parameterdateien funktionieren in Mapping Tasks, Synchronization Tasks, Data Transfer Tasks und PowerCenter Tasks. In einem Taskflow kann man Verzeichnis und Dateiname im Data-Task-Schritt unter Input Fields überschreiben. Nicht nutzbar sind sie in Mappings im SQL ELT Mode.

Was ein Parameterset ist

Taskflows bekommen ihre Eingabefelder normalerweise als JSON oder XML beim Start. Für die Migration von PowerCenter-Workflows hat Informatica deshalb die Parametersets eingeführt: eine Parameterdatei, die man mit der ParamSetCli in ein von Informatica verwaltetes Repository in der Cloud hochlädt. Ab dem Hochladen heißt sie Parameterset und ist über einen eindeutigen Namen in der ganzen Organisation ansprechbar.

Das Format ist dasselbe wie bei einer Parameterdatei. Die Abschnitte beziehen sich aber auf Taskflows und reichen bis auf einzelne Subtaskflow-Schritte hinunter:

#USE_SECTIONS
$$Umgebung=PROD
[GLOBAL]
$$Land=DE
[DWH].[Orchestrierung].[tf_DWH_Nachtlauf]
$$Land=AT
$$Ladedatum=2026-04-20
[DWH].[Orchestrierung].[tf_DWH_Nachtlauf].[Kunden laden]
$$Ladedatum=2026-04-19

Auch hier gewinnt der engste Abschnitt: Subtaskflow-Schritt vor Taskflow vor #USE_SECTIONS vor [GLOBAL]. In meinem Beispiel sieht der Taskflow tf_DWH_Nachtlauf also $$Land=AT und $$Ladedatum=2026-04-20, der Subtaskflow-Schritt „Kunden laden“ dagegen $$Ladedatum=2026-04-19. Kommt eine Abschnittsüberschrift doppelt vor, gilt nur der erste Abschnitt. Alle Werte sind Strings.

Die Aufteilung zwischen den beiden Wegen sieht so aus:

Im Firmennetz führt der Secure Agent Taskflow und Mapping Task aus; der Mapping Task liest die Parameterdatei, der Taskflow das Parameterset, das die ParamSetCli in die IDMC-Cloud hochgeladen hat
Parameterdatei und Parameterset.

Parameterset im Taskflow nutzen

Im Taskflow wählt man den Start-Schritt und trägt auf der Registerkarte Start im Feld Parameter Set den eindeutigen Namen des Sets ein. Anschließend legt man für jeden Parameter aus dem Set ein Eingabefeld im Start-Schritt an. Fehlt ein solches Eingabefeld, bricht der Taskflow laut Knowledge Base mit „Unexpected exception found“ ab. Umgekehrt bekommt ein Eingabefeld ohne Wert im Set den Standardwert seines Datentyps, also zum Beispiel null bei Text oder 0 bei Integer.

Danach veröffentlicht man den Taskflow. Der im Start-Schritt eingetragene Name wirkt als Vorgabe. Beim Start über die REST-Schnittstelle kann man ein anderes Set wählen. Dafür ersetzt man in der Service-URL rt durch tf und hängt das Set an:

https://<pod>.informaticacloud.com/active-bpel/tf/tf_DWH_Nachtlauf
https://<pod>.informaticacloud.com/active-bpel/tf/tf_DWH_Nachtlauf/paramset/nachtlauf_nachholen.params

Die SOAP-URL unterstützt keine Parametersets. Aus einem externen Scheduler geht es auch mit der runAJobCli und der Option -pun. Wie man die runAJobCli einrichtet, habe ich in einem eigenen Artikel beschrieben:

./cli.sh runAJobCli -t TASKFLOW -un tf_DWH_Nachtlauf -pun nachtlauf_nachholen.params

Die Optionen -pf und -pd für Parameterdateien wirken bei Taskflows übrigens nicht. Dort ist das Parameterset der vorgesehene Weg.

Die ParamSetCli

Die ParamSetCli ist ein kleines Java-Programm und nicht Teil des Secure Agents. Man lädt sie als paramsetcli.zip aus dem Knowledge-Base-Artikel 000181524 („FAQ: How to configure a parameter set in a Taskflow in CDI?“) herunter und entpackt sie in ein eigenes Verzeichnis außerhalb des Secure Agents. Unter Linux ruft man paramsetcli.sh auf, unter Windows paramsetcli.bat. Voraussetzung ist eine Java-Laufzeitumgebung. Falls ihr über einen Proxy geht, verlangt die Doku zusätzlich einen Secure Agent auf derselben Maschine.

Konfiguriert wird sie wie die runAJobCli über eine restenv.properties:

baseUrl=https://dm-em.informaticacloud.com/ma
paramSetBaseUrl=https://<pod>.informaticacloud.com/active-bpel
username=svc_deploy
password=<verschlüsseltes Passwort>
use.encryption=true
ACTIVITYMONITORWAIT=5000
RETRYCOUNT=6
PROXYHOST=proxy.firma.local
PROXYPORT=8080
PROXYUSERNAME=svc_proxy
PROXYPWD=<verschlüsseltes Passwort>

Neu gegenüber der runAJobCli ist paramSetBaseUrl. Das ist die Adresse eures Pods mit /active-bpel am Ende, also derselbe Host, den ihr auch in den Service-URLs eurer Taskflows seht. Angenehm ist die Proxy-Konfiguration: Benutzer und Passwort stehen hier direkt in der Datei, und das Proxy-Passwort darf wie das IDMC-Passwort verschlüsselt sein. Verschlüsselt wird mit:

./paramsetcli.sh encryptText -t 'MeinGeheimesPasswort'

Die vier Aktionen wählt man mit -a. Mit -un gibt man den eindeutigen Namen des Sets an, mit -pd und -pf Verzeichnis und Datei auf der lokalen Maschine:

# hochladen, ein vorhandenes Set gleichen Namens mit -f überschreiben
./paramsetcli.sh runParamSetCli -a upload -un nachtlauf.params -pd /data/informatica/params -pf nachtlauf.params -f

# herunterladen
./paramsetcli.sh runParamSetCli -a download -un nachtlauf.params -pd /data/informatica/params -pf nachtlauf_aktuell.params

# auflisten, höchstens 50 Einträge pro Seite
./paramsetcli.sh runParamSetCli -a list -page 2 -ps 50

# endgültig löschen
./paramsetcli.sh runParamSetCli -a delete -un nachtlauf.params

Eine Datei darf höchstens 5 MB groß sein. Ohne -f lehnt die ParamSetCli den Upload ab, falls es den Namen schon gibt, und der Download überschreibt keine vorhandene lokale Datei. Ändert ihr die Datei nach dem Hochladen, müsst ihr sie erneut hochladen, damit die Änderung wirkt.

Hinweis: Zum Anlegen und Bearbeiten von Parametersets beschreibt die Doku nur die ParamSetCli, weder eine REST-Schnittstelle noch eine Oberfläche. Nur die Zuordnung eines Sets zu einem Taskflow lässt sich per REST ändern (PUT /active-bpel/asset/v1/update?assetType=Taskflow).

Unterschiede auf einen Blick

Parameterdatei Parameterset
Ablage Secure Agent oder Cloud-Speicher (S3, ADLS Gen2, GCS) Repository von Informatica in der Cloud
Nutzbar in Mapping, Synchronization, Data Transfer und PowerCenter Task, auch innerhalb von Taskflows (eigene Taskflow-Abschnitte) nur Taskflows, für die Eingabefelder des Start-Schritts (inklusive Subtaskflow- und Data-Task-Schritte)
Abschnitte Task, Taskflow, global Taskflow, Subtaskflow-Schritt, global
Pflege beliebiges Werkzeug mit Dateizugriff nur ParamSetCli
Auswahl beim Start Verzeichnis und Dateiname im Task oder Taskflow-Schritt Name im Start-Schritt, beim Start per REST oder -pun austauschbar
Größe keine Grenze dokumentiert höchstens 5 MB
Voraussetzung keine ggf. Freischaltung durch Informatica

Vor- und Nachteile von Parametersets

Der größte Vorteil ist, dass der Taskflow seine Parameter ohne Umweg über das Dateisystem eines Secure Agents bekommt. Man kann dasselbe Set in mehreren Taskflows verwenden und für einzelne Subtaskflow-Schritte eigene Werte hinterlegen. Praktisch finde ich auch, dass man beim Start ein anderes Set wählen kann, ohne den Taskflow anzufassen, etwa für einen Nachholauf mit anderem Ladedatum. Wer PowerCenter-Workflows mit umfangreichen Parameterdateien migriert, kann diese Dateien als Grundlage nehmen. Die Abschnittsüberschriften muss man dabei allerdings von der PowerCenter-Form [Ordner.WF:Workflow] auf [Projekt].[Ordner].[Taskflow] umstellen.

Dem stehen einige Einschränkungen gegenüber:

  • Mit dem IPU-Modell sind laut Informatica alle berechtigten Cloud-Dienste enthalten, neue werden automatisch aktiviert. Laut Knowledge Base kann es trotzdem nötig sein, dass Informatica Parametersets für die Organisation freischaltet; dafür wendet man sich an den Customer Success Manager oder den Support.
  • Benutzer mit SAML-Anmeldung können nicht mit Parametersets arbeiten. Die ParamSetCli braucht also einen technischen Benutzer mit IDMC-eigenem Passwort.
  • Sie gelten nur für Taskflows. Ein Mapping Task, der allein läuft, bleibt bei der Parameterdatei.
  • Die Pflege geht nur über die Kommandozeile. Eine Versionierung ist nicht dokumentiert, und -f überschreibt ein vorhandenes Set. Ich würde die Dateien deshalb in einem Git-Repository führen und von dort hochladen.
  • Jeder Parameter braucht zusätzlich ein Eingabefeld im Start-Schritt. Parameter und Taskflow müssen also zusammen gepflegt werden.

Ein Punkt betrifft das Deployment. Die Dokumentation zum Export und Import von Assets erwähnt Parametersets nicht, und die eindeutigen Namen gelten jeweils innerhalb einer Organisation. Ich gehe deshalb davon aus, dass ein Set beim Export eines Taskflows nicht mitwandert und in jeder Umgebung einzeln mit der ParamSetCli hochgeladen werden muss. Das ist meine Schlussfolgerung, keine Aussage der Doku. Für Dev, Test und Produktion ist das aber ohnehin sinnvoll, denn dort stehen in der Regel unterschiedliche Werte drin.

Für sensible Werte wie ein parametrisiertes Connection-Passwort empfiehlt Informatica eine eigene Parameterdatei für die Mapping Tasks. Das Parameterset enthält dann nur die Werte auf Ebene des Taskflows. Diese Trennung würde ich auch unabhängig von der Empfehlung so umsetzen.

Quellen

Wie ihr seht, sind Parametersets eine Ergänzung für Taskflows. Für einzelne Tasks bleibt die Parameterdatei der richtige Weg. Falls ihr Fragen dazu habt oder gerade eine PowerCenter-Migration plant, schreibt mir gerne.