Why would we dedicate an entire article to Odoo API solutions?
During these past years, we have witnessed an increasing number of requirements from customers to open their Odoo environments to dedicated and third-party systems by using the Odoo API system and XML-RPC Odoo API interface.
The reason isn't far fetched. But we have also noticed that as the companies grow and use cases increase, the standard Odoo API limitations begin to affect productivity.
So, what are the causes, and what should you do when this happens?
Standard Odoo API limitations
When contemplating the Odoo “out-of-the-box” API performance, one quickly realizes that it cannot handle large data flows combined with intensive activity. For example, even on the latest version of Odoo 14 & 15 Enterprise, our tests reveal that creating more than two to three Sales Orders per second per worker in a Standard Sales order with no customization is already difficult.
This is mostly because the POST transactions (transactions moved from the transaction registers to the general ledger) pushed to Odoo must still be validated at the Odoo level by the ORM mechanisms. The same issues happen with medium to large data imports.
I saw many projects failing because the Odoo developers did not assess the needs in terms of the necessary volume and speed from the beginning. Yet, the clients know from the beginning how many sales orders, picking lists, warehouse moves and invoices they will generate over their usual business year.
Things tend to become tragic for the same reasons when Smartphone App developers believe they can use the standard Odoo XML/RPC API layer to power up end-user apps with thousands of concurrent users. They exceed the capacity of the Odoo ORM with B2C applications involving thousands of concurrent users.
Different Scale Implies Different Architecture
There are essentially three different ways API interfacing can be dealt with.
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.
The first benefit of this approach is that it is easy to implement as all the heavy lifting has been done by Odoo, with clear documentation that can be found here. This approach also produces quick results, and data coherence is safe-guarded by the Odoo standard ORM validation before COMMIT.
In simple terms, using this approach, users rely on the API - standard architecture and implementation - as delivered by Odoo without any modification. It, however, does not allow for large data integration, and only a limited number of concurrent users is allowed.
The Drawbacks of the standard Odoo API Approach:
It can only accommodate a limited number of concurrent transactions and users without failure.
The system cannot accept beyond a limited amount of data.
It is not scalable.
2. Advanced API integration
The standard Odoo API approach makes integration simple, but what happens when you need to process more transactions? Hence, the need for advanced API integration.
This approach, therefore, goes beyond the standard Odoo ORM features. For this approach to work, the logic of access to the data must be redesigned according to the following guidelines:
Use the Odoo ORM to create/update the data models and objects used by the endpoints.
Implement a dedicated connector and bypass the Odoo XML/RPC features when needed.
Replace the Odoo standard API features with another API engine to allow more performance.
Integrate the data validation processes of the ORM at the new API core level to accelerate the validation/response time.
Benefits and Drawbacks
The advanced API integration means that a lot more potential concurrent users than the standard API approach can be accommodated. This means that more data volumes can be processed per call and in total. And without a doubt, this solution accepts more transactions without affecting performance.
The first problem or drawback users will face is that this approach introduces new tech stacks in the project, which means more expertise is required to get the job done. So, while the Odoo API is the primary solution, the upgraded architecture means that the ETL (Extract, Transform, Load) is now split over two different systems. To preserve the ETL coherence then requires a higher level of rigor.
Are you experiencing issues with the standard Odoo API?
3. High-Performance API solution
This year, our teams have been delivering one dedicated High Availability architecture system for a big player in the “transactional world” of the Southern Asian market. The initial performance and load requirements give us up to 1500 inserts (POST requests) per second and up to 10,000 downloads (GET requests) per second.
With this sort of load, the specified capabilities of the standard Odoo modules using standard XML-RPC Odoo API have been exceeded. Even an advanced API integration would not be enough since the stress imposed by the concurrent users could easily disrupt the Odoo Database's performance and capacity to handle transactions.
Because of the above, we had to resort to the following technologies:
Split Odoo / API architecture.
Daemonized API service (external to Odoo) running in multi-threading mode.
Compliance of the API engine with load-balancing mechanisms (which offered us an almost infinite growth potential in terms of capacity).
SQL embedded authentication and authorizations.
SQL data types and ORM-like discrimination.
Dedicated C+ PostgreSQL libraries.
Haskell shell and binary executable.
Thanks to this new stack, we improved performance at the following levels:
Authentication/Authorization occurs at the low level instead of pulling access rights from the ORM.
Data validation is real-time without going to ORM.
Security improvement since the XML-RPC connector of the ERP back-end is not open to public access anymore.
As you can see, this is quite impressive, and the system specifications are not overboard. You will only need a CPU with at least 1GB RAM and a 5GB SSD.
The execution time of 1500 Sales orders goes to approximately 3 seconds on a simple architecture. It melts down to 200 ms when split over multiple cores and load-balanced managed instance groups or instance clusters. The bottom line is the more cores and threading you add, the bigger the API capacity.
Your Access to High-Performance API Solution
If the stress imposed by your current users disrupts the Odoo Database performance and capacity to handle transactions, then it's time you look for a new solution. And Port Cities can help. We have a global team powered by 200+ Odoo experts with experience handling high-performance API integrations.
Contact us here.