Wer viele Jahre mit PowerCenter gearbeitet hat, findet sich in der IDMC schnell zurecht. Mappings, Transformationen und Parameter sind vertraut. Vieles heißt aber anders, und manches verhält sich anders, als man es gewohnt ist. In diesem Artikel ordne ich die wichtigsten Bausteine von PowerCenter ihren Gegenstücken in der IDMC zu und verweise für die Details auf meine anderen Artikel.

Die Begriffe im Vergleich

Die folgende Tabelle ist meine Übersetzungshilfe. Sie ist bewusst knapp gehalten:

PowerCenter IDMC
Integration Service auf einem eigenen Server Secure Agent, zusammengefasst in einer Runtime Environment, oder die Serverless Runtime
Repository mit Foldern Projekte und Ordner in der Cloud
Session Mapping Task
Workflow Taskflow
Worklet Subtaskflow
persistente Mapping-Variable In-out-Parameter
Parameterdatei Parameterdatei, für Taskflow-Eingaben zusätzlich Parametersets
Workflow Monitor Monitor bzw. My Jobs
pmcmd startworkflow runAJobCli oder REST-API
Export und Import mit pmrep, Deployment Groups Export und Import von Assets, per Oberfläche oder REST-API
versioniertes Repository Anbindung an ein Git-Repository

Der größte Unterschied steckt in der ersten Zeile. Bei PowerCenter liegen Repository, Integration Service und Scheduler im eigenen Rechenzentrum. In der IDMC liegen Design, Metadaten und Zeitpläne in der Cloud. Ausgeführt werden Tasks und Taskflows von einer Runtime Environment, typischerweise von Secure Agents im eigenen Netz. Wie man einen Secure Agent installiert, habe ich in einem älteren Artikel beschrieben.

Parameter

Parameterdateien gibt es in der IDMC weiterhin, und der Aufbau ist ähnlich. Nur die Abschnitte sehen anders aus. In PowerCenter adressiert man Workflow, Worklet und Session:

[SALES_DWH.WF:wf_daily_load.ST:s_m_load_customer]
$$Quelltabelle=KUNDEN_DELTA

In der IDMC adressiert man Projekt, Ordner und Task bzw. Taskflow. Die erste Zeile muss #USE_SECTIONS sein, sonst liest die IDMC nur den ersten globalen Abschnitt und ignoriert alle weiteren:

#USE_SECTIONS
[Global]
$$Land=DE
[DWH].[Orchestrierung].[tf_DWH_Nachtlauf]
$$Ladedatum=2026-09-24
[DWH].[Staging].[mt_Kunden_Laden]
$$Quelltabelle=KUNDEN_DELTA

Die Werte im Taskflow-Abschnitt gelten für alle Tasks, die dieser Taskflow startet. Ein Task-Abschnitt hat Vorrang. Im Data-Task-Schritt eines Taskflows lassen sich außerdem Verzeichnis und Name der Parameterdatei überschreiben, sogar über Eingabefelder des Taskflows. Damit kann ein Taskflow je Lauf eine andere Datei verwenden. Parameter für Connections und Datenobjekte muss man dafür im Mapping mit „Allow parameter to be overridden at run time“ freigeben. Wie man Parameterdateien in PowerCenter dynamisch erzeugt, habe ich in einem älteren Artikel gezeigt. Das Prinzip lässt sich übertragen.

Was eine Parameterdatei nicht kann, ist das Füllen der Eingabefelder im Start-Schritt eines Taskflows. Dafür gibt es die Parametersets, die in der Cloud liegen und beim Start austauschbar sind. Die Unterschiede habe ich im Artikel über Parametersets und Parameterdateien ausführlich beschrieben.

Die persistenten Mapping-Variablen aus PowerCenter, typischerweise für inkrementelles Laden mit SETMAXVARIABLE, heißen in der IDMC In-out-Parameter. Die Variablenfunktionen gibt es weiterhin, und wie in PowerCenter muss der Aggregationstyp des Parameters zur Funktion passen. Laut Doku können gleichzeitige Läufe eines Mapping Tasks mit In-out-Parametern zu unerwarteten Ergebnissen führen.

Vom Workflow zum Taskflow

Ein Taskflow übernimmt die Rolle des Workflows. Für die Ablaufsteuerung gibt es eigene Schritte, unter anderem:

  • Data Task: startet einen Mapping Task oder einen anderen Datenintegrations-Task
  • Command Task: führt ein Skript auf dem Secure Agent aus
  • Decision: verzweigt nach einem Feldwert oder einer Formel
  • Parallel Paths: führt mehrere Zweige gleichzeitig aus
  • Subtaskflow: bettet einen anderen Taskflow ein, ähnlich einem Worklet
  • File Watch Task: wartet auf Dateien über einen File Listener

Neu für PowerCenter-Entwickler ist, dass ein Taskflow eine Schnittstelle ist. Nach dem Veröffentlichen lässt er sich über seinen API-Namen per REST aufrufen. Für einfache Abfolgen ohne Verzweigungen gibt es außerdem den Linear Taskflow.

Starten und überwachen

Aus einem externen Scheduler startet man in PowerCenter mit pmcmd startworkflow -wait und wertet den Rückgabewert aus. In der IDMC übernimmt die runAJobCli diese Rolle. Sie startet einen Task oder Taskflow, wartet auf das Ende und liefert einen Exit-Code. Die Codes unterscheiden sich allerdings von pmcmd, und die Wartezeit ist in der Standardkonfiguration auf ein bis zwei Minuten begrenzt. Danach endet die runAJobCli mit Code 6, obwohl der Job weiterläuft. Wie man die runAJobCli einrichtet, habe ich im Artikel über die runAJobCli beschrieben.

Den Workflow Monitor ersetzt in der Oberfläche der Monitor. Wer Läufe maschinell auswerten will, greift auf die REST-API zurück. Dort gibt es vier Quellen mit unterschiedlicher Verzögerung und einigen Fallen bei Zeitzonen, die ich im Artikel über das Überwachen von Jobläufen zusammengefasst habe.

Deployment

Für das Deployment zwischen Umgebungen nutzt man in PowerCenter die Export- und Importbefehle von pmrep mit Control-Dateien oder Deployment Groups. Wie das mit pmrep funktioniert, habe ich in einem älteren Artikel beschrieben.

In der IDMC exportiert man Assets als Paket und importiert es in der Zielorganisation, entweder über die Oberfläche oder per REST-API. Beim Import legt man fest, wie mit vorhandenen Assets umgegangen wird, und ordnet Connections und Runtime Environments der Zielumgebung zu. Eine Deployment Group im Sinne von PowerCenter gibt es nicht, ihre Rolle übernimmt das Export-Paket.

An die Stelle des versionierten PowerCenter-Repositorys tritt die Anbindung an ein Git-Repository. Assets werden dort ein- und ausgecheckt, und andere Organisationen holen sich die Stände ab. Steht der Git-Server im eigenen Netz, läuft die Verbindung über den Secure Agent, wie im Artikel über die Anbindung von On-Premise-Git beschrieben.

Der PowerCenter Task als Brücke

Die IDMC kennt einen eigenen Task-Typ für PowerCenter. Man exportiert einen Workflow aus dem Workflow Manager als XML, lädt ihn in einen PowerCenter Task hoch und führt die Session in der IDMC aus. Das klingt nach einer einfachen Migration, ist aber stark eingeschränkt. Laut Doku gilt unter anderem:

  • Die XML-Datei darf genau einen Workflow enthalten, und der Workflow genau eine Session mit einem Mapping.
  • Andere Task-Typen als Sessions sind nicht erlaubt.
  • Wiederverwendbare Transformationen und Shortcuts gehen nicht.
  • Es werden nur bestimmte Quellen, Ziele und Transformationen unterstützt.
  • Änderungen macht man weiterhin in PowerCenter und lädt die XML-Datei danach neu hoch.

Für einzelne Sessions kann das ein Übergang sein. Für eine echte Migration mit Worklets, Kontrollfluss und wiederverwendbaren Objekten reicht es nicht. Dort führt der Weg über die Umstellung auf Mapping Tasks und Taskflows. Dafür bietet Informatica mit Cloud Data Integration for PowerCenter (CDI-PC) eine Modernisierung an. Sie bewertet ein PowerCenter-Repository und wandelt Mappings, Mapplets, Sessions und Workflows in Mappings, Mapplets, Mapping Tasks und Taskflows um. Die Bewertung zeigt auch, welche Objekte sich nur teilweise oder manuell umstellen lassen.

Quellen

Ich hoffe, dass euch diese Übersicht den Einstieg in die IDMC erleichtert. Falls ihr gerade eine Migration von PowerCenter plant und Fragen dazu habt, schreibt mir gerne.