Mengapa kami mendedikasikan seluruh artikel untuk solusi API Odoo?
Selama beberapa tahun terakhir ini, kami telah menyaksikan peningkatan sejumlah persyaratan dari pelanggan untuk sistem Odoo mereka ke sistem khusus dan pihak ketiga dengan menggunakan sistem API Odoo dan interface XML-RPC Odoo API.
Kami juga memperhatikan bahwa seiring dengan pertumbuhan perusahaan dan peningkatan kasus penggunaan, batasan standar API Odoo mulai mempengaruhi produktivitas.
Lantas, apa saja penyebabnya, dan apa yang harus Anda lakukan saat hal itu terjadi?
Batasan API Odoo standar
Saat mempelajari kinerja API "out-of-the-box" Odoo, orang dengan cepat menyadari bahwa sistem tersebut tidak dapat menangani flow data besar yang dikombinasikan dengan aktivitas intensif. Misalnya, bahkan pada versi terbaru Odoo 14 & 15 Enterprise, pengujian kami mengungkapkan bahwa membuat lebih dari dua hingga tiga Sales Order per detik per pekerja dalam Standard Sales Order tanpa dikustom sangat sulit.
Hal ini sebagian besar karena transaksi POST (transaksi yang dipindahkan dari register transaksi ke buku besar) yang didorong ke Odoo masih harus divalidasi di tingkat Odoo oleh mekanisme ORM. Masalah yang sama terjadi dengan impor data menengah hingga besar.
Saya melihat banyak proyek gagal karena pengembang Odoo yang tidak menilai kebutuhan dalam hal volume dan kecepatan yang diperlukan sejak awal. Namun, klien tahu dari awal berapa banyak sales orders, picking lists, pemindahan gudang, dan faktur yang akan mereka hasilkan selama tahun bisnis mereka.
Hal-hal cenderung menjadi tragis karena alasan yang sama ketika pengembang aplikasi smartphone percaya bahwa mereka dapat menggunakan lapisan API XML/RPC Odoo standar untuk memperkuat aplikasi pengguna akhir dengan ribuan pengguna secara bersamaan. Mereka melebihi kapasitas Odoo ORM dengan aplikasi B2C yang melibatkan ribuan pengguna secara bersamaan.
Skala Berbeda Mengimplikasikan Arsitektur yang Berbeda
Pada dasarnya ada tiga cara yang berbeda untuk menangani interface API.
1. The Standard Odoo “light” approach
The standard Odoo “light” approach menggunakan API eksternal yang diberikan oleh Odoo untuk mengakses fitur dan data dari integrasi dengan alat eksternal lainnya. Pengembang dapat mengaksesnya melalui interface XML-RPC Odoo API, tersedia dalam berbagai bahasa seperti Python, Java, PHP, dan Ruby.
Manfaat pertama dari pendekatan ini adalah mudah diterapkan karena semua pekerjaan berat telah dilakukan oleh Odoo dengan dokumentasi yang jelas yang dapat ditemukan di sini. Pendekatan ini juga menghasilkan hasil yang cepat dan koherensi data dijaga dengan aman oleh validasi ORM standar Odoo sebelum COMMIT.
Secara sederhana, dengan menggunakan pendekatan ini, pengguna mengandalkan API - arsitektur dan implementasi standar - seperti yang diberikan oleh Odoo tanpa modifikasi apa pun. Namun, itu tidak memungkinkan untuk integrasi data yang besar dan hanya sejumlah pengguna bersamaan yang diizinkan.
Kelemahan Pendekatan API Odoo standar
Memiliki limitasi yang hanya dapat menampung sejumlah transaksi dan pengguna bersamaan tanpa kegagalan.
Sistem tidak dapat menerima sejumlah data jika melebihi batas.
Tidak dapat diukur.
2. Advanced API integration
Pendekatan API Odoo standar membuat integrasi menjadi sederhana, tetapi apa yang terjadi ketika lebih banyak transaksi yang perlu diproses? Itulah sebabnya ada kebutuhan untuk integrasi API tingkat lanjutan.
Pendekatan ini melampaui fitur standar Odoo ORM. Agar pendekatan ini berfungsi, logika akses ke data harus didesain ulang sesuai dengan panduan berikut:
Gunakan Odoo ORM untuk membuat/memperbarui model data dan objek yang digunakan oleh titik akhir (endpoint).
Terapkan konektor khusus dan lewati fitur XML/RPC Odoo bila diperlukan.
Ganti fitur API standar Odoo dengan mesin API lain untuk memungkinkan lebih banyak kinerja.
Integrasikan proses validasi data ORM di level inti API baru untuk mempercepat waktu validasi/respons.
Manfaat dan Kerugian
Integrasi API tingkat lanjut artinya lebih banyak pengguna sistem secara bersamaan daripada pendekatan API standar yang dapat diakomodasi. Ini berarti lebih banyak volume data yang dapat diproses per panggilan secara total. Dan tanpa ragu, solusi ini menerima lebih banyak transaksi tanpa mempengaruhi kinerja.
Masalah atau kelemahan pertama yang akan dihadapi pengguna adalah bahwa pendekatan ini memperkenalkan sebuah teknologi baru dalam proyek, yang berarti diperlukan lebih banyak keahlian untuk menyelesaikan pekerjaan. Jadi, sementara API Odoo adalah solusi utama, arsitektur yang ditingkatkan berarti ETL (Extract, Transform, Load) sekarang dibagi menjadi dua sistem yang berbeda. Untuk menjaga koherensi ETL, maka diperlukan tingkat ketelitian yang lebih tinggi.
Apakah Anda mengalami masalah dengan API Odoo standar?
3. Solusi High-Performance API
Tahun ini, tim kami telah menghadirkan High Availability architecture system khusus untuk pemain besar di "dunia transaksional" pasar Asia Selatan. Kinerja awal dan persyaratan memberi kami hingga 1500 sisipan (permintaan POST) per detik dan hingga 10.000 unduhan (permintaan GET) per detik.
Dengan beban semacam ini, kemampuan yang ditentukan dari modul Odoo standar yang menggunakan XML-RPC Odoo API standar telah terlampaui. Bahkan integrasi API tingkat lanjut tidak akan cukup karena tekanan yang ditimbulkan oleh pengguna bersamaan dapat dengan mudah mengganggu kinerja dan kapasitas Database Odoo untuk menangani transaksi.
Karena hal di atas, kami menggunakan teknologi berikut:
Pisahkan arsitektur Odoo / API
Layanan API daemonisasi (eksternal ke Odoo) berjalan dalam mode multi-threading
Kepatuhan mesin API dengan mekanisme penyeimbang beban (yang menawarkan kepada kami potensi pertumbuhan yang hampir tak terbatas dalam hal kapasitas)
SQL embedded authentication and authorizations
SQL data types and ORM-like discrimination
Dedicated C+ PostgreSQL libraries
Haskell shell and binary executable
Berkat teknologi baru ini, kami meningkatkan kinerja pada level berikut:
Otentikasi / Otorisasi terjadi pada tingkat rendah daripada menarik hak akses dari ORM
Validasi data dilakukan secara real-time tanpa masuk ke ORM
Peningkatan keamanan karena konektor XML-RPC dari back-end ERP tidak lagi terbuka untuk akses publik
Seperti yang Anda lihat, hal ini cukup mengesankan, dan spesifikasi sistemnya tidak berlebihan. Anda hanya membutuhkan CPU dengan setidaknya 1GB RAM dan 5GB SSD.
Waktu eksekusi 1500 sales order berlangsung sekitar 3 detik pada arsitektur sederhana. Kemudian turun hingga 200 mili detik saat dipecah menjadi beberapa inti dan grup instansi terkelola atau kluster instansi dengan beban seimbang. Intinya adalah semakin banyak core dan threading yang Anda tambahkan, semakin besar kapasitas API.
Akses Anda ke Solusi High-Performance API
Jika tekanan yang ditimbulkan oleh pengguna Anda saat ini mengganggu kinerja dan kapasitas database Odoo untuk menangani transaksi, maka inilah saatnya Anda mencari solusi baru. Dan Port Cities dapat membantu. Kami memiliki tim global yang didukung oleh 170+ pakar Odoo dengan pengalaman menangani integrasi API berkinerja tinggi.
Hubungi kami di sini.
