Parser

Nutze den Parser-Schritt, um Werte aus textbasierten Daten zu extrahieren — typischerweise aus dem JSON- oder XML-Response eines vorgelagerten HTTP-Request-Schritts, aber auch aus CSV-ähnlichem Text, Log-Zeilen oder beliebigem Inhalt, den du sonst von Hand auseinanderpflücken müsstest. Der Schritt zieht einen oder mehrere benannte Werte aus dem Input und stellt sie als Outputs zur Verfügung, die Folge-Schritte wie jedes andere SmartField referenzieren können.

Typische Einsatzszenarien:

• Einzelne Felder aus dem JSON-Response einer REST-API extrahieren (Status, ID, Liste von Items).
• SOAP-XML-Antworten verarbeiten — auch Dokumente mit Namespaces.
• Eingehende Webhook-Payloads zerlegen.
• Werte aus unstrukturiertem Text (E-Mail-Body, Log-Zeile) per regulärem Ausdruck herausziehen.

Der Parser ist das natürliche Pendant zum Expression-Schritt: Expression baut Werte zusammen, Parser zerlegt sie.

Schritt konfigurieren

Öffne den Flow-Editor, füge Parser hinzu und fülle die Konfigurationskarte aus.

Beschreibung

• Zweck: Macht klar, wozu diese Parser-Instanz dient.
• Wann ausfüllen: Immer. Die Beschreibung erscheint im Editor und in der Ausführungshistorie.
• Tipp: Quelle und Absicht nennen, z.B. SAP-Auftragsantwort parsen.

Parser-Typ

• Zweck: Wählt die Selektor-Sprache, die für alle Zeilen dieses Schritts verwendet wird.
• Optionen:
  • JsonPath — für JSON-Payloads. Selektoren wie $.id, $.items[*].name.
  • XPath — für XML- bzw. SOAP-Payloads. Selektoren wie /Envelope/Body/Result.
  • RegEx — für freien Text. Ein .NET-Regulärausdruck, optional mit Capture-Groups.
• Wann ausfüllen: Pflicht. Die Auswahl gilt für alle Zeilen des Schritts.

Input

• Zweck: Der zu parsende Text.
• Wann ausfüllen: Pflicht.
• Tipp: Den Output eines vorgelagerten Schritts per SmartField referenzieren — meist den responseBody einer HTTP-Anfrage. SmartFields werden vor dem Parsen aufgelöst, der Input darf also komplett aus Variablen bestehen.

Zeilen

Eine Liste von (Output-Name, Selektor)-Einträgen. Jeder Eintrag erzeugt einen oder mehrere Outputs.

• Output-Name: Name, unter dem der extrahierte Wert in Folge-Schritten verfügbar ist. Bis zu 30 Zeichen.
• Selektor: Der JsonPath-, XPath- bzw. RegEx-Ausdruck. Bis zu 2048 Zeichen.

Namespace-Overrides (nur XPath)

Die Namespace-Overrides werden nur angezeigt, wenn Parser-Typ auf XPath steht. Standardmäßig erkennt der Schritt alle Namespaces im Input automatisch und registriert sie unter den Prefixen, die das Dokument selbst verwendet. Override-Einträge haben Vorrang — sie werden nur benötigt, wenn die Auto-Discovery nicht passt.

• Prefix: Der Prefix, den du in deinen Selektoren verwendest. Bis zu 20 Zeichen.
• URI: Die Namespace-URI, auf die der Prefix abbildet. Bis zu 250 Zeichen.

Sobald die Override-Liste mindestens einen Eintrag enthält, werden ausschließlich diese Einträge registriert — die Auto-Discovery ist dann für den Schritt deaktiviert.

Output-Namensgebung

Parser-Typ	Treffer	Output
JsonPath	Skalar-Wert oder Objekt	{name}
JsonPath	Array	{name}[0], {name}[1], …
XPath	beliebige Knoten-Anzahl	{name}[0], {name}[1], …
RegEx	beliebige Match-Anzahl	{name}[0], {name}[1], …

Die Asymmetrie in der JsonPath-Zeile ist Absicht: Nur JSON erlaubt – beim Ausführen des Schritts – die eindeutige Unterscheidung zwischen Einzelwert, Objekt und Array. XPath liefert immer eine Knoten-Liste und RegEx immer eine Match-Liste — deshalb dort konsequent die indizierte Form.

Die exakten indizierten Outputs werden zur Designzeit nicht einzeln aufgeführt, weil die Anzahl erst beim Ausführen aus den Daten entsteht. Folge-Schritte greifen entweder über bekannte feste Indizes auf einzelne Werte zu oder iterieren mit einem For Each Loop-Schritt über die Liste.

Parse-Fehler

Ungültiges JSON oder XML bricht den Schritt über den Standard-Fehlerpfad ab – genau so, wie jeder andere AutoFlow-Schritt einen Fehler signalisiert. Der Execution Step wird auf Error gesetzt; der Flow folgt der Fehlerbehandlung, die du oberhalb des Schritts konfiguriert hast.

Verhalten ohne Treffer

Liefert ein Selektor keinen Treffer, wird der zugehörige benannte Output mit leerer Zeichenkette erzeugt. Das gilt einheitlich für JsonPath, XPath und RegEx, sodass Folge-Schritte den Output bedingungslos lesen können.

XML-Namespaces im Detail

XML-Payloads — vor allem SOAP-Responses — verwenden Namespaces, und XPath hat strenge Regeln, wie präfigierte Namen matchen. Der Parser bringt drei Mechanismen mit, die XML-Daten aus der echten Welt unkompliziert handhabbar machen:

1. Auto-Discovery. Der Schritt durchläuft das Dokument, sammelt alle vorkommenden Namespace-URIs ein und registriert jede unter einem Prefix in einem XmlNamespaceManager. Beim ersten Auftreten gewinnt der Prefix; verwendet ein späterer Teilbaum denselben Prefix für eine andere URI, wird die zweite URI unter einem synthetischen Suffix registriert (n → n2 → n3 → …).
2. Default-Namespace-Transparenz. Reines XPath würde /Envelope/Body/Result nicht gegen einen SOAP-Envelope mit xmlns="http://www.w3.org/2003/05/soap-envelope" matchen — XPath behandelt prefixlose Namen als "kein Namespace", die Elemente haben aber einen. Der Parser schreibt jedes prefixlose Segment deines Selektors intern auf local-name() um, sodass /Envelope/Body/Result zu /*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='Result'] wird und wie erwartet matcht.
3. Override-Liste. Wenn die Auto-Discovery nicht passt, fülle die Namespace-Overrides. Die Override-Prefixe haben Vorrang und sind in diesem Fall die einzigen registrierten Namespaces.

Wissenswerte Edge-Cases:

• Die Umschreibung prefixloser Namen behandelt /, //, Prädikate ([…]), Attribut-Prefixe (@) sowie bereits prefigierte Namen. Ungewöhnliche XPath-Konstrukte (Axis-Spezifizierer wie ancestor::, Namespace-Knoten) bleiben unverändert — registriere bei Bedarf einen expliziten Prefix-Override.
• Prädikate, die Attribute prüfen, brauchen in den meisten Dokumenten keinen Namespace, weil XML-Attribute standardmäßig "kein Namespace" haben — außer sie verwenden selbst einen Prefix.

Beispiele

REST-API-Antwort

JSON-Response einer Auftrags-API:

{
  "status": "ok",
  "order": {
    "id": "ORD-42",
    "items": [
      {"sku": "ABC", "qty": 1},
      {"sku": "DEF", "qty": 2}
    ]
  }
}

Ein Parser-Schritt mit Typ JsonPath und drei Zeilen:

Output-Name	Selektor
status	$.status
orderId	$.order.id
skus	$.order.items[*].sku

Erzeugt:

• status = ok
• orderId = ORD-42
• skus[0] = ABC
• skus[1] = DEF

SOAP-Antwort

Antwort eines Wetter-Services mit Default-Namespace:

<Envelope xmlns="http://www.w3.org/2003/05/soap-envelope">
  <Body>
    <GetWeatherResponse xmlns="http://example.com/weather">
      <Temperature>23</Temperature>
    </GetWeatherResponse>
  </Body>
</Envelope>

Mit XPath und dem Selektor /Envelope/Body/GetWeatherResponse/Temperature greifen Auto-Discovery und Default-Namespace-Umschreibung gemeinsam — Output: temperature[0] = 23. Du musst nichts an Namespaces selbst registrieren.

Text-Mining mit RegEx

Eingabetext Order ABC-123 shipped on 2026-04-15. mit RegEx-Selektor Order (\S+) shipped on (\d{4}-\d{2}-\d{2}) und Output-Name order ergibt:

• order[0] = ABC-123 (erste Capture-Group des einzigen Treffers)

Wenn du beide Groups brauchst, lege zwei Zeilen mit demselben Muster an und filtere die zweite per non-capturing wrapper, oder verarbeite den Wert in einem zweiten Parser-Schritt mit einem Datums-Pattern weiter.

Tipps

• Für SOAP-Integrationen einen Parser-Schritt direkt hinter den HTTP-Anfrage-Schritt setzen. Der responseBody der HTTP-Anfrage wird zum Input des Parsers.
• Für JSON-Arrays, über die du iterieren willst, den Array-Selektor verwenden und das Ergebnis in einen For Each Loop füttern.