BaseLinker ↔ ERP: synchroniczna czy asynchroniczna integracja?

Większość integracji BaseLinker ↔ ERP (Comarch, Optima, Subiekt, SAP) zaczyna się od pytania: jak często synchronizować i w którą stronę?. To pytanie jest niewłaściwe. Właściwe brzmi: co się dzieje, gdy jedna strona nie odpowiada?

Tu zaczyna się różnica między integracją synchroniczną a asynchroniczną. I jest to różnica, która w produkcji wraca co tydzień.

flowchart TB
  subgraph SYNC["Synchronicznie - prosto, dopóki działa"]
    direction TB
    a1["Zamówienie"] --> b1["BaseLinker / middleware"]
    b1 -->|"wywołanie, czeka na odpowiedź"| c1[("ERP")]
    c1 -.->|"ERP wolny lub padł = timeout, duplikat"| b1
  end
  subgraph ASYNC["Asynchronicznie - odporne na awarie"]
    direction TB
    a2["Zamówienie"] --> b2["BaseLinker / middleware"]
    b2 -->|"event"| q[["Kolejka: retry + DLQ"]]
    q --> w["Worker"]
    w --> c2[("ERP")]
    c2 -.->|"ERP padł = catch-up po powrocie"| q
  end
  classDef sync fill:#fef2f2,stroke:#b91c1c,color:#0f172a;
  classDef async fill:#ecfdf5,stroke:#15803d,color:#0f172a;
  class a1,b1,c1 sync;
  class a2,b2,q,w,c2 async;

Synchroniczna: prosta dopóki działa

W modelu synchronicznym BaseLinker (albo Wasz middleware) wywołuje API ERP w momencie zdarzenia - przyszło zamówienie → tworzymy dokument w Comarchu od razu, zmienił się stan w ERP → publikujemy do BaseLinkera w tym samym requeście.

Zalety:

• prosty kod, mało infrastruktury
• “co widać w BL, jest w ERP” - łatwe do tłumaczenia handlowcom
• debug to często jeden log po każdej stronie

Wady ujawniają się w incydencie:

• ERP padł na 15 minut → 200 zamówień nie trafiło, klient nie wie, że trzeba ponowić
• ERP odpowiada wolno (5s na request) → BL timeout, zamówienie znika z widoku, ale w ERP zostało utworzone (duplikat)
• update produktu wywołuje 12 wywołań do ERP (cena, stan, opis, kategorie) - każde to nowy timeout do obsłużenia

W praktyce synchroniczne integracje zaczynają się od czystego kodu, a kończą bałaganem retry-loopów, custom obsługi 5xx, ad-hoc cache’ów na timeoutach i Excelem “co się nie zsynchronizowało, sprawdzić ręcznie”.

Asynchroniczna: drożej na starcie, taniej na 12 miesiącu

W modelu asynchronicznym między BL a ERP siedzi kolejka komunikatów (RabbitMQ, AWS SQS, Redis Streams). Zdarzenie → wiadomość → konsument przetwarza ją w swoim tempie, z retry i DLQ (dead letter queue).

Co to daje konkretnie:

• ERP padł → wiadomości czekają w kolejce, po przywróceniu ERP catch-up automatyczny
• ERP wolny → konsumenci mogą być zwolnieni, ale nic nie ginie
• 12 wywołań do ERP per produkt → możemy je debouncować w kolejce (jedno wywołanie na 5 sekund per SKU, jeśli były zmiany)

Wady:

• infrastruktura: trzeba postawić i utrzymywać kolejkę (koszt operacyjny, monitoring)
• debug trudniejszy: zdarzenie z 14:32 zostało przetworzone o 14:34, więc kontekst nie jest “tu i teraz”
• eventual consistency: handlowiec widzi w BL stan z 30 sekund temu, w ERP sprzed 2 sekund - to jest fundamentalne w async i trzeba pogodzić z tym biznes

Reguła kciuka: kiedy które

Sync wystarcza, gdy:

• < 50 zamówień / dzień
• jedna instancja ERP, jedna BL, brak partnerów zewnętrznych
• ERP ma stabilne API z dobrym SLA (Comarch ERP XL, SAP)

Async opłaca się, gdy:

• 200 zamówień / dzień LUB > 5000 SKU z regularnymi update’ami

• wiele kanałów / partnerów konsumuje dane (BL + EDI + portal B2B + marketplace API)
• ERP jest legacy / niestabilny / wolny
• są wymagania compliance: audit log każdej publikacji (kolejka daje to za darmo, sync wymaga osobnej infrastruktury)

Najczęstszy błąd

Klient mówi: “zaczniemy od synchronicznego, asynchroniczne zrobimy później jak urośniemy”. W praktyce: migracja sync → async w działającym systemie to przepisanie 60-80% kodu integracyjnego. Bo cała logika obsługi błędów, retry, idempotencji była robiona pod założenie “wywołuję i czekam”.

Lepszy plan: jeśli wiesz, że za 12 miesięcy będziesz async, zacznij async od dnia 1, nawet jeśli kolejka będzie obsługiwała 30 wiadomości dziennie. Koszt na starcie: +20-30% czasu wdrożenia. Koszt migracji później: 3-6 miesięcy pracy.

Co my robimy

W projektach do ~200 zamówień/dzień z jednym ERP zwykle proponujemy sync (BaseLinker ↔ ERP przez middleware). W projektach z wieloma odbiorcami danych (BL + partnerzy + EDI) idziemy w async od początku - to nie jest “wczesna optymalizacja”, to dobra architektura pod realny scope.

Decyzja powinna zapaść w audycie, nie w trakcie wdrożenia.