Pipelines
Eine Pipeline ist die zentrale Arbeitseinheit in Orderport. Sie beschreibt, wie Bestellungen einer bestimmten Art empfangen, transformiert und zugestellt werden – eine Pipeline für Ariba-Bestellungen, eine für Shopify, eine für Ihren internen Testlauf usw.
Bestandteile einer Pipeline
| Bestandteil | Funktion |
|---|---|
| Name | Menschlicher Name, wird im Dashboard und in Logs angezeigt |
| Eingabeformat | Was erwartet die Pipeline? (cXML, Shopware 6, EDIFACT …) |
| Ausgabeformat | Was soll am Ende rauskommen? (openTrans, JSON …) |
| Mapping-Regeln | Feld-für-Feld-Zuordnung zwischen Eingabe und Ausgabe |
| Inbound-Credentials (0..n) | Wer darf Bestellungen einliefern? |
| Transporte (1..n) | Wohin wird die transformierte Bestellung zugestellt? |
| Status | Aktiv oder inaktiv |
| Webhook-URL | Eindeutige URL, über die Bestellungen empfangen werden |
Jede Pipeline ist eigenständig – sie hat ihre eigene URL, eigene Credentials und eigene Transporte. Mehrere Pipelines können unabhängig voneinander laufen.
Lebenszyklus
Anlage → (konfigurieren) → Aktiv → Deaktiviert → gelöscht
- Anlage: Pipeline wird erstellt, ist zunächst inaktiv. Ohne Aktivierung nimmt sie keine Bestellungen an.
- Aktivierung: Per Toggle auf der Detailseite. Voraussetzung: mindestens 1 aktiver Transport. Das System stellt das sicher, der Aktivierungs-Button ist sonst ausgegraut.
- Deaktivierung: Jederzeit möglich. Eingehende Webhook-Aufrufe antworten dann mit HTTP 403 und Audit-Log-Eintrag. Bereits empfangene, aber noch nicht zugestellte Nachrichten bleiben in der Queue und werden weiterverarbeitet.
- Löschen: Löscht die Pipeline inklusive aller Credentials und Transporte. Bereits verarbeitete Bestellungen bleiben erhalten (Audit / Forensik).
Typische Konfigurationen
Eine Pipeline pro Einkäufer
Sinnvoll bei cXML: ein großer Einkäufer (z. B. „Daimler Ariba Produktion"), dessen Bestellungen eine eigene Pipeline bekommen – eigene Webhook-URL, eigene Credentials, ggf. eigene Mapping-Regeln.
Eine Pipeline pro Ausgangs-Zielsystem
Sinnvoll, wenn Sie mehrere Shops betreiben: „Shopware 6 Shop A" schreibt an ERP-System 1, „Shopware 6 Shop B" an ERP-System 2 – zwei Pipelines mit unterschiedlichen Transporten.
Eine Pipeline pro Test-/Produktions-Stufe
Sinnvoll während Einführungsphasen: „Produktion" mit echtem ERP-Transport, „Test" mit E-Mail-Transport an eine Testadresse. Der Absender entscheidet über die URL, an welche Pipeline er liefert.
Aktivierungs-Voraussetzungen
Eine Pipeline lässt sich aktivieren, sobald sie:
- mindestens einen aktiven Transport hat
- ein gültiges Mapping oder eine Integration mit Auto-Map-Defaults
Credentials sind nicht zwingend. Eine Pipeline kann ohne Credential aktiv sein – sie akzeptiert dann alle eingehenden Requests mit gültigem Token. Für Produktivbetrieb sollten Sie aber immer mindestens eine Credential hinzufügen.
Standard-Verhalten bei Updates (update_behavior)
Pipelines kennen ein Verhalten, das bestimmt, was passiert, wenn eine aktualisierte Bestellung eintrifft (cXML type="update"):
- retransmit (Default): Die Update-Nachricht wird neu transformiert und zugestellt. Ihr Zielsystem erhält die aktualisierte Bestellung als neue Nachricht.
Weitere Verhalten (z. B. „notify only") sind in Planung.
Technische Details
Eingabe- und Ausgabe-Formate
Eine Pipeline wählt genau ein Eingabe- und ein Ausgabeformat:
- Eingabe: cXML, Shopware 6, Shopify, WooCommerce, EDIFACT, openTrans, Generisches JSON
- Ausgabe: openTrans, JSON, JTL-Wawi
Nicht jede Kombination ist praktisch sinnvoll; die UI schlägt kompatible Paare automatisch vor.
Webhook-Token
Beim Anlegen der Pipeline erzeugt Orderport einen zufälligen Token, der Teil der Webhook-URL wird. Dieser Token ist nicht rotierbar – möchten Sie eine neue URL, legen Sie eine neue Pipeline an und deaktivieren die alte.
Zugriffsschutz
Jeder Pipeline-Zugriff wird doppelt geprüft: über den automatischen Mandanten-Filter und eine zusätzliche Autorisierungsprüfung. Ein unberechtigter Zugriff führt zu HTTP 403, nicht zu 200 und nicht zu 404. Mehr dazu im Mandantenmodell.