Główna dokumentacja Odoo podaje, że starsza usługa RPC bazy danych zostaje usunięta w Odoo 20. Szersze interfejsy XML-RPC i JSON-RPC są wycofywane od wersji 19.0, ale Odoo 20 nie usuwa każdej starszej usługi. Odoo dokumentuje, że usługi common i object pozostają dostępne do Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Zespoły integracyjne muszą więc zidentyfikować usługę używaną przez każde zewnętrzne połączenie, zamiast traktować obsługę starszego RPC jako jedną funkcję z jedną datą wycofania.
Strona wydarzenia Odoo dla obu Ameryk podała, że Odoo 20 zostanie wydane podczas wydarzenia w San Francisco w dniach 2 i 3 września 2026 roku. (Oxp26 Americas Introduction) Planowanie aktualizacji może już teraz uwzględniać udokumentowane usunięcie usługi bazy danych, ale decyzje produkcyjne należy sprawdzić względem finalnej dokumentacji wydania Odoo 20.
Usunięcie dotyczy konkretnej usługi
Odoo wskazuje `/xmlrpc`, `/xmlrpc/2` i `/jsonrpc` jako starsze punkty końcowe wycofane od wersji 19.0. W ramach tych interfejsów usługa bazy danych zostaje usunięta w Odoo 20, natomiast usługi common i object mają pozostać do Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Integracja korzystająca z zachowanej usługi może nadal działać po aktualizacji do Odoo 20, ale sam punkt końcowy nie potwierdza zgodności.
System może korzystać z różnych usług za pośrednictwem starszego interfejsu RPC. Przegląd integracji powinien więc odnotować zarówno punkt końcowy, jak i wywołaną usługę. Opisanie aplikacji wyłącznie jako integracji XML-RPC lub JSON-RPC nie pokazuje, czy zależy ona od operacji usuniętej w Odoo 20. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Dalsza dostępność usług common i object jest tymczasowa. Odoo planuje usunąć obie w Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Zespoły mogą oddzielić pilne prace związane z wywołaniami usługi bazy danych od migracji zachowanych usług, ale oba obszary wymagają planu.
JSON-2 zmienia kontrakt żądania
Odoo dokumentuje JSON-2 jako zastępczy interfejs API. Jego format punktu końcowego to `/json/2/<model>/<method>`, a model i metoda są zawarte w adresie URL. (Odoo master Docs: Reference External API) Migracja oznacza więc coś więcej niż zastąpienie bazowej ścieżki w istniejącym kliencie RPC. Każdą operację trzeba przypisać do odpowiedniej ścieżki modelu i metody.
JSON-2 wymaga nazwanych argumentów w treści żądania JSON, zamiast pozycyjnych argumentów RPC. (Odoo master Docs: Reference External API) Istniejące wrappery, oprogramowanie pośredniczące i generowani klienci mogą zakładać, że kolejność argumentów decyduje o znaczeniu. Te komponenty wymagają indywidualnego przeglądu. Przekierowanie starszego żądania do nowego punktu końcowego nie zadziała, jeśli klient nadal tworzy parametry pozycyjne.
Dla każdej zmigrowanej operacji zespoły powinny udokumentować docelowy model, metodę i nazwane argumenty wymagane przez JSON-2. (Odoo master Docs: Reference External API) Następnie należy przetestować żądania w odpowiednim środowisku Odoo 20, szczególnie gdy współdzielona biblioteka integracyjna tworzy wywołania dla kilku aplikacji. Statyczne porównania ładunków nie potwierdzą, jak serwer lub klient obsługuje całe żądanie.
Autoryzacja również musi się zmienić
JSON-2 używa uwierzytelniania kluczem API typu bearer. (Odoo master Docs: Reference External API) Prace migracyjne powinny obejmować tworzenie kluczy, bezpieczne przechowywanie, obsługę nagłówka autoryzacji oraz zastępowanie kluczy. Należy sprawdzić proxy, bramki i biblioteki klienta, aby upewnić się, że zachowują nagłówek podczas przekazywania żądań. Należy też przejrzeć logowanie, monitorowanie i obsługę błędów, aby poświadczenia nie były ujawniane.
Dokumentacja określa metodę uwierzytelniania, ale każda organizacja musi ustalić, jak klucze API wpisują się w jej kontrolę poświadczeń. (Odoo master Docs: Reference External API) Obejmuje to przypisanie odpowiedzialności za klucze, kontrolowanie, gdzie można ich używać, oraz określenie, jak zostaną zaktualizowane integracje, których dotyczy zastąpienie klucza.
Pola binarne mają osobną zmianę zgodności
Rejestr zmian ORM Odoo odnotowuje kolejną zmianę RPC w Odoo 20: reprezentacja pól binarnych dodaje `BinaryValue.filename`. (Odoo master Docs: Orm Changelog) Jest to oddzielne od usunięcia usługi bazy danych, ponieważ zmienia zwracane dane, a nie dostępność usługi. Aplikacje, które odczytują, przekształcają lub walidują odpowiedzi zawierające pola binarne, powinny zostać objęte testami zgodności.
Rejestr zmian potwierdza dodanie elementu `filename`, ale jego praktyczny wpływ zależy od klienta. (Odoo master Docs: Orm Changelog) Testy powinny sprawdzić, czy ścisłe schematy, serializatory, porównania odpowiedzi i dalsze przekształcenia akceptują dodatkowy element. Klienci, którzy ignorują nieznane pola, mogą nie wymagać zmian, ale należy to zweryfikować, a nie zakładać.
Jak określić zakres audytu integracji
Zacznij od zidentyfikowania połączeń używających `/xmlrpc`, `/xmlrpc/2` lub `/jsonrpc`, które Odoo oznacza jako przestarzałe punkty końcowe. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Inwentaryzacja powinna obejmować aplikacje tworzone wewnętrznie, oprogramowanie pośredniczące, procesy planowane oraz łączniki firm trzecich, dla których dostępna jest konfiguracja lub kod źródłowy. Przypisz właściciela do każdego połączenia, aby można było zweryfikować jego cel i status.
Następnie sklasyfikuj każde połączenie według usługi starszego typu. Korzystanie z usługi bazy danych wymaga naprawy dla Odoo 20, natomiast użycie usług common i object pozostaje udokumentowane jako dostępne do Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Wspiera to plan etapowy: najpierw zajmij się niezgodnością w Odoo 20, a następnie wyznacz daty migracji dla pozostałych przestarzałych wywołań.
Dla integracji przechodzących na JSON-2 zapisz trasę `/json/2/<model>/<method>`, nazwane argumenty żądania oraz uwierzytelnianie API-key typu bearer wymagane przez zastępczy interfejs. (Odoo master Docs: Reference External API) Przypadki testowe powinny obejmować udane żądania, odrzucone uwierzytelnianie, nieprawidłowe nazwane argumenty oraz obsługę zwróconych danych przez aplikację. Dodaj przypadki dotyczące pól binarnych wszędzie tam, gdzie te pola występują.
Potwierdź końcowe zachowanie Odoo 20
Szczegóły usunięcia pochodzą z dokumentacji deweloperskiej Odoo master, natomiast ogłoszony termin wydania pochodzi ze strony wydarzenia, która stwierdza, że Odoo 20 zostanie wydane podczas wydarzenia Americas we wrześniu 2026 roku. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) Przed wdrożeniem zespoły powinny ponownie sprawdzić dokumentację dla wydanej wersji Odoo 20 oraz dokładnej edycji i kompilacji, której zamierzają użyć.
Korzystanie z przestarzałego punktu końcowego RPC samo w sobie nie dowodzi, że integracja przestanie działać w Odoo 20, ponieważ usługi common i object pozostają udokumentowane do Odoo 22. Z drugiej strony pomyślne działanie na wcześniejszej wersji nie potwierdza zgodności wywołania usługi bazy danych po jej usunięciu. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Lista kontrolna decyzji o aktualizacji
Przed zatwierdzeniem aktualizacji do Odoo 20 decydenci powinni poprosić o rejestr integracji pokazujący każdy przestarzały punkt końcowy, wywoływaną usługę, jej właściciela i planowaną naprawę. Zależności od usługi bazy danych powinny mieć przetestowany zamiennik. Integracje pozostające przy usługach common lub object powinny mieć osobną datę migracji odzwierciedlającą ich udokumentowane usunięcie w Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Przegląd powinien potwierdzić, że implementacje JSON-2 umieszczają model i metodę w adresie URL, używają nazwanych argumentów JSON i uwierzytelniają się za pomocą klucza API typu bearer. Gdy występują pola binarne, testy powinny uwzględniać dodanie `BinaryValue.filename`. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) Te kontrole odróżniają natychmiastowe usunięcie usługi bazy danych w Odoo 20 od późniejszego wycofania pozostałych usług legacy.