Integracja portalu B2B z ERP za pośrednictwem ESB

Odporna na awarie integracja portalu B2B z rdzeniem ERP za pośrednictwem ESB

W projektach korporacyjnych portale B2B dla kontrahentów integruje się z monolitycznymi systemami, takimi jak ERP czy Tririga. Bezpośrednie połączenie prowadzi do warunków wyścigu, gdy jednoczesne zmiany wprowadzane przez użytkownika portalu i administratora rdzenia nadpisują dane. Rozwiązaniem jest ESB jako warstwa pośrednia z modelem opartym na zdarzeniach do dwukierunkowej asynchronicznej transmisji.

ESB izoluje portal od wewnętrznej struktury rdzenia: przyjmuje JSON, przekształca go w SOAP/XML lub specyficzny REST, buforuje w kolejkach (RabbitMQ, Kafka) przy niedostępności. Rdzeń pozostaje jedynym źródłem prawdy — zmiany w nim wyzwalają webhook w magistrali do aktualizacji portalu.

Problemy synchronicznej integracji point-to-point

Synchroniczne wywołania powodują:

• Warunki wyścigu: Ostatnie żądanie nadpisuje poprzednie.
• Propagacja przestojów: Kopia zapasowa lub aktualizacja rdzenia psuje portal.
• Ryzyka bezpieczeństwa: Udostępnianie API na zewnątrz bez odpowiedniej ochrony.

W scenariuszu podwykonawca zmienia limit na portalu (z 10 na 50 obiektów), administrator — w rdzeniu (do 5 z powodu kary). Bez buforowania dane są tracone.

Architektura przez ESB: przepływ danych

Przepływ danych:

• Portal wysyła JSON do ESB.
• ESB waliduje, przekształca ładunek, umieszcza w kolejce.
• Przy dostępności rdzenia — dostarczenie i potwierdzenie.
• Zmiany w rdzeniu → wyzwalacz → webhook w ESB → aktualizacja portalu.

Zapewnia to:

• Izolację interfejsów.
• Asynchroniczność z polityką ponawiania.
• Odporność na awarie przy szczytowych obciążeniach.

Dokumentowanie w kodzie: protokół AOK

Dla utrzymania architektury stosuje się AOK — paszport w komentarzach JSDoc kluczowych modułów. Ustala on cel, architekturę, punkty integracji, zgodność z SOLID.

Przykład dla modułu synchronizacji limitów:

/**
 * ====================================================================
 * | AOK PASSPORT: MODUŁ SYNCHRONIZACJI LIMITÓW |
 * ====================================================================
 *
 * @CEL
 * Zapewnienie dwukierunkowej synchronizacji parametrów „Limitów”
 * między Kontem Klienta kontrahenta a kartą w systemie Core.
 *
 * @ARCHITEKTURA
 * Przyjmuje ładunek JSON od Portalu KA.
 * Weryfikuje wartości (min/max) zgodnie z tabelą konfiguracyjną.
 * Inicjuje aktualizację rekordu w tabeli (Business Object).
 * Przy zmianie danych przez Administratora Biznesowego uruchamia
 * `Proces w tle do przekazywania danych z powrotem przez Webhook.`
 *
 * @INTEGRACJA
 * Endpoint: /api/v1/sync_capacity
 * Mechanizm ochrony: Walidacja tokenu JWT, szyfrowanie SSL/TLS.
 * Obsługa błędów: W przypadku niedostępności magistrali aktywowana jest
 * `Polityka ponawiania (3 próby w odstępach 5 min), następnie logowanie w Kibana.`
 *
 * @ZGODNOŚĆ_SOLID
 * Single Responsibility: Moduł odpowiada tylko za synchronizację danych,
 * logika obliczania ocen jest izolowana w osobnym mikrousłudze.
 * ==================================================================== */

AOK minimalizuje onboarding: nowy programista od razu widzi kontekst integracji, walidację, obsługę błędów.

Kluczowe komponenty implementacji

• Kolejki: RabbitMQ/Kafka do buforowania.
• Przekształcenia: ESB mapuje JSON → formaty legacy (SOAP, XML).
• Wyzwalacze: OnSave w rdzeniu do odwrotnej synchronizacji.
• Bezpieczeństwo: JWT, TLS, ograniczenie liczby żądań.
• Monitorowanie: Logi w Kibana, metryki kolejek.

Co jest ważne

• Rdzeń — jedyne źródło prawdy, portal odzwierciedla stan przez ESB.
• Asynchroniczność zapobiega przestojom i warunkom wyścigu.
• AOK w kodzie zapewnia długoterminową utrzymywalność.
• Polityki ponawiania (3 próby, 5-minutowy interwał) dla niezawodności.
• Izolacja zmniejsza ryzyka bezpieczeństwa zewnętrznych API.

— Editorial Team