Odoo 19 a konektory z middleware: kiedy warto integrować wewnątrz Odoo

Natywny konektor w Odoo 19 się opłaca, gdy to Odoo decyduje o zapasach, zamówieniach, dostawach i fakturach: każdy status istnieje tylko raz, na karcie, na której pracuje zespół. Middleware się opłaca, gdy trzeba tylko przesyłać dane bez podejmowania decyzji operacyjnych albo gdy nikt nie będzie utrzymywał kodu wewnątrz Odoo. Jednorazowe podłączenie API nigdy nie było problemem: problemem jest utrzymanie porządku w zamówieniach, zapasach, błędach i śledzeniu, gdy operacja rośnie.

Prawdziwa różnica nie leży w API

API Amazona, Mirakl czy przewoźnika jest takie samo, kto by go nie wywoływał. Zmienia się to, kto zapisuje wynik i gdzie widzi go osoba przygotowująca zamówienie: na tym polega różnica, nie na API.

Jeśli Odoo ma rezerwować zapasy, przygotowywać zamówienia, generować dokumenty wydania, tworzyć etykiety i zwracać numer przesyłki do kanału, integracja natywna zostawia śledzenie tam, gdzie pracuje zespół. Przy warstwie pośredniej każdy krok istnieje dwa razy, a obie kopie zgadzają się tylko wtedy, gdy ktoś to sprawdzi.

Kiedy wybrać natywny konektor w Odoo

Ma to sens, gdy Odoo jest systemem nadrzędnym dla produktów, zapasów, zamówień, logistyki i fakturowania. Także wtedy, gdy potrzebujesz własnych reguł: wielu magazynów, walidacji przed wysyłką, ponowień, rejestru wywołań dla każdego zamówienia i błędów widocznych na ekranie użytkownika.

W naszych konektorach marketplace rejestr każdego wywołania to model Odoo z metodą, endpointem, parametrami, wysłaną treścią, kodem i treścią odpowiedzi, próbą oraz czasem trwania w milisekundach, z konfigurowalnym czyszczeniem. Filtruje się go jak każdą listę w Odoo, bez zewnętrznego panelu.

Kiedy middleware może wystarczyć

Jeśli przenosisz tylko proste dane między dwoma systemami, bez złożonych decyzji operacyjnych, middleware może przyspieszyć start. Także wtedy, gdy kilka systemów ERP sprzedaje w tych samych kanałach, a publikowany stan magazynowy musi być ich sumą. I przede wszystkim, gdy nikt, ani zespół wewnętrzny, ani partner Odoo, nie będzie utrzymywał kodu w ERP.

Ryzyko pojawia się wtedy, gdy zespół sprawdza trzy panele, żeby ustalić, czy zamówienie jest sprzedane, zarezerwowane, wysłane czy nieudane: tego dnia middleware przestaje przesyłać dane i zaczyna przechowywać stan.

Ile kosztuje middleware w codziennej pracy

Liczy się nie miesięczna opłata, tylko zadania, które pojawiają się, gdy tylko wchodzi warstwa pośrednia, a których nikt nie wlicza w budżet. Są cztery.

1. Podwójny master. Produkt zakłada się w Odoo, a do tego mapuje w middleware: SKU, kategorię kanału, atrybuty obowiązkowe. Każde nowe zgłoszenie, każda zmiana EAN i każdy nowy wariant to dwie edycje. W konektorze natywnym mapowanie na kanał to po prostu kolejne pole produktu w Odoo.
2. Uzgadnianie statusów. Zamówienie z marketplace ma trzy prawdy: kanału, middleware i Odoo. Gdy się rozjeżdżają (zamówienie anulowane w kanale, które w Odoo nadal rezerwuje zapasy), ktoś odkrywa to ręcznie. Gdy konektor działa w Odoo, są dwie, a status zdalny zapisuje się dokładnie tak, jak zwraca go API, przy zamówieniu sprzedaży, z godziną ostatniej synchronizacji.
3. Kto patrzy w log. Błąd wywołania żyje w panelu dostawcy, z jego użytkownikiem i jego okresem przechowywania. Kto widzi zablokowane zamówienie w Odoo, zwykle nie ma dostępu do tego panelu. Jeśli log jest modelem Odoo, widzi go ten, kto ma problem, na tym samym ekranie.
4. Aktualizacja wersji. Gdy Odoo przechodzi z 18 na 19, middleware obiecuje, że jego strona się nie zmienia. Zmienia się ta po stronie Odoo: moduł-most dostawcy, pola, które czyta, i webhooki, których oczekuje. Tę migrację i tak robisz, w tempie dostawcy, nie własnym; publikujemy jednocześnie dla 19, 18 i 17, jak opisujemy w utrzymaniu modułu w trzech wersjach.

Jeśli już płacisz za warstwę pośrednią i podejrzewasz, że jest zbędna, plan przełączania kanał po kanale znajdziesz w od middleware do natywnego połączenia w Odoo, opisanym na podstawie naszej własnej migracji Amazona na produkcji.

Gdzie gubi się śledzenie

Dokładnie w dokumencie wydania. W Odoo dokument wydania (stock.picking) dziedziczy po mail.thread, a jego stan jest śledzony, więc każde przejście do „zrobione” zostaje zapisane z datą i użytkownikiem. Z modułem dostaw numer przesyłki przewoźnika to pole samego dokumentu wydania (carrier_tracking_ref). Wszystko to jest w standardzie.

Czego Odoo w standardzie nie wie, to czy ten numer dotarł do marketplace'u. Przy middleware łańcuch zamówienie → dokument wydania → numer przesyłki → potwierdzenie do kanału rozpada się na dwie części: dwa pierwsze ogniwa w Odoo, dwa ostatnie w panelu dostawcy. Chatter dokumentu wydania mówi „zrobione”, a dowód, że kupujący zobaczył swój numer, jest w innym systemie.

Konektor natywny zamyka łańcuch w jednym miejscu. W naszym konektorze Mirakl zatwierdzenie dokumentu wydania uruchamia wysłanie numeru przesyłki, jeśli instancja ma to włączone, a wynik trafia do chattera: notatka, jeśli wysłano, druga z błędem, jeśli się nie udało, i trzecia, inna, jeśli dokument wydania nie miał numeru przesyłki i nic nie wysłano. Wywołania do Mirakl przechodzą przez bramę FlexigoTech Cloud, która nie przechowuje ani nie rejestruje tego, co przenoszą, więc to, co stało się z każdą wysyłką, zostaje w Twoim Odoo.

Natywny to też nie magia: 32 błędy przy zielonych testach

Niewygodna część dotyczy nas: „natywny” znaczy, że kod żyje w Odoo, a nie że działa. Zaudytowaliśmy własny konektor marketplace, zanim oddaliśmy go prawdziwemu sprzedawcy. Zestaw testów dawał 236 na 236 na zielono, na prawdziwych buildach Odoo.sh w 19, 18 i 17. Pod spodem było 32 prawdziwe błędy: 20 w kontrakcie z API i 12 w obsłudze wersji Odoo.

Te z kontraktu to parametry, których API wymagało, a które nie były wysyłane, oraz pola odpowiedzi czytane pod złą nazwą, które zwracają None i niczego nie zgłaszają. Cztery wyszły dopiero przy prawdziwych wywołaniach: nagłówek paginacji przychodził względny i od pierwszej strony nie importowano żadnego zamówienia; błąd 403 z powodu limitu nie miał udokumentowanego formatu i był odczytywany jako brak uprawnień, zatrzymując całą synchronizację. Te z wersji były po stronie samego Odoo: cron, który w 17 uruchamia się raz i sam się wyłącza, pole grup, które od 19 nazywa się inaczej, widok listy, który 17 odrzuca. Połowa nie dawała błędu: dawała ciszę.

Pełny przypadek (razem z drugim konektorem z 163 na 163 na zielono, który nigdy nie zapisał ani jednej linii logu) jest w testy były zielone, a konektor nie działał. Wniosek dla porównującego: stawiaj konektorowi natywnemu te same wymagania co middleware. Żeby był naprawdę zainstalowany w Twojej wersji, a nie tylko się kompilował; żeby był zweryfikowany ze specyfikacją dostawcy, a nie z własnymi mockami; i żeby wykonał co najmniej jedno prawdziwe wywołanie na rodzinę endpointów. Jeśli dziedziczysz go po kimś, lista jest w audycie odziedziczonego konektora Odoo.

Lista kontrolna decyzji

• Gdzie rezerwowane są zapasy i ile systemów przechowuje kopię stanu dostępnego?
• Kto tworzy dokument wydania i etykietę?
• Gdzie widać błąd, gdy API zawodzi, i czy widzi go ta sama osoba, która widzi zamówienie?
• Czy numer przesyłki wraca do kanału automatycznie i czy w dokumencie wydania zostaje zapis, że wrócił?
• Czy można ponowić próbę bez dublowania zamówień lub wysyłek?
• Kto zmigruje konektor, gdy wyjdzie następna wersja Odoo, i w jakim terminie?
• Czy został naprawdę zainstalowany w Twojej wersji i przetestowany na sandboxie dostawcy?

Kolejność podłączania kilku kanałów zależy od tego, który publikuje stan magazynowy: omawiamy to w sprzedaży na kilku marketplace'ach z jednego Odoo. Konektory, które już łączą się z Amazonem, Mirakl, ManoMano, AliExpress i przewoźnikami, są w katalogu oraz w integracjach i automatyzacji Odoo; jeśli chodzi o Twoje własne oprogramowanie, zobacz konektor Odoo dla Twojego oprogramowania.

Najczęstsze pytania

Przydatne linki w FlexigoTech

Co robimy w tej sprawie