René Passmann w omówieniu planu rozwoju Odoo wskazuje JSON-2 oraz planowane zastąpienie starszych interfejsów XML-RPC i JSON-RPC. To sygnał zmiany, ale nie precyzuje on, których endpointów ona dotyczy ani kiedy zostaną usunięte. Potraktuj go jako powód do audytu zależności, a nie zgodę na przepisanie każdego konektora.
Zatwierdź prace dostosowawcze, gdy udokumentowana niezgodność lub mający zastosowanie termin zakończenia wsparcia dotyczy niezbędnego procesu. Gdy ryzyko jest prawdopodobne, ale niepotwierdzone, zleć test zgodności o ograniczonym zakresie. Gdy nie potwierdzono istotnej niezgodności, monitoruj sytuację i określ, co uruchomi kolejny przegląd. Rezultatem powinny być rejestr integracji poparty dowodami i specyfikacja testów o jasno określonym zakresie, a nie zbiorcza wycena migracji bez rozróżnienia potrzeb.
Ustal, który komunikat o cyklu życia ma zastosowanie
Omówienie planu rozwoju przedstawia kierunek techniczny, a Passmann zastrzega, że taki plan jest deklaracją zamiaru, nie gwarancją. Na potrzeby budżetowania zastąp ogólne hasło „wycofywanie RPC” wskazaniem konkretnego endpointu, usługi i wdrożenia.
Komunikat Odoo o cyklu życia RPC oznacza /xmlrpc, /xmlrpc/2 i /jsonrpc jako przestarzałe. Podaje, że usługę db usunięto w Odoo 20, natomiast usługi common i object mają zostać usunięte w Odoo 22, jesienią 2028 roku, oraz w Odoo Online 21.1, zimą 2027 roku. Pozostałe kontrolery korzystające z @route(type='jsonrpc') są wyraźnie wyłączone z tego komunikatu. Nie należy więc planować migracji niestandardowego kontrolera tylko dlatego, że ktoś określa go jako JSON-RPC.
Dokumentacja przedstawia JSON-2 jako nowość w Odoo 19.0, nie należy zatem zakładać, że pojawi się dopiero przy następnej aktualizacji. Zapisz osobno wersję obecną i docelową, uwzględniając model hostingu. Przed zatwierdzeniem wydatków ponownie sprawdź właściwy komunikat, odróżniając planowane usunięcie od błędu wykazanego w docelowym wdrożeniu.
Zbuduj rejestr wokół procesów, nie nazw konektorów
Podczas webinaru o suwerenności cyfrowej ERP prelegenci wskazują model eksploatacji oraz koncentrację zależności wokół ERP jako istotne kwestie. Praktyczny wniosek: odwzoruj to, od czego zależy działalność firmy, w tym odpowiedzialność za utrzymanie, zamiast jedynie wypisywać połączone aplikacje.
Poproś właściciela biznesowego i osobę odpowiedzialną za utrzymanie techniczne każdej integracji o uzupełnienie poniższego rejestru. Tam, gdzie to możliwe, dołącz fragmenty konfiguracji, odwołania do kodu lub dokumentację podmiotu utrzymującego rozwiązanie.
- Odpowiedzialność biznesowa: właściciel procesu, wymagany rezultat, krytyczne okresy operacyjne i akceptowalny sposób działania awaryjnego.
- Wdrożenie: obecna i docelowa wersja Odoo, model hostingu, edycja, subskrypcja oraz właściwe warunki wsparcia.
- Rzeczywiście używany interfejs: endpoint, usługa RPC lub niestandardowy kontroler, aplikacja wywołująca, wersja konektora i metoda uwierzytelniania. Zapisz, kto odpowiada za dane uwierzytelniające, nie same sekrety.
- Operacje: reprezentatywne odczyty, tworzenie i aktualizowanie rekordów oraz działania biznesowe, w tym wymagane pola, niestandardowe metody i zależne moduły.
- Utrzymanie: podmiot utrzymujący konektor, opublikowana deklaracja zgodności, macierz wspieranych wersji oraz odpowiedzialność za błędy.
- Scenariusze awarii: odrzucone aktualizacje, brak odpowiedzi i ponowione żądania; kto wykrywa problem, uzgadnia dane i zatwierdza przywrócenie poprawnego działania.
Arkusz zatwierdzania modyfikacji ERP oddziela akceptację zmiany biznesowej przez właściciela procesu od odpowiedzialności technicznej za implementację, zależności i wsparcie. Tutaj impulsem jest zewnętrzna zmiana interfejsu, a nie wniosek o modyfikację. Zanim zdecydujesz, jak zachować proces, ustal, czy nadal jest potrzebny.
Odpowiedź „konektor obsługuje Odoo” jest niewystarczająca. Poproś o wskazanie właściwej, wydanej wersji konektora, docelowego wdrożenia i objętych zgodnością operacji. Jeśli odpowiedź dotyczy tylko planowanego wydania, pozostaw zgodność jako nierozstrzygniętą i wyznacz osobę odpowiedzialną za uzyskanie wersji do testów lub ocenę alternatywy.
Zleć test zgodności o ograniczonym zakresie
Dokumentacja JSON-2 Odoo określa uwierzytelnianie Bearer z użyciem klucza API oraz argumenty nazwane zamiast pozycyjnych. Dostępne modele, pola i metody zależą od konkretnej bazy danych i można je sprawdzić na jej stronie /doc. Sprawdź wymagane niestandardowe metody w docelowej bazie; nie wnioskuj o zgodności na podstawie udanego, ogólnego odczytu.
Zweryfikuj również prawo do korzystania z API. Zgodnie z udokumentowanym ograniczeniem planów komercyjnych Odoo dostęp do zewnętrznego API jest dostępny w planie Custom, ale nie w One App Free ani Standard. Potwierdź warunki właściwe dla docelowego wdrożenia, zamiast traktować to stwierdzenie jako rozstrzygnięcie zasad licencjonowania edycji Community.
Specyfikacja testów powinna wskazywać środowisko, konto integracyjne, wersję konektora, reprezentatywne dane, oczekiwane wyniki biznesowe i osoby odpowiedzialne za odbiór. Wymagaj reprezentatywnych odczytów i zapisów, sprawdzenia dozwolonego i zabronionego dostępu, wykonania niestandardowych metod oraz możliwej do zaobserwowania obsługi błędów. Zarejestruj wynikowe rekordy biznesowe, a także dowody w postaci żądań i odpowiedzi.
Hipotetyczny scenariusz odbioru: aplikacja zewnętrzna przesyła aktualizację zamówienia, ale nie otrzymuje użytecznej odpowiedzi. Poproś zespół o ustalenie, czy aktualizacja została zatwierdzona, zademonstrowanie przywrócenia poprawnego działania, ponowienie żądania w kontrolowanych warunkach i uzgodnienie danych w obu systemach. Zaliczenie testu oznacza potwierdzenie uzgodnionego stanu biznesowego i przypisanie odpowiedzialności za wyjątki, a nie tylko powodzenie kolejnego żądania.
Przyjrzyj się szczególnie zapisom wieloetapowym. Każde wywołanie JSON-2 działa we własnej transakcji SQL, zatwierdzanej przy powodzeniu i wycofywanej przy błędzie; wielu wywołań nie można połączyć w jedną transakcję. Zapytaj, co się stanie, gdy wcześniejsze wywołanie zakończy się powodzeniem, a późniejsze błędem. Wycofanie transakcji nie dowodzi, że ponawianie żądań jest bezpieczne ani że stary i nowy interfejs zachowują się równoważnie.
Oddziel monitoring, testy i potwierdzone prace dostosowawcze
Monitoruj, gdy rejestr nie wykazuje istotnej niezgodności. Zapisz uzasadnienie i określ zdarzenia uruchamiające przegląd, takie jak zmiana wersji docelowej, aktualizacja komunikatu o cyklu życia lub zmiana wsparcia ze strony podmiotu utrzymującego konektor. Niezidentyfikowany endpoint nie jest dowodem zgodności.
Testuj, gdy endpoint, sposób uwierzytelniania, niestandardowe metody lub stanowisko podmiotu utrzymującego rozwiązanie wskazują na prawdopodobne ryzyko. Zatwierdź analizę o ograniczonym zakresie, ze wskazanymi procesami i wymaganymi dowodami, zamiast przepisywania integracji bez określonych granic.
Dostosuj, gdy udokumentowana niezgodność lub mający zastosowanie termin zakończenia wsparcia dotyczy wymaganego procesu. Porównaj aktualizację do wspieranej wersji konektora, punktową zmianę adaptera i zastąpienie rozwiązania według tych samych kryteriów odbioru. Przepisanie jest uzasadnione dopiero wtedy, gdy jego zakres wynika z zależności objętych zmianą, a alternatywy nie spełniają wymagania.
Przed zatwierdzeniem wydatków przejrzyj rejestr z każdym właścicielem procesu i osobą odpowiedzialną za utrzymanie, oddzielając potwierdzone zmiany od nierozstrzygniętych założeń. Jeśli potrzebujesz wsparcia funkcjonalnego i programistycznego przy określeniu zakresu tych prac, omów procesy objęte zmianą i testy zgodności ze specjalistami Odoo w Digiventi.
