Die Master-Dokumentation von Odoo sagt, dass der veraltete RPC-Datenbankdienst in Odoo 20 entfernt wird. Die breiteren XML-RPC- und JSON-RPC-APIs sind seit Version 19.0 veraltet, aber Odoo 20 entfernt nicht jeden Legacy-Dienst. Odoo dokumentiert, dass die Dienste common und object bis Odoo 22 verfügbar bleiben. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Integrationsteams müssen daher den von jeder externen Verbindung verwendeten Dienst identifizieren, statt die Unterstützung für Legacy-RPC als eine einzige Funktion mit einem einzigen Entfernungsdatum zu behandeln.
Auf der Americas-Veranstaltungsseite von Odoo hieß es, dass Odoo 20 während der Veranstaltung in San Francisco am 2. und 3. September 2026 veröffentlicht wird. (Oxp26 Americas Introduction) Die Upgrade-Planung kann die dokumentierte Entfernung des Datenbankdienstes jetzt berücksichtigen, aber Produktionsentscheidungen sollten mit der endgültigen Odoo-20-Release-Dokumentation abgeglichen werden.
Die Entfernung gilt für einen bestimmten Dienst
Odoo nennt `/xmlrpc`, `/xmlrpc/2` und `/jsonrpc` als veraltete Endpunkte, die seit Version 19.0 deprecated sind. Innerhalb dieser APIs wird der Datenbankdienst in Odoo 20 entfernt, während die Dienste common und object bis Odoo 22 erhalten bleiben sollen. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Eine Integration, die einen beibehaltenen Dienst verwendet, kann nach einem Odoo-20-Upgrade weiter funktionieren, aber der Endpunkt allein bestätigt keine Kompatibilität.
Ein System kann über die Legacy-RPC-Schnittstelle unterschiedliche Dienste verwenden. Eine Integrationsprüfung sollte daher sowohl den Endpunkt als auch den aufgerufenen Dienst dokumentieren. Eine Anwendung nur als XML-RPC- oder JSON-RPC-Integration zu beschreiben, zeigt nicht, ob sie von einer in Odoo 20 entfernten Operation abhängt. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Die weitere Verfügbarkeit der Dienste common und object ist nur vorübergehend. Odoo plant, beide in Odoo 22 zu entfernen. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Teams können dringende Arbeiten an Aufrufen des Datenbankdienstes von der Migration der beibehaltenen Dienste trennen, aber beides erfordert einen Plan.
JSON-2 ändert den Request-Vertrag
Odoo dokumentiert JSON-2 als Ersatz-API. Das Endpunktformat lautet `/json/2/<model>/<method>`, wobei Modell und Methode in der URL enthalten sind. (Odoo master Docs: Reference External API) Die Migration umfasst daher mehr als das Ersetzen des Basispfads in einem vorhandenen RPC-Client. Jede Operation muss der passenden Modell- und Methodenroute zugeordnet werden.
JSON-2 erfordert benannte Argumente in einem JSON-Request-Body statt positionsabhängiger RPC-Argumente. (Odoo master Docs: Reference External API) Bestehende Wrapper, Middleware und generierte Clients gehen möglicherweise davon aus, dass die Reihenfolge der Argumente die Bedeutung bestimmt. Diese Komponenten müssen einzeln geprüft werden. Das Weiterleiten einer Legacy-Anfrage an den neuen Endpunkt funktioniert nicht, wenn der Client weiterhin positionsabhängige Parameter erzeugt.
Für jede migrierte Operation sollten Teams das Zielmodell, die Methode und die von JSON-2 benötigten benannten Argumente dokumentieren. (Odoo master Docs: Reference External API) Requests sollten anschließend in der relevanten Odoo-20-Umgebung getestet werden, besonders wenn eine gemeinsame Integrationsbibliothek Aufrufe für mehrere Anwendungen erzeugt. Statische Payload-Vergleiche können nicht bestätigen, wie Server oder Client die vollständige Anfrage verarbeiten.
Auch die Authentifizierung muss sich ändern
JSON-2 verwendet Bearer-API-Key-Authentifizierung. (Odoo master Docs: Reference External API) Die Migrationsarbeit sollte die Schlüsselerstellung, sichere Speicherung, die Verarbeitung des Autorisierungs-Headers und den Schlüsselaustausch abdecken. Proxys, Gateways und Client-Bibliotheken sollten geprüft werden, um sicherzustellen, dass sie den Header beim Weiterleiten von Anfragen beibehalten. Auch Protokollierung, Monitoring und Fehlerbehandlung sollten überprüft werden, damit keine Anmeldedaten offengelegt werden.
Die Dokumentation legt die Authentifizierungsmethode fest, aber jede Organisation muss selbst bestimmen, wie API-Schlüssel in ihre Kontrollen für Anmeldedaten passen. (Odoo master Docs: Reference External API) Dazu gehört, die Verantwortung für Schlüssel zuzuweisen, zu steuern, wo sie verwendet werden dürfen, und festzulegen, wie betroffene Integrationen aktualisiert werden, wenn ein Schlüssel ersetzt wird.
Binärfelder haben eine separate Kompatibilitätsänderung
Das ORM-Änderungsprotokoll von Odoo verzeichnet eine weitere RPC-Änderung in Odoo 20: Die Darstellung von Binärfeldern ergänzt `BinaryValue.filename`. (Odoo master Docs: Orm Changelog) Dies ist getrennt von der Entfernung des Datenbankdienstes, weil sich die zurückgegebenen Daten ändern und nicht die Verfügbarkeit des Dienstes. Anwendungen, die Antworten mit Binärfeldern lesen, umwandeln oder validieren, sollten in die Kompatibilitätstests einbezogen werden.
Das Änderungsprotokoll bestätigt, dass das Mitglied `filename` hinzugefügt wird, aber die praktische Auswirkung hängt vom Client ab. (Odoo master Docs: Orm Changelog) Tests sollten prüfen, ob strenge Schemata, Serialisierer, Antwortvergleiche und nachgelagerte Transformationen das zusätzliche Mitglied akzeptieren. Clients, die unbekannte Felder ignorieren, benötigen möglicherweise keine Anpassung, aber dieses Verhalten sollte verifiziert und nicht angenommen werden.
So grenzen Sie das Integrationsaudit ein
Beginnen Sie mit der Identifizierung von Verbindungen, die `/xmlrpc`, `/xmlrpc/2` oder `/jsonrpc` verwenden, die Odoo als veraltete Endpunkte kennzeichnet. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Das Inventar sollte intern entwickelte Anwendungen, Middleware, geplante Prozesse und Drittanbieter-Konnektoren abdecken, bei denen Konfiguration oder Quellcode verfügbar sind. Weisen Sie jeder Verbindung einen Verantwortlichen zu, damit Zweck und Status überprüft werden können.
Klassifizieren Sie anschließend jede Verbindung nach dem jeweiligen Legacy-Dienst. Die Nutzung des Datenbankdienstes erfordert für Odoo 20 eine Korrektur, während die Nutzung der Common- und Object-Dienste laut Dokumentation bis Odoo 22 weiterhin verfügbar bleibt. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Das unterstützt einen schrittweisen Plan: Beheben Sie zuerst die Inkompatibilität in Odoo 20, und legen Sie dann Migrationsdaten für die verbleibenden veralteten Aufrufe fest.
Für Integrationen, die zu JSON-2 wechseln, dokumentieren Sie die Route `/json/2/<model>/<method>`, die benannten Request-Argumente und die Bearer-API-Key-Authentifizierung, die die Ersatzschnittstelle erfordert. (Odoo master Docs: Reference External API) Testfälle sollten erfolgreiche Anfragen, abgelehnte Authentifizierung, ungültige benannte Argumente und die Verarbeitung der zurückgegebenen Daten durch die Anwendung abdecken. Fügen Sie Binärfeld-Fälle überall dort hinzu, wo solche Felder vorkommen.
Das endgültige Verhalten von Odoo 20 bestätigen
Die Angaben zur Entfernung stammen aus der Entwicklerdokumentation von Odoo, während der angekündigte Veröffentlichungstermin von einer Veranstaltungsseite stammt, auf der steht, dass Odoo 20 während des Americas-Events im September 2026 veröffentlicht wird. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) Vor der Bereitstellung sollten Teams die Dokumentation für die veröffentlichte Odoo-20-Version sowie die genaue Edition und den Build, den sie verwenden wollen, erneut prüfen.
Die Verwendung eines veralteten RPC-Endpunkts beweist für sich allein nicht, dass eine Integration in Odoo 20 nicht mehr funktioniert, weil die Common- und Object-Dienste laut Dokumentation bis Odoo 22 verfügbar bleiben. Umgekehrt bedeutet ein erfolgreicher Betrieb auf einer früheren Version nicht, dass ein Datenbankdienst-Aufruf nach seiner Entfernung kompatibel bleibt. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Checkliste für Upgrade-Entscheidungen
Vor der Freigabe eines Upgrades auf Odoo 20 sollten Entscheidungsträger ein Integrationsverzeichnis anfordern, das jeden veralteten Endpunkt, den aufgerufenen Dienst, den Verantwortlichen und die geplante Behebung aufführt. Abhängigkeiten vom Datenbankdienst sollten einen getesteten Ersatz haben. Integrationen, die weiterhin auf Common- oder Object-Diensten laufen, sollten ein separates Migrationsdatum erhalten, das ihre dokumentierte Entfernung in Odoo 22 widerspiegelt. (Odoo master Docs: Reference External API; Odoo master Docs: Referenz zur externen RPC-API)
Die Überprüfung sollte bestätigen, dass JSON-2-Implementierungen das Modell und die Methode in der URL platzieren, benannte JSON-Argumente verwenden und sich mit einem Bearer-API-Schlüssel authentifizieren. Wenn Binärfelder vorhanden sind, sollte das Testen die Ergänzung von `BinaryValue.filename` berücksichtigen. (Odoo master Docs: Externe API-Referenz; Odoo master Docs: ORM-Änderungsprotokoll) Diese Prüfungen unterscheiden die unmittelbare Entfernung des Odoo-20-Datenbankdienstes von der späteren Abschaltung der verbleibenden Legacy-Dienste.