Kod Odoo integracija, velikih importova, API poziva, generiranja PDF dokumenata ili batch obrade brzo se pojavi isti problem: ne treba sve raditi unutar korisničkog HTTP requesta.

Ako korisnik klikne gumb, a sustav zatim radi težak posao nekoliko minuta, korisničko sučelje postaje sporo, request može timeoutati, a greške je teže kontrolirati.

OCA queue_job modul rješava taj problem tako da posao sprema u red i izvršava ga asinkrono u pozadini. Na standardnom self-hosted Odoo serveru konfiguracija je obično jasna. Na Odoo.sh treba paziti na nekoliko detalja.

Što radi queue_job?

queue_job omogućuje da se metoda ne izvrši odmah, nego da se doda u red poslova.

Primjeri:

record.with_delay().generate_pdf()
record.with_delay().send_to_external_api()
record.with_delay().process_large_import()

Korisnik dobije brži odgovor, a posao se izvršava u pozadini kroz job runner. Poslovi mogu imati prioritete, kanale, retry logiku i status koji se može pratiti u Odoo sučelju.

To je posebno korisno za:

• integracije s vanjskim API-jima
• velike importove ili exporte
• generiranje dokumenata
• sinkronizaciju podataka
• obradu skladišnih ili računovodstvenih batch procesa
• zadatke koje treba ponoviti ako privremeno padne vanjski servis

Važna razlika na Odoo.sh

Na Odoo.sh konfiguracijska datoteka se može otvoriti iz shell-a:

nano /home/odoo/.config/odoo/odoo.conf

Međutim, Odoo.sh nije isto što i server kojim potpuno sami upravljate. Dio parametara kontrolira platforma. U samoj konfiguracijskoj datoteci Odoo.sh obično prikazuje upozorenje da se parametri vezani uz workere, memorijska ograničenja i time limite ne uzimaju nužno u obzir kao na self-hosted instalaciji.

Zato kod queue_job konfiguracije treba biti precizan: cilj nije preuzeti kontrolu nad cijelom worker arhitekturom, nego pravilno učitati queue_job kao server-wide modul i podesiti job runner da zna kako pozvati Odoo instancu.

Preporučena početna konfiguracija

Konzervativna početna konfiguracija za Odoo.sh može izgledati ovako:

[options]
dbfilter=
server_wide_modules = web,base,queue_job

[queue_job]
channels = root:1
scheme=https
host=<your-odoo-sh-domain>
port=443

host treba biti domena Odoo.sh instance bez https://.

Primjer formata:

host=myproject.odoo.com

Ne koristiti:

host=https://myproject.odoo.com

scheme=https i port=443 već definiraju protokol i port.

server_wide_modules

Ova linija je ključna:

server_wide_modules = web,base,queue_job

queue_job mora biti učitan kao server-wide modul kako bi job runner infrastruktura bila dostupna pri pokretanju Odoo procesa.

Ako je modul samo instaliran u bazi, ali nije dodan u server_wide_modules, možete završiti u situaciji gdje se jobovi kreiraju, ali se ne izvršavaju.

Tipičan simptom je da poslovi ostaju u pending stanju.

channels

Linija:

channels = root:1

znači da jedan posao može raditi u root kanalu.

Na Odoo.sh je pametno krenuti konzervativno. root:1 je dobar početni izbor jer smanjuje rizik da pozadinski poslovi preopterete instancu ili naprave konkurentne izmjene nad istim podacima.

Kasnije, nakon promatranja stvarnog opterećenja, može se razmotriti više kanala:

channels = root:2,root.api:1,root.pdf:1

Takva konfiguracija može odvojiti API sinkronizacije, PDF poslove i druge batch procese. Ipak, povećavanje broja kanala treba raditi tek nakon što je osnovna konfiguracija stabilna.

scheme, host i port

Ovo je najčešća razlika u odnosu na lokalni ili self-hosted server:

scheme=https
host=<your-odoo-sh-domain>
port=443

Job runner ne izvršava posao direktno u sebi. On koristi Odoo HTTP endpoint za pokretanje posla. Na klasičnoj instalaciji često se koristi localhost:8069.

Na Odoo.sh to može zapeti jer runner može pokušati zvati:

http://localhost:8069/queue_job/...

Ako Odoo.sh kontejner i platformni routing nisu postavljeni kao vaš lokalni server, localhost:8069 nije sigurna pretpostavka. Zato je praktičnije usmjeriti runner na javni HTTPS host Odoo.sh instance.

Što nakon spremanja konfiguracije?

Nakon promjene konfiguracije treba restartati Odoo.sh build ili servis kako bi se konfiguracija učitala.

Zatim treba provjeriti logove. Kod ispravnog starta job runnera očekuju se poruke slične ovima:

queue_job.jobrunner.runner: starting
queue_job.jobrunner.runner: initializing database connections
queue_job.jobrunner.runner: queue job runner ready for db <dbname>
queue_job.jobrunner.runner: database connections ready

Ako tih poruka nema, prvo treba provjeriti je li queue_job stvarno učitan u server_wide_modules.

Test s malim jobom

Nakon konfiguracije nemojte odmah testirati veliki import ili kompleksnu integraciju. Prvo pokrenite mali, kontrolirani job.

Primjer:

self.with_delay().message_post(body="Queue job test")

Zatim provjerite Queue Jobs izbornik u Odoo sučelju. Ovisno o verziji i pravima pristupa, taj izbornik je najčešće dostupan kroz tehničke ili debug izbornike.

Provjerite:

• je li job kreiran
• prelazi li iz pending u started
• završava li u done
• postoji li traceback ako završi u failed
• pojavljuju li se poruke job runnera u logovima

Česte greške

Najčešće greške kod Odoo.sh i queue_job konfiguracije su:

• queue_job je instaliran, ali nije u server_wide_modules
• host sadrži https://
• runner pokušava koristiti localhost:8069
• konfigurirano je previše kanala prerano
• nema restarta nakon promjene konfiguracije
• jobovi ostaju u pending stanju
• stari jobovi ostanu u started ili enqueued stanju nakon prekida
• očekuje se da Odoo.sh worker parametri rade isto kao na vlastitom serveru

Oprez oko podrške i arhitekture

Važno je jasno reći: Odoo.sh nije isto što i potpuno upravljani vlastiti server. Neke stvari koje su jednostavne na vlastitoj infrastrukturi na Odoo.sh ovise o ograničenjima platforme.

Za mnoge projekte queue_job na Odoo.sh može biti praktičan, ali treba krenuti s malim brojem kanala, pratiti logove i izbjegavati dugačke poslove koji agresivno troše resurse.

Ako projekt ima vrlo velik broj pozadinskih poslova, visoku frekvenciju sinkronizacija ili stroge zahtjeve nad infrastrukturom, treba razmotriti self-hosted Odoo, Odoo Enterprise hosting s dodatnom arhitekturom ili odvojeni worker pristup.

Preporučena checklist

Prije nego konfiguraciju smatrate spremnom, provjerite:

• queue_job je instaliran u bazi
• queue_job je dodan u server_wide_modules
• konfiguracija koristi scheme=https
• host je domena bez https://
• port=443
• početni channels je konzervativan, npr. root:1
• Odoo.sh servis je restartan nakon promjene
• logovi pokazuju da je runner pokrenut
• mali test job završava u done
• postoji postupak za retry i praćenje failed jobova

Zaključak

OCA queue_job je jedan od najkorisnijih modula za ozbiljnije Odoo implementacije jer odvaja dugotrajne zadatke od korisničkog requesta.

Na Odoo.sh najvažnije je ne pretpostaviti da vrijede ista pravila kao na lokalnom serveru. server_wide_modules, channels, scheme, host i port treba postaviti pažljivo.

Siguran početak je:

[options]
dbfilter=
server_wide_modules = web,base,queue_job

[queue_job]
channels = root:1
scheme=https
host=<your-odoo-sh-domain>
port=443

Nakon toga treba provjeriti logove i pokrenuti mali test job prije nego se queue koristi za važne produkcijske procese.

CTA

Maxcode može pomoći u konfiguraciji Odoo.sh projekata, OCA modula i pozadinskih procesa za integracije, importove i automatizaciju poslovnih zadataka.