Odoo REST と XML-RPC API の統合チュートリアル: あらゆるシステムに接続

Odoo は外部 API を通じてデータ モデル全体を公開し、e コマース プラットフォーム、CRM ツール、ビジネス インテリジェンス ソフトウェア、モバイル アプリ、カスタム アプリケーションなど、事実上あらゆるシステムとの統合を可能にします。このチュートリアルでは、コード例とベスト プラクティスを使用して、3 つの API プロトコル (XML-RPC、JSON-RPC、REST)、認証方法、CRUD 操作、および実際の統合パターンすべてについて説明します。

重要なポイント

• Odoo は、XML-RPC (最も成熟した)、JSON-RPC (ブラウザー フレンドリー)、および REST (Odoo 19、OpenAPI 準拠) の 3 つの API プロトコルを提供します。
• すべての API では、データベース名、ユーザー名、パスワードまたは API キーを使用した認証が必要です
• CRUD 操作は、すべてのプロトコルにわたって一貫したパターンに従います: 検索、読み取り、作成、書き込み、リンク解除
• ドメイン フィルターは、複雑なクエリに対してポーランド語の表記法構文を使用します。
• ページネーション、フィールド選択、バッチ操作により、大規模なデータセットのパフォーマンスを最適化します。

API プロトコルの比較

認証

XML-RPC 認証

XML-RPC 認証では、2 段階のプロセスが使用されます。つまり、認証してユーザー ID (uid) を取得し、その uid を後続の呼び出しに使用します。

認証呼び出しは、authenticate メソッドで /xmlrpc/2/common エンドポイントに到達し、データベース名、ユーザー名、パスワード、および空のオブジェクトを渡します。応答は数値のユーザー ID です。後続のすべてのデータ呼び出しでは、/xmlrpc/2/object と execute_kw メソッドが使用され、データベース、uid、パスワード、モデル名、メソッド名、および引数が渡されます。

JSON-RPC 認証

JSON-RPC は、/web/session/authenticate エンドポイントを介したセッションベースの認証を使用します。リクエストの本文は、jsonrpc: "2.0"、call のメソッド、および db、login、password を含むパラメータを含む JSON オブジェクトです。応答には、後続のリクエストを認証するセッション ID が Cookie に含まれています。

REST API 認証 (Odoo 19)

REST API は、Odoo バックエンドで生成された API キーをサポートしています。

1. [設定] > [ユーザー] > [API キー] に移動します。
2. 指定された権限を持つ新しいキーを生成します
3. Authorization: Bearer ヘッダーにキーを含めます。

REST エンドポイントは、コレクションの場合は /api/{model} のパターンに従い、個々のレコードの場合は /api/{model}/{id} のパターンに従います。

CRUD 操作

検索して読む

最も一般的な操作は、特定の条件でレコードを検索し、そのフィールド値を読み取ることです。

ドメイン フィルターは、演算子を含むポーランド語表記法 (接頭辞表記法) を使用します。

条件の結合: & (AND)、| (OR)、および ! (NOT) を接頭辞演算子として使用します。

• AND: ['&', ['state', '=', 'sale'], ['amount_total', '>', 1000]] は 1000 を超える販売注文に一致します
• OR: ['|', ['state', '=', 'sale'], ['state', '=', 'done']] はいずれかの状態に一致します
• 複合体: ['&', ['state', '=', 'sale'], '|', ['partner_id', '=', 5], ['partner_id', '=', 10]]

フィールドの選択: ペイロード サイズを削減し、パフォーマンスを向上させるために必要なフィールドのみをリクエストします。フィールド名のリストを指定して fields パラメーターを渡します。省略した場合は、すべてのフィールドが返されます。

ページネーション: offset および limit パラメーターを使用して結果をページネーションします。例: offset: 20, limit: 20 はレコード 21 ～ 40 を返します。

レコードの作成

フィールド値のディクショナリを使用して create メソッドを呼び出してレコードを作成します。必須フィールドを含める必要があります。応答は、新しく作成されたレコードの ID (またはバッチ作成の場合は ID の配列) を返します。

例: 連絡先を作成するには、少なくとも name フィールドが必要です。オプションのフィールドには、email、phone、company_id、street、city、state_id、country_id、およびカスタム フィールドが含まれます。

関連レコード (one2many または many2many) の場合は、特別なコマンド タプルを使用します。

レコードを更新する

レコード ID と変更されたフィールドのディクショナリを指定して write メソッドを呼び出して、レコードを更新します。変更する必要があるフィールドのみを含めます。省略されたフィールドは現在の値を保持します。

バッチ更新がサポートされています。ID のリストを渡して、1 回の呼び出しで複数のレコードを同じ値で更新します。

レコードの削除

レコード ID を指定して unlink メソッドを呼び出してレコードを削除します。このメソッドは成功すると True を返します。

削除には注意してください -- Odoo レコードの多くはビジネス ルールによって保護されています。たとえば、転記された請求書を削除しようとすると、エラーが発生します。代わりに適切なビジネス メソッドを使用してください (例: 削除前の button_cancel)。

現実世界の統合パターン

eコマース注文の同期

外部の e コマース プラットフォームから Odoo に注文を同期します。

1. 新しい注文のポーリング: 最後の同期タイムスタンプ以降の注文について eCommerce API をクエリします。
2. 顧客のマッチング: 電子メールで Odoo の連絡先を検索します。見つからない場合は作成する
3. 販売注文の作成: 顧客、品目、配送、支払い情報を使用して注文を作成します。
4. 注文を確認: action_confirm を呼び出して、ワークフローを通じて注文を処理します。
5. e コマースの更新: Odoo 注文参照を e コマース プラットフォームに送信します。

インベントリの同期

Odoo と外部チャネルの間で在庫レベルの同期を維持します。

1. 在庫レベルの読み取り: 場所フィルターを使用して stock.quant の search_read を呼び出します
2. 更新のプッシュ: 数量の変更を外部チャネルに送信します
3. 予約の処理: 予約済み在庫 (保留中の注文にコミット) を考慮します。
4. スケジュール同期: 精度を維持するために 15 ～ 30 分ごとに実行します

CRM リードのインポート

マーケティング プラットフォームから Odoo CRM にリードをインポートします。

1. リードの取得: マーケティング プラットフォーム API から新しいリードを取得します
2. 重複排除: 電子メールまたは電話で Odoo で既存の連絡先を検索します
3. リードの作成: ソース追跡を使用して crm.lead にレコードを作成します
4. 割り当て: Odoo のリード割り当てルールを使用するか、カスタム ロジックに基づいて割り当てます。

財務データのエクスポート

財務データをビジネス インテリジェンス プラットフォームにエクスポートします。

1. 勘定科目表のエクスポート: 勘定科目構造については account.account を読み取ります。
2. 仕訳エントリのエクスポート: 日付フィルターを使用して account.move.line を読み取ります
3. 残高のエクスポート: read_group を使用して、口座および期間ごとに残高を集計します。
4. スケジュール: 会計終了ウィンドウ後に毎日実行します。

エラー処理

一般的な API エラー

レート制限

Odoo はデフォルトでは API レート制限を強制しませんが、運用環境ではリバース プロキシ レベルでレート制限を実装する必要があります。 Odoo.sh の場合、悪用を防ぐためにデフォルトの制限が適用されます。適切なポーリング間隔とバッチ操作を使用して統合を設計します。

再試行戦略

一時的なエラーに対して指数バックオフを実装します。

1. 1 秒後に最初の再試行
2. 4 秒後に 2 回目の再試行
3. 16 秒後に 3 回目の再試行
4. 最大再試行後のログとアラート

パフォーマンスの最適化

バッチ操作

個別のレコード処理よりもバッチ操作を優先します。

• create はバッチ作成用の値ディクショナリのリストを受け入れます
• write はバッチ更新用の ID のリストを受け入れます
• ページネーションを伴う search_read は、個別の read 呼び出しよりも効率的です

フィールドの選択

不要なデータのロードを避けるために、常に fields パラメーターを指定してください。 50 列以上のモデルにすべてのフィールドを読み込むと、特に sale.order や account.move.line のようなモデルの場合、大幅なオーバーヘッドが発生します。

キャッシング

ゆっくりと変化するデータをローカルにキャッシュします。

• 製品カタログ (毎時更新)
• 顧客リスト（変更通知時に更新）
• 税率と財政状態 (毎日更新)

ECOSIRE 統合サービス

信頼性の高い統合を構築するには、外部システムと Odoo のデータ モデルの両方を理解する必要があります。 ECOSIRE の Odoo 統合サービス は、API 設計、コネクタ開発、データ マッピング、継続的な監視をカバーします。 e コマース プラットフォームに接続する組織の場合、特化された Shopify-Odoo 統合 および マーケットプレイス コネクタ が最も一般的なシナリオを処理します。

関連書籍

• Odoo API 統合ガイド
• ERP データ用の ETL パイプライン: Odoo と Shopify
• Docker Odoo 導入ガイド
• Odoo カスタム モジュール開発ガイド
• API セキュリティ: 認証と認可

新しい統合にはどの API プロトコルを選択する必要がありますか?

Odoo 19 の新しいプロジェクトの場合は、REST API を使用します。 HTTP 標準に従い、自動生成されたドキュメントがあり、認証用の API キーをサポートしています。 Odoo 17 または 18 の場合、XML-RPC は最も信頼性が高く、十分に文書化されたオプションです。 JSON-RPC は、ブラウザベースの統合または JavaScript アプリケーションに最適です。

Odoo の外部 API にはレート制限がありますか?

Odoo 自体はレート制限を強制しません。ただし、Odoo.sh の展開にはインフラストラクチャ レベルの制限があるため、セルフホスト型の展開ではリバース プロキシ (Nginx) レベルでレート制限を実装する必要があります。制限に関係なく、バッチ操作と適切なポーリング間隔を使用するように統合を設計します。

API を通じてワークフロー (注文の確認、請求書の発行) をトリガーできますか?

はい。ワークフロー メソッド名を指定して execute_kw メソッドを使用します。たとえば、sale.order で action_confirm を呼び出して確認するか、account.move で action_post を呼び出して仕訳入力を転記します。ワークフロー メソッドは、UI と同じビジネス ルールを適用します。