# 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:

1. mindestens **einen aktiven Transport** hat
2. 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](/docs/mandantenmodell).

## Nächste Schritte

- [Simple Wizard](/docs/simple-wizard)
- [Experten-Wizard](/docs/expert-wizard)
- [Feldmapping](/docs/feldmapping)
- [Zustellung](/docs/zustellung)