13. Notification JMS: Benutzer informieren ohne Hauptprozess zu blockieren
Benachrichtigungen sind wichtig, aber sie sollen den Bestellabschluss nicht unnötig blockieren.
Ein Portal soll dem Benutzer schnell und stabil antworten. Wenn die Bestellung erfolgreich angelegt wurde, sollte eine temporär gestörte E-Mail-Komponente den Kernprozess nicht rückgängig machen. Deshalb werden Benachrichtigungen über Outbox und JMS entkoppelt.
Die Outbox wird in derselben lokalen Transaktion wie der Prozessstatus geschrieben. Ein separater Publisher liest offene Outbox-Einträge und publiziert sie an den Broker. Dadurch werden Nachrichten wiederholbar und auditierbar.
Outbox Tabelle fuer Portal Events
create table portal_outbox_event (
id varchar(36) primary key,
aggregate_type varchar(80) not null,
aggregate_id varchar(120) not null,
event_type varchar(120) not null,
correlation_id varchar(80) not null,
payload_json clob not null,
status varchar(30) not null,
created_at timestamp not null,
published_at timestamp null,
retry_count integer default 0 not null
);
OutboxRepository mit Outbox Pattern
/**
* Design Pattern: Transactional Outbox.
* Zweck: Prozessstatus und zu sendende Nachricht atomar in derselben DB speichern.
*/
public interface OutboxRepository {
void enqueueOrderAccepted(String trackingId, String userId);
List<OutboxEvent> findNextBatchForPublishing(int limit);
void markPublished(String eventId);
void markFailed(String eventId, String reason);
}
19. Observability: Logs, Metriken, Traces und fachliche Events
Ein Portalprozess über mehrere Systeme ist ohne Observability im Betrieb kaum steuerbar.
Technische Logs allein reichen nicht. Man braucht fachliche Metriken: Anzahl angenommener Bestellungen, fachliche Ablehnungen, technische Pending-Fälle, durchschnittliche SOAP-Latenz, Fault-Raten pro Backend und Retry-Erfolg.
Für SOAP ist besonders wichtig, nicht unkontrolliert komplette Payloads mit personenbezogenen oder vertraulichen Daten zu loggen. Besser sind strukturierte Logfelder, technische Metadaten und gezielte maskierte Diagnosen.
- Metrik: order_submit_success_total.
- Metrik: order_submit_business_rejected_total nach Fehlercode.
- Metrik: soap_backend_latency_seconds nach Operation.
- Trace: Portal -> Adapter -> SOAP/REST/JMS.
- Audit: fachliche Aktion mit Benutzer, Mandant und Tracking-ID.
Strukturiertes Logging ohne Payload-Leak
logger.info("portal.order.submit.completed trackingId={} correlationId={} backendOrderId={} tenant={} durationMs={}",
state.trackingId(),
state.correlationId(),
state.backendOrderId(),
state.tenant(),
duration.toMillis());
31. Betriebscheckliste für SOAP-Portal-Integration
Vor Go-Live braucht das Portal eine klare Betriebsprüfung.
- Alle SOAP Endpunkte pro Umgebung dokumentiert.
- Timeouts kleiner als Benutzer-Latenzbudget.
- Fault-Mapping mit Beispielnachrichten getestet.
- Zertifikate, Secrets und Rotation geklärt.
- Dashboards für Latenz, Fehler und Pending-Prozesse vorhanden.
- Runbook für Order SOAP Down, Billing Down, Broker Down.
32. Datenklassifikation und Logging-Regeln
SOAP Payloads enthalten oft sensible Daten und dürfen nicht unkontrolliert protokolliert werden.
- Keine vollständigen SOAP Bodies im Standardlog.
- PII maskieren oder gar nicht loggen.
- Business-IDs und technische IDs getrennt behandeln.
- Audit ist fachlich, Debuglog ist technisch.
- Supportzugriffe auf Payload-Artefakte kontrollieren.