Zielgruppe & Rolle

Rolle: Technik / Entwickler & Support | Schritt: 1 von 5 der Verarbeitungspipeline

Eingang und Übernahme

Ziel des Schritts

Neue Belege schnell starten, Doppelverarbeitung verhindern und Fehlerfälle kontrolliert nachziehen.

Eingangskanal und Ablage

Der Ablauf startet mit eingehenden Rechnungs-E-Mails. Die Nachricht und ihre Anhänge werden tenantbezogen in S3 abgelegt und im Eingangspfad mail/pending/ für die Verarbeitung bereitgestellt.

Damit ist der Beleg für das Polling sichtbar und kann in den technischen Ablauf übernommen werden.

Polling und Priorisierung

• pending: neue, noch nicht verarbeitete Belege im Eingang (mail/pending/); wird engmaschig verarbeitet (ca. alle 15 Sekunden), damit frische Eingänge schnell starten.
• processing: Belege sind bereits von einem Worker geclaimt und in Bearbeitung; dieser Zustand wird nicht direkt gepollt, sondern über den Stale-Check überwacht.
• retry: Belege mit technischem Fehler in einem vorherigen Versuch; wird in größerem Abstand verarbeitet (ca. alle 60 Sekunden), um Störfälle kontrolliert nachzuziehen.
• retry-lock: temporär blockierte Retry-Fälle mit Sperrmarker; hat ein eigenes Intervall (ca. alle 5 Minuten), um blockierte Fälle später erneut aufzunehmen.
• dead-letter: permanenter Fehlerzustand nach ausgeschöpften Wiederholungen; diese Fälle werden von mail-go zur Benachrichtigung des Nutzers verarbeitet.
• rejected-final: Endzustand nach erfolgter Benachrichtigung in Outlook.

Damit werden Lastspitzen abgefangen, ohne dass retry den Frischlauf blockiert.

Sichere Übernahme pro Beleg

Vor der Verarbeitung wird pro Beleg ein exklusiver Claim auf holderId gesetzt. Nur bei erfolgreichem Claim geht der Beleg nach processing.

Fehlerpfad während der Übernahme

Schlägt die Verarbeitung fehl, wird ein Retry-Counter geführt:

• bis einschließlich 5 Versuche: Rückführung in Retry,
• ab Versuch 6: Übergang nach DeadLetter (mit Fehlerhinweis für mail-go).

So bleiben temporäre Störungen im Lauf, ohne Endlosschleifen.

Stale-Check für hängende Verarbeitungen

Ein zyklischer Stale-Check prüft processing-Fälle über LastModified in S3.

Wenn ein Beleg im Status processing länger als 15 Minuten keine Aktualisierung in S3 hat, wird er als hängend gewertet. Der Stale-Check verschiebt ihn dann automatisch nach retry, damit ein neuer Verarbeitungsversuch starten kann.

---

Nächster technischer Schritt

Nach der erfolgreichen Übernahme folgt das Auslesen der Belegdaten: Schritt 2: Extraktion (E-Rechnung, PDF, Scan)