Integration von B2B-Portal mit ERP über ESB

Fehlertolerante B2B-Portal-Integration mit ERP-Kern über ESB

In Unternehmensprojekten werden B2B-Portale für Partner mit monolithischen Systemen wie ERP oder Tririga integriert. Direkte Verbindungen führen zu Race Conditions, bei denen gleichzeitige Änderungen von Portalnutzern und Kernadministratoren Daten überschreiben. Die Lösung ist ein ESB als Zwischenschicht mit einem ereignisgesteuerten Modell für bidirektionalen asynchronen Transfer.

ESB isoliert das Portal von der internen Struktur des Kerns: Es akzeptiert JSON, wandelt es in SOAP/XML oder spezifisches REST um und puffert es in Warteschlangen (RabbitMQ, Kafka), falls nicht verfügbar. Der Kern bleibt die einzige Wahrheitsquelle – Änderungen darin lösen Webhooks an den Bus für Portalaktualisierungen aus.

Probleme mit synchroner Punkt-zu-Punkt-Integration

Synchrone Aufrufe verursachen:

• Race Condition: Die letzte Anfrage überschreibt die vorherige.
• Ausfallverbreitung: Kern-Backups oder Updates unterbrechen das Portal.
• Sicherheitsrisiken: APIs werden extern ohne angemessenen Schutz exponiert.

In einem Szenario ändert ein Auftragnehmer ein Kontingent im Portal (von 10 auf 50 Objekte), während ein Administrator es im Kern ändert (auf 5 aufgrund einer Strafe). Ohne Pufferung gehen Daten verloren.

Architektur über ESB: Datenfluss

Datenfluss:

• Portal sendet JSON an ESB.
• ESB validiert, transformiert die Nutzdaten und reiht sie ein.
• Wenn der Kern verfügbar ist – Auslieferung und Bestätigung.
• Änderungen im Kern → Auslöser → Webhook an ESB → Portalaktualisierung.

Dies gewährleistet:

• Schnittstellenisolierung.
• Asynchronie mit Wiederholungsrichtlinien.
• Fehlertoleranz bei Spitzenlasten.

Code-Dokumentation: AOK-Protokoll

Um die Architektur zu wahren, verwenden Sie AOK – einen Pass in JSDoc-Kommentaren von Schlüsselmodulen. Es erfasst Zweck, Architektur, Integrationspunkte und SOLID-Konformität.

Beispiel für ein Kontingentsynchronisationsmodul:

/**
 * ====================================================================
 * | AOK-PASS: KONTINGENTSYNCHRONISATIONSMODUL |
 * ====================================================================
 *
 * @ZWECK
 * Sicherstellung der bidirektionalen Synchronisation von "Kontingent"-Parametern
 * zwischen dem Partner-Personalbereich und der Karte im Kernsystem.
 *
 * @ARCHITEKTUR
 * Akzeptiert JSON-Nutzdaten vom Partnerportal.
 * Validiert Werte (Min/Max) gemäß Konfigurationstabellen.
 * Initiiert Datensatzaktualisierungen in der Tabelle (Business Object).
 * Wenn Daten vom Business-Administrator geändert werden, löst es
 * einen Hintergrundprozess zum Zurücksenden von Daten per Webhook aus.
 *
 * @INTEGRATION
 * Endpunkt: /api/v1/sync_capacity
 * Sicherheitsmechanismus: JWT-Token-Validierung, SSL/TLS-Verschlüsselung.
 * Fehlerbehandlung: Wenn der Bus nicht verfügbar ist, aktiviert
 * eine Wiederholungsrichtlinie (3 Versuche mit 5-Minuten-Intervallen), dann Logging in Kibana.
 *
 * @SOLID_KONFORMITÄT
 * Einzelverantwortung: Das Modul ist nur für Datensynchronisation verantwortlich;
 * Bewertungsberechnungslogik ist in einem separaten Microservice isoliert.
 * ==================================================================== */

AOK minimiert das Onboarding: Neue Entwickler sehen sofort Integrationskontext, Validierung und Fehlerbehandlung.

Wichtige Implementierungskomponenten

• Warteschlangen: RabbitMQ/Kafka zur Pufferung.
• Transformationen: ESB bildet JSON → Legacy-Formate (SOAP, XML) ab.
• Auslöser: OnSave im Kern für Rückwärtssynchronisation.
• Sicherheit: JWT, TLS, Ratenbegrenzung.
• Monitoring: Logs in Kibana, Warteschlangenmetriken.

Wichtige Erkenntnisse

• Kern ist die einzige Wahrheitsquelle; Portal spiegelt Zustand über ESB wider.
• Asynchronie verhindert Ausfälle und Race Conditions.
• AOK im Code gewährleistet langfristige Wartbarkeit.
• Wiederholungsrichtlinien (3 Versuche, 5-Minuten-Intervalle) für Zuverlässigkeit.
• Isolierung reduziert Sicherheitsrisiken durch externe APIs.

— Editorial Team