Zustellung
Der Ausgangsteil einer Pipeline heißt Transport. Er entscheidet, wohin die transformierte Bestellung geht – und wie. Orderport kennt vier Transport-Typen, die Sie je nach Zielsystem wählen.
Die vier Transport-Typen im Überblick
| Typ | Eignet sich für | Authentifizierung | Addon |
|---|---|---|---|
| HTTP POST | Einfache ERP-Importer mit XML-Body | Basic Auth oder keine | – |
| REST API | Moderne APIs mit JSON, OAuth, Custom Header | Basic / Bearer / OAuth / API-Key | – |
| Manuelle Übernahme oder E-Mail-Importer (z. B. JTL-Wawi) | – | delivery_email |
|
| FTP/SFTP | Dateibasierte Importer, Dropfolder-Consumer | Passwort oder SSH-Key | delivery_ftp |
Entscheidungshilfe
Die schnelle Logik:
- Ziel ist ein HTTP-Endpoint, erwartet XML, einfache oder keine Auth → HTTP POST
- Ziel ist ein HTTP-Endpoint, erwartet JSON oder braucht OAuth → REST API
- Ziel ist ein Postfach oder ein System mit E-Mail-Import → E-Mail
- Ziel ist ein Verzeichnis auf einem (S)FTP-Server → FTP/SFTP
Im Zweifel ist REST API die flexibelste Wahl.
Mehrere Transporte pro Pipeline
Eine Pipeline kann mehrere Transporte haben. Sie werden der Reihe nach nach Priorität durchprobiert:
- Primärer Transport (Priority 0) wird versucht
- Erfolg? → fertig. Fehler? → nächster Transport (Priority 1) wird versucht
- Wenn alle Transporte im Versuch scheitern, wird die Nachricht für den nächsten Retry-Versuch vorgemerkt
Das ist nützlich für Fallbacks: Zum Beispiel primär REST API an Ihr ERP, sekundär E-Mail an einen Sachbearbeiter. Fällt die API aus, erhält der Sachbearbeiter die Bestellung als E-Mail und kann manuell eingreifen.
Die Priorität lässt sich per Drag & Drop auf der Pipeline-Detailseite anpassen.
Verbindungstest
Jeder Transport hat auf der Pipeline-Detailseite einen „Verbindung testen"-Button:
- HTTP / REST API – sendet einen Test-Request (leeres Payload). Die Antwort zeigt HTTP-Status, Antwortzeit und Body-Auszug.
- E-Mail – sendet eine Test-Mail an die konfigurierte Adresse.
- FTP/SFTP – baut Verbindung auf, listet Verzeichnisrechte.
Der Verbindungstest ist throttled auf 5 Aufrufe pro Minute, um versehentliche Testläufe nicht als DoS wirken zu lassen.
Retry-Verhalten
Wenn alle aktiven Transporte im Versuch scheitern, reiht Orderport einen Retry ein. Backoff: 1 min / 5 min / 30 min / 2 h / 24 h, maximal 5 Versuche. Dann Status permanently_failed. Details: Fehlerbehebung.
Transport-Logs
Jeder Zustellungsversuch erzeugt einen Transport-Log-Eintrag:
- Welcher Transport war dran, welcher Versuch-Index
- HTTP-Status des Zielsystems (sofern zutreffend)
- Antwortzeit in ms
- Die ersten 5 000 Zeichen der Antwort
- Fehlermeldung bei Abbruch
Sie sehen die Logs in der Bestellungs-Detailansicht. So können Sie bei Fehlschlägen sofort erkennen, welches Zielsystem welchen Fehler geworfen hat.
Technische Details
Erfolgskriterium
Ein Zustellungsversuch gilt als erfolgreich, wenn:
- HTTP / REST API: Das Zielsystem antwortet mit einem HTTP-Statuscode aus der Liste der erwarteten Codes (Default
[200, 201, 202], konfigurierbar bei REST API). - E-Mail: Der Mailserver hat die Nachricht akzeptiert. Dass das Ziel-Postfach sie tatsächlich erhält, ist SMTP-bedingt nicht nachprüfbar.
- FTP/SFTP: Die Datei wurde auf den Server geschrieben und erfolgreich umbenannt (atomarer Write via Temp-Datei + Rename).
Alles andere – Timeout, Netzwerkfehler, unerwarteter HTTP-Status, Auth-Fehlschlag – gilt als Fehler und startet die Retry-Kette.
Parallelität
Pro Nachricht läuft stets nur ein Zustellungsversuch gleichzeitig. Parallele Zustellungen an unterschiedliche Pipelines und Mandanten laufen unabhängig voneinander.
Feature-Gate pro Transport-Typ
- HTTP POST und REST API sind für alle Mandanten aktiv
- E-Mail benötigt das Addon
delivery_email - FTP/SFTP benötigt das Addon
delivery_ftp - Demo-Mandanten haben alle Transport-Typen automatisch
Nächste Schritte
- Transport-Typen im Detail: HTTP POST, REST API, E-Mail, FTP & SFTP
- Zugangsdaten – Auth-Typen im Detail
- Fehlerbehebung – Retry und Recovery