Odoo API 統合ガイド: Odoo を任意のシステムに接続する

Odoo が単独で動作することはほとんどありません。企業は、eコマース プラットフォーム、支払い処理業者、配送業者、マーケティング ツール、カスタム アプリケーションに接続する必要があります。 Odoo 外部 API は、XML-RPC と JSON-RPC という 2 つのプロトコルを提供し、どのシステムでも Odoo 内のレコードをプログラム的に読み取り、作成、更新、削除できるようにします。

認証

APIキー認証

Odoo で API キーを生成します。ユーザー プロファイル、[アカウント セキュリティ]、[API キー] の順に移動します。説明的なラベルが付いたキーを作成します。 API 認証のパスワードの代わりにこのキーを使用します。このキーは、ログイン資格情報を変更せずに個別に取り消すことができます。

接続パラメータ

すべての API 呼び出しには、Odoo サーバー URL、データベース名、ユーザー名 (ログイン電子メール)、および API キーが必要です。これらは安全に保管してください。ソース コードに資格情報をハードコーディングしないでください。

XML-RPC プロトコル

接続のセットアップ

XML-RPC は、認証に /xmlrpc/2/common 、データ操作に /xmlrpc/2/object という 2 つのエンドポイントを使用します。最初に認証してユーザー ID を取得し、その後の呼び出しにその ID を使用します。

CRUD 操作

検索と読み取り: ドメイン フィルターを使用してレコードをクエリします (SQL WHERE 句と同様)。ドメインはタプルを使用します: [('state', '=', 'sale'), ('amount_total', '>', 1000)] は、1,000 ドルを超える確認済みの販売注文を検索します。

作成: フィールド値の辞書を渡します。 API は新しいレコード ID を返します。必須フィールドを含める必要があります。含めないと、呼び出しは検証エラーで失敗します。

書き込み: レコード ID と変更された値の辞書を渡して、既存のレコードを更新します。変更するフィールドのみを含めます。

リンク解除: ID によってレコードを削除します。使用には注意が必要です。依存レコードがある場合、一部のレコードは削除できません。

JSON-RPC プロトコル

JSON-RPC を使用する理由

JSON-RPC は一般に最新の統合に好まれます。JSON を使用し (XML よりも開発者にとって使いやすい)、JavaScript/TypeScript アプリケーションとよりよく連携し、大きなペイロードに対してわずかに優れたパフォーマンスを提供します。

リクエストのフォーマット

JSON-RPC 呼び出しは単一のエンドポイント /jsonrpc に送信されます。各リクエストには、標準の JSON-RPC 2.0 エンベロープ内のサービス名、メソッド、および引数が含まれます。

一般的な統合パターン

eコマース注文の同期

Shopify または WooCommerce から Odoo に注文を同期します。

1. e コマース プラットフォームからの注文 Webhook をリッスンします。
2. 顧客データを Odoo パートナー レコードにマッピングします (作成または既存のものと照合)
3. Odoo 製品にマッピングされた品目で販売注文を作成します。 4.注文を確認してフルフィルメントワークフローをトリガーします
4. 追跡情報を e コマース プラットフォームに同期します。

決済プロセッサの統合

Stripe、PayPal、またはその他のプロセッサを接続します。

1. 支払い確認 Webhook を受信する
2. 参照番号に基づいて支払いを Odoo 請求書と照合します。
3. Odoo Accounting に支払いを登録します
4. 銀行取引明細書と自動的に照合する

CRM の同期

Odoo CRM を外部マーケティング ツールと同期させます。

1. マーケティング プラットフォームからの新しいリードが Odoo のリードを生み出す
2. リードスコアの更新は双方向にフローします
3. 獲得した機会により、マーケティング ツールでフォローアップ キャンペーンがトリガーされます
4. 連絡先情報はシステム間で常に同期されます

エラー処理

一般的なエラー

• アクセスが拒否されました: 無効な資格情報または不十分な権限
• 検証エラー: 必須フィールドが欠落しているか、値が無効です。
• レコードが見つかりません: 存在しない ID を参照しています
• 同時更新: 別のユーザーが同時にレコードを変更しました

ベストプラクティス

1. 一時的な障害に対する指数バックオフを備えた 再試行ロジックの実装
2. 送信前にデータを検証してエラーを早期に発見する
3. デバッグと監査の目的で すべての API 呼び出しをログに記録
4. レート制限の処理 — 個別の呼び出しではなくバッチ操作
5. べき等操作を使用して、失敗した呼び出しを安全に再試行します

パフォーマンスの最適化

• バッチ読み取り: 個別の search + read 呼び出しの代わりに search_read を使用します。
• フィールドを制限: モデル上のすべてのフィールドではなく、必要なフィールドのみをリクエストします
• ページネーション: 大きな結果セットには limit と offset を使用します
• キャッシュ: ゆっくりと変化するデータ (製品カタログ、通貨レート) をローカルにキャッシュします。

Webhook パターン

Odoo には、すべてのバージョンにネイティブのアウトバウンド Webhook があるわけではありません。一般的なアプローチ:

• 自動アクション: レコードの変更時にトリガーされ、外部 URL を呼び出すサーバー アクション
• カスタム コントローラー: 外部システムの Webhook エンドポイントを公開する Odoo モジュールを構築します。
• ポーリング: 外部システムは、変更について一定間隔で Odoo をポーリングします (シンプルですが、リアルタイム性は低くなります)。

セキュリティに関する考慮事項

• パスワードの代わりに API キーを使用
• ネットワーク レベルで IP アドレスによって API アクセスを制限
• すべての API 通信に HTTPS を使用
• 適切なアクセス権を実装 — API ユーザーには必要最小限の権限が必要です
• API キーを定期的にローテーションし、侵害されたキーを直ちに取り消します

当社の Odoo 統合サービス は、適切なエラー処理、監視、セキュリティを備えた運用グレードの統合を構築します。

よくある質問

XML-RPC と JSON-RPC のどちらのプロトコルを使用する必要がありますか?

新しいプロジェクトの場合は JSON-RPC。これは開発者にとってより使いやすく、最新のツールとの連携も良く、Odoo が目指している方向です。 XML-RPC ライブラリのサポートが向上したレガシー システムまたは言語用の XML-RPC。

REST APIはありますか?

Odoo 17+ には、RPC エンドポイントとともに REST API が含まれています。これは、JSON ペイロードを使用した標準の REST 規則に従っており、一般的に Web アプリケーションでの作業が容易です。

大規模なデータの移行はどのように処理すればよいですか?

初期データのロードでは、CSV インポート機能を使用するか、バッチごとにエラー処理を備えたバッチ (バッチあたり 100 ～ 500 レコード) でレコードを作成する移行スクリプトを作成します。

カスタム エンドポイントを使用して API を拡張できますか?

はい。標準 API ではカバーされていない特殊な操作のための追加の HTTP エンドポイントを公開するコントローラー クラスを含むカスタム Odoo モジュールを作成します。