Odoo API ソリューション

なぜ私たちは1つの記事を割り当てるのですか Odoo APIソリューション ?

これらの過去の数年間、お客様からの要件が増え、専用およびサードパーティのシステムをOdoo環境に開放するために、Odoo APIシステムとXML-RPC Odoo APIインターフェースを使用することが増えてきました。

その理由は遠くありません。しかし、企業が成長し、ユースケースが増えるにつれて、標準のOdoo APIの制限が生産性に影響を与えることも気づきました。

だから、原因は何で、これが起こった場合にはどうすればいいのか？

標準のOdoo APIの制限

Odooの「箱から出してすぐに使える」APIのパフォーマンスを考えると、大量のデータフローと集中的なアクティビティを処理することはできないことがすぐにわかります。たとえば、最新バージョンのOdoo 14＆15 Enterpriseでも、カスタマイズなしの標準の販売注文で1秒あたりのワーカーあたり2〜3件以上の販売注文を作成することはすでに困難です。 Odoo 14＆15 エンタープライズ、私たちのテストでは、カスタマイズなしの標準の販売注文で1秒あたりのワーカーあたり2〜3件以上の販売注文を作成することはすでに困難です。

これは主に、POSTトランザクション（取引レジスタから総勘定元帳に移動される取引）がOdooにプッシュされた場合でも、ORMメカニズムによってOdooレベルでまだ検証する必要があるためです。中程度から大規模なデータのインポートでも同じ問題が発生します。

多くのプロジェクトが失敗したのは、Odooの開発者が最初から必要なボリュームとスピードのニーズを評価していなかったためです。しかし、クライアントは最初から通常のビジネス年度で生成される販売注文、ピッキングリスト、倉庫移動、請求書の数を知っています。

スマートフォンアプリの開発者が、標準のOdoo XML/RPC APIレイヤーを使用して数千の同時ユーザーを持つエンドユーザーアプリをパワーアップできると信じている場合、同じ理由で事態は悲劇的になります。数千の同時ユーザーを含むB2CアプリケーションでOdoo ORMの容量を超えてしまいます。

異なるスケールは異なるアーキテクチャを意味します

APIインターフェースの取り扱い方には基本的に3つの異なる方法があります。

1. The Standard Odoo “light” approach

The standard Odoo “light” approach utilizes the external API delivered by Odoo to access features and data from integration with other external tools. Developers can access it over the XML-RPC Odoo API interface, available in multiple languages such as Python, Java, PHP, and Ruby.

このアプローチの最初の利点は、すべての重い作業がOdooによって行われ、明確なドキュメントが見つかるため、実装が容易であることです。 ここ このアプローチはまた、迅速な結果を生み出し、データの整合性は、COMMIT前のOdoo標準ORMバリデーションによって保護されます。

単純に言えば、このアプローチを使用すると、ユーザーはOdooによって提供されるAPI-標準のアーキテクチャと実装-に変更を加えることなく依存します。ただし、大規模なデータ統合は許可されず、同時ユーザー数も制限されます。

標準のOdoo APIアプローチの欠点:

• 同時トランザクションとユーザーの数には限界があり、障害なく処理できます。

• システムは限られたデータ量を超えることはできません。

• スケーラブルではありません。

2. 高度なAPI統合

標準のOdoo APIアプローチは統合を簡単にしますが、より多くのトランザクションを処理する必要がある場合はどうなりますか？そのため、高度なAPI統合が必要です。

このアプローチは、標準のOdoo ORMの機能を超えています。このアプローチが機能するためには、データへのアクセスのロジックを以下のガイドラインに従って再設計する必要があります。

• エンドポイントで使用されるデータモデルとオブジェクトを作成/更新するために、Odoo ORMを使用します。

• 必要に応じて、専用のコネクタを実装し、Odoo XML/RPCの機能をバイパスします。

• パフォーマンスを向上させるために、Odooの標準API機能を別のAPIエンジンで置き換えます。

• 新しいAPIコアレベルでORMのデータ検証プロセスを統合し、検証/応答時間を高速化します。

利点と欠点

高度なAPI統合により、標準APIアプローチよりも多くの同時ユーザーを処理できます。これにより、1回の呼び出しおよび合計でより多くのデータ量を処理できます。そして、このソリューションは間違いなく、パフォーマンスに影響を与えることなく、より多くのトランザクションを受け入れます。

ユーザーが直面する最初の問題または欠点は、このアプローチがプロジェクトに新しいテックスタックを導入することであり、それにはより高い専門知識が必要です。したがって、Odoo APIは主要なソリューションである一方、アップグレードされたアーキテクチャにより、ETL（抽出、変換、ロード）が2つの異なるシステムに分割されるようになりました。ETLの一貫性を保つためには、より高いレベルの厳格さが必要です。

標準のOdoo APIで問題が発生していますか？

はい、問題があります

3. 高性能APIソリューション

今年、私たちのチームは専用の1つを提供しています 高可用性アーキテクチャシステム 南アジア市場の「トランザクションの世界」の大手プレーヤー向けに。初期のパフォーマンスと負荷要件により、1秒あたり最大1500回の挿入（POSTリクエスト）と1秒あたり最大10,000回のダウンロード（GETリクエスト）が可能です。

このような負荷では、標準のXML-RPC Odoo APIを使用した標準のOdooモジュールの指定された機能を超えています。高度なAPI統合でも、同時ユーザーによるストレスにより、Odooデータベースのパフォーマンスやトランザクションの処理能力が容易に妨害される可能性があります。

上記の理由から、以下の技術に頼る必要がありました：

• 分割されたOdoo / APIアーキテクチャ。

• デーモン化されたAPIサービス（Odooとは別の外部）がマルチスレッドモードで実行されています。

• APIエンジンが負荷分散メカニズムに準拠している（容量のほぼ無限の成長ポテンシャルを提供しています）。

• SQLに埋め込まれた認証と権限。

• SQLデータ型とORMのような差別化。

• 専用C+ PostgreSQL ライブラリ。

• Haskellシェルとバイナリ実行可能ファイル。

この新しいスタックのおかげで、以下のレベルでパフォーマンスが向上しました:

• 認証/認可はORMからアクセス権を取得するのではなく、低レベルで行われます。

• データの検証はORMに行かずにリアルタイムで行われます。

• ERPバックエンドのXML-RPCコネクタが公開アクセスされなくなったため、セキュリティが向上しました。

ご覧の通り、これはかなり印象的ですが、システムの仕様は過剰ではありません。少なくとも1GBのRAMと5GBのSSDを搭載したCPUが必要です。

1500件の販売注文の実行時間は、シンプルなアーキテクチャでは約3秒かかります。複数のコアに分割し、負荷分散された管理インスタンスグループまたはインスタンスクラスタに分散すると、200ミリ秒に短縮されます。結論として、コア数とスレッドを追加するほど、APIの容量が大きくなります。

高性能APIソリューションへのアクセス

現在のユーザーによるストレスがOdooデータベースのパフォーマンスとトランザクション処理能力に影響を与える場合、新しいソリューションを探す時が来ています。そして、Port Citiesがお手伝いします。200人以上のOdooのエキスパートからなるグローバルチームが、高性能API統合の経験を持っています。

お問い合わせ こちら .