# 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**](/docs/http) | Einfache ERP-Importer mit XML-Body | Basic Auth oder keine | – |
| [**REST API**](/docs/rest-api) | Moderne APIs mit JSON, OAuth, Custom Header | Basic / Bearer / OAuth / API-Key | – |
| [**E-Mail**](/docs/email) | Manuelle Übernahme oder E-Mail-Importer (z. B. JTL-Wawi) | – | `delivery_email` |
| [**FTP/SFTP**](/docs/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:

1. Primärer Transport (Priority 0) wird versucht
2. Erfolg? → fertig. Fehler? → nächster Transport (Priority 1) wird versucht
3. 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](/docs/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](/docs/http), [REST API](/docs/rest-api), [E-Mail](/docs/email), [FTP & SFTP](/docs/ftp-sftp)
- [Zugangsdaten](/docs/credentials) – Auth-Typen im Detail
- [Fehlerbehebung](/docs/fehlerbehebung) – Retry und Recovery