System-HTML: Customer Master

10. Customer Master: Kundendaten vor SOAP-Bestellung prüfen

Der Kundenstamm kann SOAP oder REST sein. Für den Prozess ist wichtig, dass er eine stabile fachliche Antwort bekommt.

Das Portal sollte nicht blind eine Bestellung an das Order-System senden, wenn der Kunde gesperrt ist oder Pflichtdaten fehlen. Deshalb prüft der Prozess typischerweise zuerst den Kundenstatus. Das kann synchron sein, weil die Antwort direkt für die Benutzerführung relevant ist.

Auch hier gilt: Der Prozess kennt nur CustomerSystemPort. Ob dahinter ein SOAP-Port, REST-Endpoint oder ein gecachter Leseservice steckt, entscheidet der Adapter.

• Kundenstatus: aktiv, gesperrt, unbekannt, Dublette.
• Adressprüfung: Lieferadresse gültig oder manuell prüfen.
• Mandantentrennung: Portalbenutzer darf Kundendaten nur im eigenen Tenant sehen.
• Caching: Stammdaten können kurzzeitig gecacht werden, Sperrstatus oft nicht.

CustomerSystemPort als fachliche Grenze

public interface CustomerSystemPort {
    CustomerSnapshot loadCustomer(String tenant, String customerNumber);
}

public record CustomerSnapshot(
    String customerNumber,
    boolean active,
    boolean blocked,
    String displayName,
    String riskClass
) {}

15. Security: Frontend-Identity, Backend-Identity und Kontextweitergabe

Das Portal übersetzt Sicherheitskontext kontrolliert. Der Benutzer ist nicht automatisch der technische SOAP-Caller.

Im Browser authentifiziert sich ein Benutzer zum Beispiel über Session, MFA oder OAuth2. Das SOAP-Backend erwartet möglicherweise mTLS, WS-Security UsernameToken, SAML Assertion oder technische Service-Credentials. Diese Welten müssen bewusst verbunden werden.

Das Portal darf keine Backend-Credentials an den Browser geben. Stattdessen ruft das Portal serverseitig die Backends auf und übergibt nur den notwendigen fachlichen Kontext: Benutzerkennung, Mandant, Rollen, Zweck der Verarbeitung und Correlation-ID.

• Browser zu Gateway: TLS, Session/OAuth2, CSRF-Schutz.
• Gateway zu Portal: validierter Principal, Mandant, Rollen.
• Portal zu SOAP: mTLS oder WS-Security, technische Credentials.
• Kontextheader: userId, tenant, purpose, correlationId.
• Audit: Wer hat wann welchen Prozess ausgelöst?

18. Correlation-ID und Tracking-ID: zwei IDs, zwei Zielgruppen

Eine Correlation-ID hilft Technik und Tracing. Eine Tracking-ID hilft Benutzer, Support und Fachbereich.

In Multi-System-Kommunikation ist Nachvollziehbarkeit entscheidend. Die Correlation-ID läuft durch Portal, SOAP Header, REST Header, JMS Properties und Logs. Sie ist technisch. Die Tracking-ID ist fachlich sichtbar und kann dem Benutzer angezeigt werden.

Beide IDs gehören in den Prozessstatus. So kann der Support aus einer Portal-Meldung den technischen Trace und die Backend-Referenzen finden.

• Tracking-ID: sichtbar im Portal, stabil für Benutzer und Support.
• Correlation-ID: technisch, in Logs, Traces und Messages.
• BackendOrderId: Referenz des Order-Systems.
• InvoiceNumber: Referenz des Billing-Systems.
• ReservationId: Referenz des Inventory-Systems.

36. Mandantenfähigkeit in SOAP-Portal-Kommunikation

Mandant gehört in Security, Datenfilterung, Header und Audit.

• Tenant im Portal-Kontext validieren.
• Tenant nicht nur als UI-Feld akzeptieren.
• SOAP Header oder fachliches Feld eindeutig verwenden.
• Cross-Tenant-Zugriff in Adaptertests abdecken.
• Audit pro Tenant auswertbar halten.