Az Odoo fő dokumentációja szerint az örökölt RPC adatbázis szolgáltatás az Odoo 20-ban megszűnik. A szélesebb XML-RPC és JSON-RPC API-k 19.0 verzió óta elavultnak számítanak, de az Odoo 20 nem távolít el minden örökölt szolgáltatást. Az Odoo dokumentációja szerint a common és object szolgáltatások az Odoo 22-ig továbbra is elérhetők maradnak. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Az integrációs csapatoknak ezért minden külső kapcsolatnál azonosítaniuk kell, hogy melyik szolgáltatást használja, ahelyett hogy az örökölt RPC támogatást egyetlen, egyetlen eltávolítási dátummal rendelkező funkciónak tekintenék.
Az Odoo amerikai eseményoldala szerint az Odoo 20-at a San Franciscó-i eseményen, 2026. szeptember 2. és 3. között adják ki. (Oxp26 Americas Introduction ) A frissítési tervezés már most figyelembe veheti a dokumentált adatbázis-szolgáltatás eltávolítását, de az éles környezetre vonatkozó döntéseket a végleges Odoo 20 kiadási dokumentációval kell ellenőrizni.
Az eltávolítás egy konkrét szolgáltatásra vonatkozik
Az Odoo a `/xmlrpc`, `/xmlrpc/2` és `/jsonrpc` végpontokat 19.0 verziótól elavultnak jelöli. Ezeken az API-kon belül az adatbázis szolgáltatás az Odoo 20-ban megszűnik, míg a common és object szolgáltatások az Odoo 22-ig maradnak ütemezve. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Egy megtartott szolgáltatást használó integráció az Odoo 20-ra való frissítés után is működhet, de a végpont önmagában nem bizonyítja a kompatibilitást.
Egy rendszer a régi RPC interfészen keresztül különböző szolgáltatásokat használhat. Az integrációs felülvizsgálatnak ezért rögzítenie kell mind a végpontot, mind a meghívott szolgáltatást. Egy alkalmazás pusztán XML-RPC vagy JSON-RPC integrációként való leírása nem mutatja meg, hogy függ-e egy, az Odoo 20-ban eltávolított művelettől. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
A common és object szolgáltatások további elérhetősége ideiglenes. Az Odoo ezek eltávolítását az Odoo 22-re ütemezi. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) A csapatok külön kezelhetik az adatbázis-szolgáltatás hívásaira vonatkozó sürgős munkát a megtartott szolgáltatások migrációjától, de mindkettőhöz tervre van szükség.
A JSON-2 megváltoztatja a kérés szerződését
Az Odoo a JSON-2-t dokumentálja helyettesítő API-ként. A végpont formátuma `/json/2/<model>/<method>`, ahol a modell és a metódus szerepel az URL-ben. (Odoo master Docs: Reference External API) A migráció ezért többet jelent, mint egy meglévő RPC kliens alapútvonalának lecserélését. Minden műveletet hozzá kell rendelni a megfelelő modell- és metódusútvonalhoz.
A JSON-2 JSON-kérés törzsében elnevezett argumentumokat igényel, nem pozicionális RPC argumentumokat. (Odoo master Docs: Reference External API) A meglévő wrapper-ek, middleware-ek és generált kliensek feltételezhetik, hogy az argumentumok sorrendje határozza meg a jelentést. Ezeket az összetevőket egyenként felül kell vizsgálni. Egy régi kérés új végpontra irányítása nem működik, ha a kliens továbbra is pozicionális paramétereket állít össze.
Minden migrált művelethez a csapatoknak dokumentálniuk kell a JSON-2 által megkövetelt célmodellt, metódust és elnevezett argumentumokat. (Odoo master Docs: Reference External API) Ezután a kéréseket a megfelelő Odoo 20 környezetben kell tesztelni, különösen akkor, ha egy megosztott integrációs könyvtár több alkalmazás számára állít össze hívásokat. A statikus payload-összehasonlítások nem tudják megerősíteni, hogyan kezeli a szerver vagy az ügyfél a teljes kérést.
A hitelesítésnek is változnia kell
A JSON-2 bearer API-kulcsos hitelesítést használ. (Odoo master Docs: Reference External API)A migrációs munkának ki kell terjednie a kulcsgenerálásra, a biztonságos tárolásra, az engedélyezési fejléc kezelésére és a kulcscserére. A proxykat, átjárókat és klienskönyvtárakat is ellenőrizni kell, hogy továbbításkor megőrizzék-e a fejlécet. A naplózást, monitorozást és hibakezelést szintén felül kell vizsgálni, hogy a hitelesítő adatok ne kerüljenek nyilvánosságra.
A dokumentáció meghatározza a hitelesítési módszert, de minden szervezetnek el kell döntenie, hogyan illeszkednek az API-kulcsok a hitelesítő adatkezeléshez. (Odoo master Docs: Reference External API)Ez magában foglalja a kulcsokért felelősök kijelölését, annak szabályozását, hogy hol használhatók, valamint annak meghatározását, hogyan frissülnek az érintett integrációk a kulcs cseréjekor.
A bináris mezőknek külön kompatibilitási változásuk van
Az Odoo ORM változásnaplója egy újabb Odoo 20 RPC változást rögzít: a bináris mezők reprezentációja kiegészül a `BinaryValue.filename` elemmel. (Odoo master Docs: Orm Changelog)Ez elkülönül az adatbázis-szolgáltatás eltávolításától, mert a visszaadott adatokat változtatja, nem a szolgáltatás elérhetőségét. Azokat az alkalmazásokat, amelyek bináris mezőket tartalmazó válaszokat olvasnak, alakítanak át vagy érvényesítenek, be kell vonni a kompatibilitási tesztelésbe.
A változásnapló megerősíti, hogy a `filename` tag hozzáadódik, de a gyakorlati hatása az ügyféltől függ. (Odoo master Docs: Orm Changelog)A teszteknek ellenőrizniük kell, hogy a szigorú sémák, a szerializálók, a válaszösszehasonlítások és a downstream átalakítások elfogadják-e a további tagot. Azoknak az ügyfeleknek, amelyek figyelmen kívül hagyják az ismeretlen mezőket, lehet, hogy nincs szükségük módosításra, de ezt a viselkedést ellenőrizni kell, nem feltételezni.
Hogyan határozzuk meg az integrációs audit terjedelmét
Kezdje az `/xmlrpc`, `/xmlrpc/2` vagy `/jsonrpc` végpontokat használó kapcsolatok azonosításával, amelyeket az Odoo elavult végpontként jelöl. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)A leltárnak ki kell terjednie a házon belül fejlesztett alkalmazásokra, a middleware-re, az ütemezett folyamatokra és a harmadik féltől származó csatlakozókra, ahol a konfiguráció vagy a forráskód elérhető. Minden kapcsolathoz rendeljen felelőst, hogy a célja és állapota ellenőrizhető legyen.
Ezután sorolja be az egyes kapcsolatokat az örökölt szolgáltatás szerint. Az adatbázis-szolgáltatás használata Odoo 20 esetén javítást igényel, míg az általános és objektumszolgáltatás használata a dokumentáció szerint Odoo 22-ig elérhető marad. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)Ez támogatja a fokozatos tervet: először kezelje az Odoo 20 kompatibilitási problémát, majd állapítsa meg a migrációs dátumokat a fennmaradó elavult hívásokhoz.
A JSON-2-re áttérő integrációknál rögzítse a `/json/2/<model>/<method>` útvonalat, a megnevezett kérési argumentumokat és a helyettesítő interfész által megkövetelt bearer API-kulcsos hitelesítést. (Odoo master Docs: Reference External API)A teszteseteknek le kell fedniük a sikeres kéréseket, az elutasított hitelesítést, az érvénytelen megnevezett argumentumokat és a visszaadott adatok alkalmazásbeli kezelését. Adjon hozzá bináris mezős eseteket mindenütt, ahol ezek a mezők előfordulnak.
Erősítse meg a végleges Odoo 20 viselkedést
Az eltávolítás részletei az Odoo master fejlesztői dokumentációjából származnak, míg a bejelentett megjelenési időpont egy eseményoldalról jön, amely szerint az Odoo 20 a 2026. szeptemberi amerikai esemény során jelenik meg. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction)Telepítés előtt a csapatoknak újra ellenőrizniük kell a megjelent Odoo 20 verzió dokumentációját, valamint a használni kívánt pontos kiadást és buildet.
Egy elavult RPC-végpont használata önmagában nem bizonyítja, hogy egy integráció Odoo 20 alatt le fog állni, mert az általános és objektumszolgáltatások a dokumentáció szerint Odoo 22-ig elérhetők maradnak. Ezzel szemben egy korábbi verzión való sikeres működés nem bizonyítja egy adatbázis-szolgáltatásbeli hívás kompatibilitását annak eltávolítása után. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Frissítési döntési ellenőrzőlista
Mielőtt jóváhagyna egy Odoo 20 frissítést, a döntéshozóknak kérjenek egy integrációs nyilvántartást, amely minden elavult végpontot, a meghívott szolgáltatást, annak felelősét és a tervezett javítást mutatja. Az adatbázis-szolgáltatás-függőségekhez tesztelt helyettesítő megoldásnak kell tartoznia. Az általános vagy objektumszolgáltatásokon maradó integrációkhoz külön migrációs dátum szükséges, amely tükrözi az Odoo 22-ben dokumentált eltávolítást. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Az áttekintésnek meg kell erősítenie, hogy a JSON-2 implementációk az URL-ben helyezik el a modellt és a metódust, név szerinti JSON-argumentumokat használnak, és bearer API-kulccsal hitelesítenek. Bináris mezők esetén a tesztelésnek figyelembe kell vennie a `BinaryValue.filename` hozzáadását. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) Ezek az ellenőrzések megkülönböztetik az Odoo 20 azonnali adatbázis-szolgáltatás eltávolítását a fennmaradó örökölt szolgáltatások későbbi megszüntetésétől.