XSLT oder Message Mapping in der CPI: Wann welches Werkzeug?

Die Mapping-Arten in der CPI im Überblick

Bevor wir in den Vergleich einsteigen, ein kurzer Überblick über alle Optionen:

• Message Mapping: Grafisches Werkzeug, Felder werden per Drag-and-Drop verbunden, Funktionen per Klick konfiguriert.
• XSLT Mapping: Transformation über eine externe XSLT-Datei, volle programmatische Kontrolle über die Ausgabe.
• Operation Mapping: Import aus dem SAP Enterprise Services Repository (ESR), relevant in PI/PO-Migrationsszenarien.
• Groovy- oder JavaScript-Script: Kein dediziertes Mapping, aber als Script-Schritt in der Integration Flow nutzbar, wenn die anderen Werkzeuge nicht ausreichen.

Im Projektalltag sind Message Mapping und XSLT die Hauptkandidaten. Die Entscheidung zwischen den beiden bestimmt oft, wie wartbar ein Integration Flow langfristig bleibt.

Message Mapping: Stärken und Grenzen

Message Mapping ist das, was die meisten Einsteiger zuerst kennenlernen. Es sieht intuitiv aus: linke Seite Quellstruktur, rechte Seite Zielstruktur, Linien ziehen, fertig.

Die Stärken:

• Kein Code nötig: Personen ohne Entwicklungserfahrung können einfache Mappings selbst erstellen und anpassen.
• Integrierte Testfunktion: Direkt im Editor lässt sich ein Mapping mit Beispieldaten testen.
• MIG- und MAG-Integration: Über den SAP Integration Advisor können Message Implementation Guides und Mapping Guidelines direkt importiert und als Basis genutzt werden, besonders hilfreich bei Standardformaten wie EDIFACT oder IDoc.
• Schneller Einstieg: Für einfache, flache 1:1-Mappings ist man in wenigen Minuten fertig.

Die Grenzen:

• Viele Klicks: Jede Funktion, jede Bedingung, jede Schleife wird grafisch konfiguriert. Bei wachsender Komplexität wird das zeitaufwendig und unübersichtlich.
• Schlechte Versionierbarkeit: Das Mapping wird intern als XML gespeichert. Ein Git-Diff auf diese Datei ist kaum lesbar, weil kleine inhaltliche Änderungen große strukturelle Diffs erzeugen.
• Testfunktion versagt bei Komplexität: Dynamische Mappings, kontextabhängige Funktionen oder große Payloads führen oft dazu, dass der integrierte Test fehlschlägt oder schlicht nichts zurückgibt, ohne klare Fehlermeldung.
• Schwer mit LLMs zu analysieren: Der grafische Zustand des Mappings lässt sich einem Sprachmodell nicht einfach übergeben. Eine XSLT-Datei hingegen ist reiner Text.

XSLT Mapping: Stärken und Grenzen

XSLT ist eine deklarative, XML-basierte Sprache speziell für die Transformation von XML-Dokumenten. In der CPI wird eine externe XSLT-Datei in das Integration Package geladen und im XSLT Mapping Schritt referenziert.

Die Stärken:

• Volle Kontrolle: Alles, was das Mapping tut, steht im Code. Kein versteckter Zustand, kein Klick-Rätsel.
• Übersicht auf einen Blick: Auch komplexe Transformationen mit Schleifen, Bedingungen und mehreren Templates sind in einer einzigen Datei nachvollziehbar.
• Saubere Versionierung: Ein Git-Diff auf eine XSLT-Datei zeigt genau, was sich geändert hat. Code-Reviews sind möglich.
• LLM-freundlich: Eine XSLT-Datei lässt sich direkt in einen Chat mit Claude oder ChatGPT einfügen. Das Modell kann erklären, refaktorieren, Fehler finden und Verbesserungen vorschlagen, ohne Kontext zu verlieren.
• Wiederverwendbare Templates: XSLT erlaubt named Templates und Import-Mechanismen, mit denen sich gemeinsame Logik auslagern lässt.
• Externe Testbarkeit: XSLT kann lokal mit Beispiel-XML getestet werden, unabhängig von der CPI-Laufzeit.

Die Grenzen:

• Einstiegshürde: Wer kein XML und keine funktionale Programmierlogik kennt, braucht Zeit, um XSLT zu verstehen.
• Kein natives Tooling in der CPI: Es gibt weder Syntax-Highlighting noch einen Live-Test direkt im Integration Package Editor. Die Entwicklung findet lokal statt, die Datei wird hochgeladen.
• Externes Werkzeug notwendig: Für komfortable Entwicklung, Syntax-Prüfung und Formatierung braucht man ein externes Tool wie VS Code mit einer XML/XSLT-Extension. Das bedeutet einen zusätzlichen Schritt im Workflow: lokal schreiben, in das CPI-Package hochladen, testen.
• Keine MIG-/MAG-Integration: Der SAP Integration Advisor kann keine XSLT-Dateien direkt generieren. Wer auf diesen Workflow angewiesen ist, bleibt beim Message Mapping.

Code-Beispiel: Ein XSLT-Mapping in der Praxis

Das folgende Beispiel zeigt eine typische Transformation: ein Quell-XML wird umgebaut, Felder umbenannt und ein bedingtes Element eingefügt.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:output method="xml" indent="yes" encoding="UTF-8"/>

  <xsl:template match="/">
    <Order>
      <xsl:apply-templates select="PurchaseOrder"/>
    </Order>
  </xsl:template>

  <xsl:template match="PurchaseOrder">
    <!-- Felder umbenennen -->
    <OrderId><xsl:value-of select="PONumber"/></OrderId>
    <Supplier><xsl:value-of select="Vendor/Name"/></Supplier>

    <!-- Bedingte Ausgabe -->
    <xsl:if test="Priority = 'HIGH'">
      <Urgent>true</Urgent>
    </xsl:if>

    <!-- Schleife über Positionen -->
    <Items>
      <xsl:for-each select="LineItems/Item">
        <Item>
          <MaterialNumber><xsl:value-of select="@id"/></MaterialNumber>
          <Quantity><xsl:value-of select="Qty"/></Quantity>
        </Item>
      </xsl:for-each>
    </Items>
  </xsl:template>

</xsl:stylesheet>

Diesen Code kann man direkt in einen Chat mit einem LLM einfügen und fragen: "Warum gibt dieses Mapping kein Ergebnis zurück?" oder "Füge eine Bedingung hinzu, die leere Felder überspringt." Das funktioniert zuverlässig, weil XSLT reiner Text ist.

Wann XSLT bevorzugen

• Das Mapping hat mehr als eine Handvoll Felder oder benötigt Schleifen und Bedingungen.
• Die Quelldaten haben verschachtelte oder wiederholende Strukturen, die grafisch schwer darstellbar sind.
• Mehrere Personen arbeiten am gleichen Integration Flow, Code-Reviews sollen möglich sein.
• Das Mapping soll mit Hilfe eines LLMs erstellt, debuggt oder optimiert werden.
• Es gibt viele ähnliche Mappings, zum Beispiel in einem Migrationsprojekt, die sich über gemeinsame Templates wiederverwenden lassen.
• Der Integration Flow soll langfristig gewartet werden und die Logik muss in einem Jahr noch nachvollziehbar sein.
• Grosse Payloads oder dynamische Eingaben machen den eingebauten Testmechanismus des Message Mappings unzuverlässig.

Wann Message Mapping bevorzugen

• Es handelt sich um ein einfaches, flaches 1:1-Mapping ohne komplexe Logik.
• Der Fachbereich oder ein Junior ohne Entwicklungshintergrund soll das Mapping selbst pflegen können.
• Das Szenario basiert auf dem SAP Integration Advisor mit MIGs und MAGs, zum Beispiel bei EDIFACT- oder IDoc-Szenarien.
• Es ist ein schneller Prototyp gefragt und Langlebigkeit spielt keine Rolle.
• Das Team hat keine Ressourcen für lokales XSLT-Tooling und möchte alles direkt in der CPI erledigen.

Fazit

Beide Werkzeuge haben ihren Platz. Message Mapping senkt die Einstiegshürde und ist für einfache Szenarien und MIG-/MAG-basierte Integrationen die richtige Wahl. XSLT skaliert besser mit wachsender Komplexität, lässt sich sauber versionieren und eignet sich gut für die Zusammenarbeit mit LLMs.

Eine gute Faustregel: Sobald ein Mapping im grafischen Editor unübersichtlich wird oder der Testmechanismus nicht mehr funktioniert, ist der Wechsel zu XSLT meist die richtigere Investition. Der Mehraufwand durch das externe Tooling amortisiert sich schnell, wenn das Mapping wächst oder häufig angepasst werden muss.