Eingangsnachrichten#

Eine InboundMessage ist der Datenbankeintrag, der für jede empfangene Bestellung angelegt wird. Sie durchläuft einen klar definierten Lebenszyklus – vom Eingang über Transformation und Zustellung bis zur (oft automatisch nach 90 Tagen erfolgenden) Payload-Löschung.

Lebenszyklus#

empfangen → queued → processing → delivered
                 │
                 └→ failed → (retry) → delivered
                                    └→ permanently_failed

Statuswerte#

Sie sehen den Status im Dashboard und in der Bestellungs-Liste. Die Detailseite zeigt zusätzlich die einzelnen Transport-Logs – pro Versuch einen Eintrag mit HTTP-Status, Antwortzeit und Fehlermeldung.

Was passiert bei Duplikaten?#

Bestellungen, die als Duplikat erkannt werden (order_type=new mit bereits existierender external_order_id in derselben Pipeline), erzeugen keine neue InboundMessage. Stattdessen antwortet Orderport idempotent (HTTP 409 für JSON, Status-Code 409 im cXML-Response) und die bestehende Nachricht bleibt unverändert. Siehe Duplikatserkennung.

Retry-Strategie#

Bei fehlgeschlagener Zustellung startet Orderport automatisch neue Versuche. Der Abstand wächst mit jedem Versuch:

Nach dem 5. Fehlschlag ist der Status permanently_failed. Manuelle Wiederholung ist jederzeit möglich über die Detailseite („Erneut zustellen"). Mehr dazu in Fehlerbehebung.

Payload-Aufbewahrung#

Jede Nachricht enthält zwei Payload-Felder:

• raw_payload – das Original-Dokument wie es angekommen ist (XML/JSON/EDIFACT-Text)
• transformed_payload – das Ergebnis nach Transformation (das, was an Ihr Zielsystem geht)

Beide werden in der Datenbank gespeichert, damit Sie im Fehlerfall nachvollziehen können, was genau passiert ist. Nach 90 Tagen werden beide Felder automatisch auf NULL gesetzt – ein scheduler-getriebenes Cleanup (orders:cleanup-payloads --days=90) löscht sie. Die Nachricht selbst (Status, Timestamps, Transport-Log-Zusammenfassung) bleibt für spätere Statistik und Audit.

Eine längere Aufbewahrung ist auf Anfrage möglich, aber gegen Aufpreis (erhöhter Speicherbedarf).

Was Sie mit Bestellungen in der UI tun können#

Auf der Detailseite:

• Status ansehen inklusive aller Transport-Versuche
• Payload-Vorschau (raw und transformiert, solange nicht durch Cleanup gelöscht)
• Erneut zustellen – setzt die Nachricht zurück auf queued und triggert einen neuen Versuch
• Manuell als erledigt markieren – setzt den Status auf delivered (nur für Sonderfälle; keine neue Zustellung)

Bulk-Aktionen (mehrere Nachrichten gleichzeitig) sind in Planung.

Technische Details#

Entkoppelter Empfang und Verarbeitung#

Empfang und Transport laufen zeitlich entkoppelt: Der HTTP-Handler nimmt das Payload synchron an, prüft die Authentifizierung und antwortet dem Absender sofort (HTTP 202 bei JSON, HTTP 200 mit cXML-Response bei XML). Die eigentliche Transformation und Zustellung passiert asynchron in einer Queue. Dadurch antwortet Orderport Partnern in der Regel innerhalb weniger hundert Millisekunden, auch wenn das Zielsystem langsam ist.

Transport-Logs#

Jeder Zustellungsversuch – erfolgreich oder nicht – erzeugt einen Eintrag im Transport-Log. Er enthält:

• welcher Transport genutzt wurde
• die laufende Versuchs-Nummer
• das Ergebnis (success oder failed)
• den HTTP-Status des Zielsystems (falls zutreffend)
• die Antwortzeit in Millisekunden
• die ersten 5 000 Zeichen der Antwort
• eine Fehlermeldung bei Abbruch

Aufbewahrung#

Der Datensatz einer Nachricht bleibt dauerhaft erhalten; nur die Payload-Felder (raw + transformiert) werden nach 90 Tagen geleert. Audit-Log-Einträge laufen nach 365 Tagen ab. Beide Fristen sind auf Anfrage anpassbar. Mehr in Limits & Kontingente.

Nächste Schritte#

• Bestellungen verwalten
• Fehlerbehebung
• Duplikatserkennung
• Limits & Kontingente