OCA queue_job premješta dugotrajne zadatke iz korisničkog HTTP zahtjeva i izvršava ih asinkrono. Koristan je za uvoz podataka, izradu dokumenata, API sinkronizacije i poslove koji se moraju kontrolirano ponoviti nakon privremene pogreške. Na Odoo.sh može dobro raditi, ali konfiguracija izvršitelja mora odgovarati stvarnoj verziji Odooa, OCA grani, broju radnih procesa i mrežnoj ruti.
Konfiguracija u nastavku je polazište za dijagnostiku, a ne univerzalan recept. Prvo je provjerite na pripremnoj grani i usporedite s dokumentacijom točne OCA verzije koju koristite.
Što omogućuje queue_job?
Modul sprema poslove u PostgreSQL i izvršava ih kada izvršitelj ima slobodan kapacitet. Metoda se može odgoditi umjesto da se odmah izvrši:
record.with_delay().send_to_external_api()
OCA modul podržava stanja poslova, prioritete, kanale, pravila ponavljanja, planirano vrijeme izvršenja, opise i povezane radnje. To je korisno kada privremeni prekid vanjske usluge ne smije blokirati korisnika ili izgubiti zahtjev.
Tipični primjeri su:
- sinkronizacije s vanjskim API-jima
- veliki uvozi i izvozi
- izrada PDF dokumenata i izvještaja
- skupne izmjene podataka
- skladišne integracije
- poslovi koji se ponavljaju nakon privremene pogreške
Primarni izvor za instalaciju i ponašanje pojedine verzije je službena dokumentacija OCA queue_job modula .
Što provjeriti prije konfiguracije na Odoo.sh?
Prije izmjene postavki potvrdite četiri stvari:
1. grana modula queue_job odgovara glavnoj verziji Odooa
2. modul i njegove Python ovisnosti dostupni su u Odoo.sh buildu
3. modul je instaliran u ciljnoj bazi
4. okruženje ima dovoljno radnih procesa za odabrani način izvršavanja
OCA dokumentacija za verziju 18 navodi da namjenski izvršitelj treba učitati queue_job kao poslužiteljski modul i raditi s više od jednog radnog procesa. Kapacitet Odoo.sh radnih procesa ovisi o pretplati i postavkama projekta. Zato nije ispravno kopirati vrijednost workers iz primjera za vlastiti server.
Odoo.sh kontejner omogućuje pristup ljusci i konfiguracijskoj datoteci, ali platforma upravlja životnim ciklusom kontejnera. Prije produkcijske promjene pročitajte službenu dokumentaciju o Odoo.sh kontejnerima i koristite pripremnu granu.
Minimalna queue_job konfiguracija
OCA dokumentacija prikazuje ovu osnovnu strukturu:
[options] server_wide_modules = web,queue_job [queue_job] channels = root:1
Postojeći server_wide_modules može već sadržavati druge potrebne module. Sačuvajte postojeću vrijednost i dodajte queue_job samo jednom. Nemojte naslijepo zamijeniti postavke koje je pripremila platforma.
root:1 je dokumentirani zadani kapacitet kanala i razumno početno ograničenje. Omogućuje izvršavanje jednog posla u korijenskom kanalu. Tako je lakše provjeriti zaključavanje, transakcije, ograničenja vanjskih API-ja i opterećenje poslužitelja.
Kada trebaju scheme, host i port?
Izvršitelj koristi HTTP krajnju točku za pokretanje poslova. OCA podržava postavke poput ovih:
[queue_job] scheme = https host = naziv-usmjeravanja port = 443
Te vrijednosti ovise o okruženju. OCA opisuje zadane vrijednosti prema Odoo HTTP sučelju i portu, uz localhost kada host nije postavljen. Javni HTTPS host može riješiti usmjeravanje u jednom Odoo.sh projektu, a biti pogrešan u drugom, posebno uz zaštitu pripremne grane, prilagođenu domenu, HTTP autentikaciju ili dodatni proxy.
Nemojte pretpostaviti da svaki Odoo.sh projekt treba javnu domenu. Prvo u zapisu rada provjerite koju krajnju točku izvršitelj pokušava dohvatiti. Zatim potvrdite:
- host sadrži samo naziv hosta, bez
https:// - protokol i port odgovaraju stvarnoj ruti
- ruta otvara ispravnu bazu
- zaštita pripremne grane ili HTTP autentikacija pravilno su postavljene
- zahtjev ne završava u petlji preusmjeravanja
OCA podržava i http_auth_user te http_auth_password za okruženja koja traže HTTP autentikaciju. Te vrijednosti tretirajte kao tajne i nemojte ih zapisivati u Git.
Kako postaviti kapacitet kanala?
Kanal ograničava istodobno izvršavanje određene skupine poslova. Počnite s root:1, promatrajte stvarne poslove i povećajte kapacitet tek kada znate da je paralelno izvršavanje sigurno.
Primjer složenije postavke:
[queue_job] channels = root:2,root.api:1,root.pdf:1
Ona ima učinka samo ako su funkcije poslova dodijeljene odgovarajućim kanalima. Veći broj kanala ne stvara dodatne Odoo.sh radne procese, a može izazvati istodobne izmjene istih zapisa.
Odvojeni kanali imaju smisla kada poslovi imaju različita ograničenja. Vanjski API može ograničiti broj poziva, izrada PDF-a može trošiti mnogo memorije, a skladišne izmjene mogu zahtijevati strogo redoslijedno izvršavanje.
Kako provjeriti je li izvršitelj pokrenut?
Nakon ponovnog pokretanja builda ili servisa pregledajte Odoo zapis. OCA dokumentacija navodi poruke poput ovih:
queue_job.jobrunner.runner: starting queue_job.jobrunner.runner: initializing database connections queue_job.jobrunner.runner: queue job runner ready for dbqueue_job.jobrunner.runner: database connections ready
Ako ih nema, prije poslovnog koda provjerite putanju modula, verziju Odooa, ovisnosti, server_wide_modules, raspoložive radne procese i sintaksu konfiguracije.
Za detaljniju dijagnostiku OCA preporučuje poseban zapisivač:
--log-handler=odoo.addons.queue_job:DEBUG
Detaljni zapis koristite privremeno. U produkciji može stvoriti mnogo zapisa i otkriti operativne detalje.
Kako napraviti kontrolirani test?
Nemojte početi velikim uvozom. U pripremnom okruženju napravite mali idempotentni test koji ostavlja vidljiv, ali bezopasan rezultat.
Provjerite:
- nastaje li posao
- izlazi li iz stanja
pending - pokreće li ga izvršitelj
- završava li u stanju
done - slijedi li namjerna privremena pogreška očekivano pravilo ponavljanja
- daje li trajna pogreška koristan zapis poziva
- stvara li ponavljanje neželjene duplikate
Posljednja provjera je najvažnija. Posao se može ponoviti nakon prekida radnog procesa ili mrežne pogreške. Kod koji šalje račun, stvara isporuku ili zove platni API mora spriječiti dvostruki poslovni učinak.
Zašto poslovi ostaju u stanju pending?
Provjeravajte uzroke ovim redom:
1. queue_job je instaliran, ali nije učitan kao poslužiteljski modul
2. izvršitelj se nije pokrenuo nakon builda
3. aktivni filtar baze ne odabire ciljnu bazu
4. HTTP krajnja točka nije dostupna ili je pogrešno postavljena
5. nema raspoloživog radnog procesa
6. ciljni kanal nema kapacitet ili mu je naziv pogrešan
7. ovisnost drži posao u stanju čekanja
Ako poslovi ostanu u stanju started ili enqueued, provjerite je li radni proces prekinut. Aktualna OCA dokumentacija navodi automatsko ponovno stavljanje takvih poslova u red, ali ponašanje potvrdite na instaliranoj verziji.
Koje zaštite trebaju u produkciji?
Prije važnih poslovnih poslova dodajte zaštite u samu metodu:
- gdje je moguće, učinite posao idempotentnim
- koristite uobičajene Odoo transakcije
- ograničite broj ponavljanja kod trajnih pogrešaka
- spremite identifikator vanjskog zahtjeva
- pratite neuspjele poslove i starost reda
- ograničite pristup izbornicima i zapisima pogreške
- ne stavljajte tajne ni pune osobne podatke u opis posla
- dokumentirajte kako operater ponavlja ili otkazuje posao
Red poslova ubrzava korisnički odgovor, ali sam po sebi ne čini proces pouzdanim. Pouzdanost dolazi iz jasnih pravila ponavljanja, transakcija, nadzora i sigurnog postupanja pri mogućem dvostrukom izvršavanju.
Završna kontrolna lista
Prije produkcije potvrdite:
- OCA grana odgovara verziji Odooa
queue_jobse učitava kao poslužiteljski modul- model radnih procesa podržava odabrani izvršitelj
- početni kapacitet kanala je konzervativan
- mrežne postavke odgovaraju stvarnoj Odoo.sh ruti
- tajne nisu zapisane u repozitoriju
- poruke pokretanja postoje u zapisu
- mali posao završava u pripremnom okruženju
- testirani su ponavljanje i zaštita od duplikata
- neuspjeli poslovi imaju vlasnika i postupak obrade
Ako queue_job ostaje u stanju pending ili integracija treba sigurnije ponavljanje, pošaljite verziju Odooa, model hostinga, konfiguraciju bez tajni i relevantan dio zapisa rada. To je obično dovoljno da se problem izvršitelja odvoji od pogreške u poslovnom kodu.
