Middleware - co to jest i po co w e-commerce

Co konkretnie robi middleware

Middleware odpowiada za cztery rzeczy, których ani sklep, ani ERP nie chcą robić:

1. Mapowanie danych. Sklep ma price_net, ERP ma CenaNetto, PIM ma pricing.net.default. Middleware tłumaczy jedno na drugie.
2. Kolejkowanie. ERP nie przyjmie 4000 zamówień naraz w Black Friday. Middleware buforuje i podaje w tempie, które ERP przetrawi.
3. Powtórzenia i błędy. ERP zwrócił 500 albo timeout. Middleware ponawia z backoffem, zamiast gubić zamówienie.
4. Logowanie. Gdy klient dzwoni, że zamówienie nie doszło, w middleware widzisz payload, godzinę i odpowiedź ERP-a. W integracji bezpośredniej najczęściej nie widzisz nic.

Piąta rzecz jest niewidoczna, a najważniejsza: middleware odcina sklep od zmian w ERP. Aktualizacja Comarcha zmienia strukturę pola - poprawiasz mapowanie w jednym miejscu, nie w sklepie i nie w BaseLinkerze osobno.

Middleware ERP - najczęstszy przypadek

W polskim B2B middleware prawie zawsze pojawia się przy ERP-ie, bo to najbardziej oporny system w całym układzie. Comarch ERP XL, enova365 czy Subiekt GT mają API, ale każde inne, każde z własnymi limitami i każde napisane pod księgowość, nie pod sklep.

Typowy podział pracy wygląda tak:

[Sklep] <--> [MIDDLEWARE] <--> [ERP]
                  |
                  +--> [PIM]
                  +--> [WMS]
                  +--> [BaseLinker / marketplace]
                  +--> [kurierzy]

Sklep zna jeden endpoint. Middleware zna sześć systemów. Gdy dochodzi siódmy, sklep się nie zmienia.

Jak wygląda integracja bez middleware

Bezpośrednio, czyli sklep gada z ERP-em po REST. Na starcie to jest szybsze i tańsze - i przez pierwszy rok ma sens.

Problem przychodzi z liczbą systemów. Przy dwóch systemach masz jedno połączenie. Przy pięciu - potencjalnie dziesięć. Logika mapowania rozłazi się po pluginach sklepu, a przy migracji platformy przepisujesz wszystko od nowa, bo integracje siedzą w kodzie sklepu.

Rozwinięcie tego kompromisu, z liczbami i progami decyzyjnymi, jest tutaj: middleware czy integracja bezpośrednia.

Kiedy middleware jest potrzebny

• Integrujesz 3 lub więcej systemów poza sklepem
• Masz więcej niż jeden sklep albo jeden sklep i marketplace'y
• ERP nie wyrabia z wolumenem i potrzebujesz bufora
• Wymieniasz dane z kontrahentami po EDI
• Planujesz migrację platformy i nie chcesz przepisywać integracji
• Potrzebujesz audytu - kto, kiedy i jakie dane wysłał

Kiedy middleware to przerost formy

Częstszy błąd niż brak middleware jest odwrotny: budowanie go „na zapas”.

Sklep z jedną integracją do ERP-a i 800 zamówieniami miesięcznie nie potrzebuje warstwy pośredniej. Dostaje za to dodatkowy serwer do utrzymania, kolejny punkt awarii i osobę, która musi to umieć debugować o 22:00.

Zdarzają się wdrożenia, w których middleware kosztuje więcej niż sam sklep, a obsługuje dwa endpointy. Próg opłacalności to zwykle trzeci system albo drugi kanał sprzedaży - wcześniej to koszt bez zwrotu.

Druga pułapka: middleware nie naprawia złego API po stronie ERP-a. Jeśli Subiekt oddaje stany magazynowe raz na 15 minut, middleware nie zrobi z tego czasu rzeczywistego. Przełoży tylko problem w inne miejsce.

Pokrewne pojęcia

• EDI - Electronic Data Interchange
• PIM - Product Information Management
• OMS - Order Management System

Co dalej

• Middleware czy integracja bezpośrednia - progi decyzyjne i koszty
• Integracje w e-commerce B2B - filar z pełnym przeglądem
• Integracja z Comarch ERP
• Słownik B2B