Od middleware do natywnego połączenia z Odoo: kiedy warto przejść i jak to zrobić bez zatrzymywania operacji

Warto usunąć middleware, gdy ta warstwa przechowuje stan, który powinien być w Odoo: publikowane zapasy, rzeczywisty status każdego zamówienia, numer śledzenia wracający do kanału. Nie warto, gdy warstwa tylko transportuje: odbiera plik i zostawia go gdzie indziej, o niczym nie decydując. To cała reguła. Dalej: kiedy uczciwa odpowiedź brzmi „nie przechodź” i jak przeprowadzić zmianę bez wstrzymywania realizacji zamówień, na przykładzie naszej własnej migracji do konektorów działających wewnątrz Odoo, na produkcji.

Ile middleware kosztuje w codziennej pracy, a nie w pieniądzach

Argument za usunięciem jednej warstwy przedstawiliśmy już przy e-fakturach w SERES z poziomu Odoo, a pogłębione porównanie znajdziesz w Odoo 19 kontra konektory z middleware. W przypadku marketplace'ów i przewoźników jest tak samo, tylko pomnożone przez dzienną liczbę zamówień: cztery zadania, których nikt nie wlicza w budżet.

Wiersz z logiem wymaga ostrzeżenia: „mamy to w Odoo” nie znaczy, że to się zapisuje. W audycie naszego konektora Mirakl funkcja rejestrująca każde wywołanie pytała if not log_model, a funkcja pomocnicza zwracała pusty recordset, gdy wszystko szło dobrze; w Odoo pusty recordset to fałsz, więc rejestrowanie nie robiło nic od pierwszego dnia. Dowód był na produkcji: sekwencja tej tabeli wciąż wynosiła NULL po miesiącach działania cronów. Dziś sprawdzamy if log_model is False.

Kiedy nie przechodzić: trzy oczywiste przypadki

1. Kilka systemów ERP. Jeśli Odoo prowadzi jedną spółkę, a inny system drugą i obie sprzedają w tych samych kanałach, middleware jest jedynym miejscem, w którym publikowany stan zapasów jest sumą obu.
2. Orkiestracja między stronami trzecimi. Jeśli przepływ to marketplace → zewnętrzny operator logistyczny → przewoźnik, a Odoo dowiaduje się dopiero na końcu, warstwa steruje systemami, które nie są Twoje.
3. Nikt, kto utrzyma Odoo. Natywny konektor to kod wewnątrz Twojego ERP. Jeśli nikt, ani wewnętrznie, ani partner Odoo, nie zajmie się tą pracą, middleware z abonamentem jest tanią opcją.

Plan migracji bez zatrzymywania operacji

Cztery kroki i jedna zasada: natywne połączenie wchodzi w trybie odczytu i nie zapisuje na zewnątrz, dopóki przez kilka dni nie czyta tego samego co middleware. Zastosowaliśmy to w czerwcu 2026, zastępując na własnej produkcji w Odoo.sh stary moduł Amazon konektorem, który wywołuje SP-API z poziomu Odoo.

1. Inwentaryzacja przepływów, z kierunkiem

Jeden wiersz na przepływ: zamówienia przychodzące, zapasy i ceny wychodzące, tracking wychodzący, anulowania i zwroty przychodzące, faktury wysyłane. Dla każdego kierunek, częstotliwość i wyzwalacz (cron, webhook lub człowiek). Marketplace Mirakl daje od ośmiu do dwunastu wierszy; przewoźnik trzy lub cztery; platforma podpisu dwa.

2. Kolejność: odczyt przed zapisem

Natywny konektor instaluje się z wyłączonymi wszystkimi zapisami do strony trzeciej: u nas globalny przełącznik plus znacznik na koncie dla każdej akcji wychodzącej. Czyta tylko zamówienia, statusy i stany magazynowe; middleware nadal zapisuje i nikt nie przerywa realizacji. Tu pojawił się pierwszy błąd przełączenia: nowy importer sprawdzał, czy zamówienie istnieje, w swojej własnej tabeli, świeżo utworzonej i pustej, a nie wśród zamówień sprzedaży, które poprzedni system już utworzył. Skutek: siedemnaście zduplikowanych, potwierdzonych zamówień sprzedaży, z których każde rezerwowało zapas po raz drugi. Poprawka polegała na wyszukaniu referencji marketplace w sale.order przed utworzeniem czegokolwiek. Reguła: deduplikuje się względem celu, nigdy względem własnej tabeli pośredniej konektora.

3. Okres równoległy z codziennym porównaniem

Tydzień lub dwa z oboma systemami czytającymi ten sam kanał i, każdego ranka, krótka lista: zamówienia zaimportowane przez jeden system, a nie przez drugi, niezgodne statusy, niedopasowane SKU. Zero przez dwa dni z rzędu, i dopiero wtedy pierwszy zapis.

4. Przełączenie kanał po kanale i zapisy tylko do przodu

Przełącza się jeden kanał, nie wszystkie. A po włączeniu zapisów tylko te, które wyzwala przejście stanu: potwierdzenie wysyłki przy zatwierdzeniu dostawy jest bezpieczne, bo zdarza się raz na zamówienie, które naprawdę wychodzi. Niebezpieczny jest cron przeglądający istniejące rekordy i wysyłający je ponownie. W naszym przełączeniu zostało 534 historycznych dostaw wykonanych i oznaczonych przez stary moduł jako „do synchronizacji”; cron ponowień je znalazł i w cztery minuty wysłał do Amazon 28 potwierdzeń wysyłki, zanim go wyłączyliśmy. Wniosek: zanim włączysz cron przeglądający, uzgodnij zaległą historię, która tkwi w stanie, jakiego ten cron szuka.

Dane historyczne: co migrować, a co zostawić tylko do odczytu

Migruje się to, co jeszcze może się zmienić: otwarte zamówienia, mapowanie SKU ↔ referencja kanału, przesyłki, których tracking nie wrócił jeszcze do marketplace, oraz trwające zwroty. Nie migruje się historii wywołań ani zamkniętych zamówień: prosi się o dostęp tylko do odczytu do panelu na okres reklamacji. W naszym przełączeniu dane biznesowe pozostały nietknięte: 1 838 zamówień sprzedaży i 13 236 produktów zostało tam, gdzie były.

Jak sprawdzić, że natywne połączenie działa, przed przełączeniem

Na prawdziwym buildzie Odoo i w sandboxie strony trzeciej, a nie na mockach. Opisaliśmy to na liczbach w testy były zielone, a konektor nie działał: konektor z 236 z 236 zielonych testów w Odoo 19, 18 i 17 miał pod spodem 32 realne błędy, a inny, ze 163 z 163, nigdy nie zapisał ani jednej linii logu. Trzy sprawdzenia, które się liczą:

• Okno synchronizacji pyta o to, co się zmieniło, nie o to, co utworzono. Popełniliśmy ten błąd dwa razy: konektor Mirakl wysyłał start_date (utworzenie) zamiast start_update_date, a konektor AliExpress filtrował po dacie utworzenia od ostatniego przebiegu. W obu zamówienie utworzone rano i wysłane po południu nie wracało do okna, a jego status w Odoo pozostawał zamrożony.
• Log ma wiersze. Po pierwszym imporcie policz rekordy modelu logu. Zero oznacza, że nic się nie zapisuje, a nie że nie ma błędów.
• Ślad jest na karcie. Z zaimportowanego zamówienia musisz dojść do zamówienia sprzedaży, dostawy i trackingu bez wychodzenia z Odoo.

Co zostaje potem: kto utrzymuje konektor w następnej wersji Odoo

To część, którą middleware Ci oszczędzał, a teraz jest Twoja. Każda wersja Odoo zmienia coś, czego dotyka konektor: w 19 read_group jest oznaczone jako przestarzałe w samym ORM; w 18 widoki list przeszły z <tree> na <list>; w 17 ir.cron bez numbercall wykonuje się raz i sam się wyłącza. Żadna z tych trzech zmian nie zgłasza błędu przy instalacji. Nasze konektory są publikowane jednocześnie dla 19, 18 i 17 i testowane na prawdziwych buildach każdej serii. Zanim przejdziesz, zdecyduj, kto wykona tę pracę: Twój zespół, partner Odoo albo autor konektora, jeśli publikuje go dla kilku wersji i migruje, gdy tylko wyjdzie nowa.

Jeśli konektor ma dotyczyć Twojego własnego oprogramowania, w konektor Odoo dla Twojego oprogramowania wyjaśniamy, jak to robimy z partnerami technologicznymi; w katalogu są te, które już rozmawiają z Amazon, Mirakl, ManoMano, AliExpress i przewoźnikami. Przy kilku kanałach kolejność przełączania zależy od tego, który kanał publikuje zapasy: omawiamy to w sprzedaży na wielu marketplace'ach z jednego Odoo i zapasach w czasie rzeczywistym dla marketplace'ów.

Lista kontrolna decyzji

• Czy middleware przechowuje zapasy, status zamówienia lub tracking, których Odoo nie ma? Jeśli tylko transportuje pliki, nie przechodź.
• Jeden ERP czy kilka sprzedających w tych samych kanałach? Czy Odoo dowiaduje się o zamówieniu na początku przepływu, czy na końcu?
• Kto przenosi konektor do następnej wersji Odoo i kiedy?
• Czy wiesz, ile rekordów historycznych tkwi w stanie, jakiego szuka cron ponowień?

Jeśli chcesz, żeby ktoś przejrzał Twój przypadek według tych kryteriów, w usługach i rozwiązaniach opisujemy, jak pracujemy.

Najczęściej zadawane pytania

Przydatne linki w FlexigoTech

Co robimy w tym temacie