Integration
Druckversand
Binect- und E-POSTBUSINESS-Sendungen überwachen und nachverfolgen
Druckversand zeigt alle Briefe, die Output.Rocks über die Webhook-Typen Binect oder E-POSTBUSINESS an einen Druckdienstleister übergeben hat. Die Seite dient als Monitoring- und Eingriffsfläche für Uploads, Provider-Status, Fehler, Kosten und technische Rohantworten.
Die Seite ist nur für Benutzer mit ROLE_PRINT_DELIVERY sichtbar. In der Navigation erscheint sie, sobald für den aktuellen Mandantenkontext mindestens eine Drucksendung existiert.
Voraussetzungen
Der Druckversand entsteht aus Webhooks. Legen Sie unter Webhooks einen passenden Typ an:
| Anwendungsfall | Binect | E-POSTBUSINESS |
|---|---|---|
| Gerendertes Dokument als Brief versenden | binect-document | epostbusiness-document |
| PDF-Anhänge eines E-Mail-Prozesses als Briefe versenden | binect-email | epostbusiness-email |
Nur PDF-Dateien werden an die Druckdienstleister übergeben. Bei E-Mail-Webhooks werden alle PDF-Anhänge des E-Mail-Prozesses einzeln als Drucksendung angelegt.
Ablauf
- Ein Dokument- oder E-Mail-Prozess erreicht seine Webhook-Phase und führt einen Binect- oder E-POSTBUSINESS-Webhook aus.
- Output.Rocks legt pro PDF eine Drucksendung an, merkt sich Provider, Umgebung, Dateiname, Webhook, Quelle und den zugehörigen Render- oder E-Mail-Prozess.
- Der Upload läuft asynchron über den Workflow
print_delivery. Der übergeordnete Dokument- oder E-Mail-Prozess wartet, bis alle zugehörigen Drucksendungen vom Provider angenommen wurden. - Nach der Annahme synchronisieren geplante Jobs oder der Button Status synchronisieren die Provider-Status weiter, bis ein Endstatus erreicht ist.
- Fehlerhafte Uploads blockieren den zugehörigen Prozess und erscheinen als Manuelle Prüfung.
Liste und Filter
Die Tabelle zeigt die wichtigsten Kontrollinformationen pro Sendung.
| Spalte | Bedeutung |
|---|---|
| ID | Interne Druckversand-ID |
| Status | Provider-Status und interner Verarbeitungsstatus |
| Dienstleister / Umgebung | Binect oder E-POSTBUSINESS, jeweils test oder production |
| Dateiname | PDF-Datei, die an den Provider übergeben wurde |
| Provider Dokument-ID | ID, die der Druckdienstleister nach Annahme zurückgibt |
| Quelle | RenderingProcess oder EmailProcess PDF-Anhang |
| Webhook | Auslösender Webhook inklusive ID |
| Kosten | Provider-Kosten, sofern der Dienstleister sie zurückmeldet |
| Zuletzt synchronisiert | Zeitpunkt der letzten Statusabfrage |
Filter stehen für Dienstleister, Umgebung, Provider-Status, Verarbeitung, Quelle, Webhook-ID, RenderProcess-ID und EmailProcess-ID bereit.
Aktionen
- Aktualisieren lädt die Liste neu.
- Status synchronisieren fragt offene Binect- und E-POSTBUSINESS-Sendungen sofort ab.
- Details zeigt Status, Provider-ID, Upload-Versuche, nächste Synchronisierung, Fehler, Kosten und Rohantworten.
- Upload erneut versuchen ist möglich, solange der Provider noch keine Dokument-ID geliefert hat und die Sendung in
retry_waitodermanual_reviewsteht. - Manuell erledigen schließt eine Sendung aus
manual_review, wenn der Fall außerhalb von Output.Rocks geklärt wurde. - RP und EP springen direkt zum zugehörigen Dokument- oder E-Mail-Prozess.
Statusmodell
Provider-Status beschreiben den fachlichen Stand beim Druckdienstleister:
| Status | Bedeutung |
|---|---|
submitted | Upload wurde gestartet oder angenommen |
validated | Provider hat die Sendung validiert |
queued | Sendung wartet beim Provider auf Verarbeitung |
printing | Sendung befindet sich in Produktion |
sent | Sendung wurde versendet |
canceled | Sendung wurde storniert |
failed | Provider meldet einen Fehler |
unknown | Status konnte nicht eindeutig gemappt werden |
Die interne Verarbeitung steuert Upload, Retry und manuelle Prüfung:
| Verarbeitung | Bedeutung |
|---|---|
pending_submission | Wartet auf Upload |
submitting | Upload läuft |
accepted | Provider hat eine Dokument-ID geliefert |
retry_wait | Temporärer Fehler, nächster Upload-Versuch ist geplant |
manual_review | Manuelle Prüfung erforderlich |
done | Endstatus erreicht oder manuell erledigt |
archived | Abgeschlossene Sendung wurde archiviert |
E-POSTBUSINESS im Testmodus endet bereits bei validated, weil dort kein physischer Versand folgt. In Produktion laufen offene Sendungen weiter bis zu einem Versand- oder Fehlerstatus.
Fehler, Retry und Rohdaten
Provider-Meldungen werden als Fehler oder Warnungen gesammelt und in der Liste über ein Warnsymbol angezeigt. Die Details enthalten zusätzlich den aktuellen Fehlertext und die Rohantworten der Upload- und Statusabfragen.
Bei temporären Fehlern plant Output.Rocks automatische Upload-Retries mit Backoff ein: 60 Sekunden, 5 Minuten, 15 Minuten, 1 Stunde und danach 2 Stunden. Nach mehreren erfolglosen Versuchen oder bei Authentifizierungsfehlern wechselt die Sendung in Manuelle Prüfung.
Rohantworten werden vor der Speicherung bereinigt. Sensible Adress-, Empfänger-, Absender- und E-Mail-Felder werden maskiert. Nicht privilegierte Benutzer sehen in den Details nur, dass Rohdaten zurückgehalten wurden; Admins und Super-Admins können die bereinigten Rohantworten einsehen.
Die Standard-Aufbewahrung für Druckversand-Rohdaten beträgt 90 Tage. Danach entfernt der Archivierungsjob die Rohantworten aus der Hot-Tabelle; Status, Provider-ID, Kosten und Meldungen bleiben erhalten.
Betrieb
Der reguläre Betrieb erfolgt über geplante Aktionen:
| Aktion | Aufgabe |
|---|---|
sync-binect-print-deliveries | Synchronisiert offene Binect-Sendungen |
sync-epostbusiness-print-deliveries | Synchronisiert offene E-POSTBUSINESS-Sendungen |
archive-print-delivery-raw-payloads | Entfernt abgelaufene Rohantworten gemäß Aufbewahrungsdauer |
Offene Sendungen werden nach erfolgreichen Uploads typischerweise alle fünf Minuten erneut synchronisiert, bis ein Endstatus erreicht ist.