افزونه صف کار در Odoo

افزونه صف کار یک Job Queue یکپارچه به Odoo اضافه می کند. این افزونه امکان به تعویق انداختن فراخوانی های متد ها را که به صورت غیر همزمان اجرا می شوند فراهم می کند. کارها (jobs) در پس زمینه توسط یک Jobrunner در تراکنش خاص خودشان اجرا می شوند.

مثال:

در قطعه کد بالا، هنگامی که ما متد button_do_stuff را فراخوانی می کنیم، یک کار برای گرفتن متد و آرگومان ها ((my_method('a', k=2) به تعویق می افتد (postpone). این کار به محض اینکه Jobrunner یک فضای آزاد (free bucket) داشته باشد، اجرا می شود. در صورتی که هیچ کار دیگری در حال اجرا نباشد، این کار می تواند به صورت آنی اجرا شود.

ویژگی های افزونه صف کار:

• نماهای کارها و کار ها در PostgreSQL ذخیره می شوند.
• Jobrunner: شما می توانید به لطف NOTIFY PostgreSQL کارها را به صورت کارآمدی اجرا کنید.
• کانال ها: شما می توانید ظرفیتی برای کانال root و زیر کانال های آن ایجاد کنید و کارها را در آن کانال ها تفکیک کنید. به عنوان مثال می توانید دو کانال ایجاد کنید و کار های سنگین را در یک کانال و کار های سبک را در کانال دیگر قرار دهید. این دو کانال به صورت نوبتی اجرا می شوند. هر کانال در نوبت اجرای خود می تواند تعدادی از کارهای درون خود را بسته به تصمیم شما اجرا کند. به عنوان مثال، می توانید کارهای سنگین به صورت یک کار در نوبت اجرا کنید در حالی که کارهای کوچک به صورت 4 کار در نوبت اجرا کنید.
• تلاش های مجدد: در این افزونه امکان تلاش مجدد کارها با بیدار کردن یک نوع exception وجود دارد.
• الگوی تلاش مجدد: 3 بار اول، بعد از 10 ثانیه مجدد، 5 بار بعدی، بعد از 1 دقیقه دوباره تلاش می کند.
• تنظیمات کار: در این افزونه، تنظیمات کار شامل اولویت ها، زمان تخمینی ورود (ETA)، توضیحات سفارشی، تعداد تلاش های مجدد است.
• اقدامات مرتبط: در این افزونه امکان اقداماتی مانند اختصاص دادن یک اکشن روی نمای کار، مانند باز کردن رکورد مربوط به کار وجود دارد.

موارد استفاده

Odoo وظایف را به طور همزمان انجام می دهد، مانند زمانی که لیستی از محصولات را وارد می کنید، هر لاین را در یک کار بزرگ بررسی می کند. "Queue job" به شما این امکان را می دهد که وظایف بزرگ را در بسیاری از موارد کوچکتر به تفصیل بیان کنید.

تصور کنید برای هزاران سفارش داده‌های زیادی برای تغییر دارید، می‌توانید این کار را در یک مرحله انجام دهید و بار سنگینی روی سرور ایجاد کنید و این ممکن است بر عملکرد Odoo تأثیر بگذارد. با queue_job می توانید تسک را به کار ها تقسیم کنید و هزاران کار را اجرا کنید (یک کار برای هر سفارش). یک مزیت دیگر این است که اگر یک خط شکست بخورد، پردازش بقیه را مسدود نمی کند، زیرا کار ها مستقل هستند. به علاوه می‌توانید کارها را زمان‌بندی کنید و تعدادی تلاش مجدد را تنظیم کنید.

در اینجا چند نمونه کاربرد در community آورده شده است:

• فاکتورهای ارسال انبوه: account_invoice_mass_sending
• وارد کردن داده ها در پس زمینه: base_import_async
• استخراج داده ها را در پس زمینه: base_export_async
• ایجاد فاکتورهای قرارداد با کار ها: contract_queue_job
• ایجاد فاکتورهای پارتنر را با کارها: partner_invoicing_mode
• پردازش اکشن های گردش کار خودکار فروش با کارها: sale_automatic_workflow_job

نصب و راه اندازی

برای نصب و راه اندازی افزونه صف کار باید حتما کتابخانه requests را داشته باشید.

پیکربندی

• استفاده از متغیرهای محیطی و خط فرمان:
• • تنظیم متغیرهای محیطی (اختیاری):
  • • تنظیم کانال ها را می توانید با کد ODOO_QUEUE_JOB_CHANNELS=root:4 یا هر پیکربندی کانال دیگر انجام دهید. به صورت پیش فرض root:1 است
    • اگر  xmlrpc_port تنظیم نشده باشد، آن را با کد ODOO_QUEUE_JOB_PORT=8069 تنظیم کنید
  • Odoo را با --load=web, queue_job و --workers بزرگتر از 1 راه اندازی کنید.
• با استفاده از فایل پیکربندی Odoo:

• با بررسی فایل گزارش (log file) موجود در odoo، تأیید کنید که runner به درستی شروع می شود:

• کارها را ایجاد کنید (مثلاً با استفاده از base_import_async) و مشاهده کنید که بلافاصله و به طور موازی شروع می شوند.
• نکته: برای فعال کردن نمایش گزارش های (log) رفع خطا برای کار صف، از log-handler=odoo.addons.queue_job:DEBUG-- استفاده کنید.
• حتما Jobs Garbage Collector CRON را بررسی کنید و پارامترهای enqueued_delta و start_delta را بر اساس نیازهای خود تغییر دهید.
• • enqueued_delta: زمان صرف شده به دقیقه که پس از آن یک کار در نوبت صف، گیر افتاده در نظر گرفته می شود. برای غیرفعال کردن این بررسی، آن را روی 0 تنظیم کنید.
  • start_delta: زمان صرف شده به دقیقه که پس از آن یک کار شروع شده گیر افتاده در نظر گرفته می شود. این پارامتر در پیکربندی شما نباید کمتر از پارامتر limit-time-real // 60 باشد. برای غیرفعال کردن این بررسی، آن را روی 0 تنظیم کنید. بر اساس پارامتر پیکربندی limit-time-real-- سرور، آن را روی -1 تنظیم کنید تا خودکار شود.

استفاده

برای استفاده از این ماژول باید به Job Queue منو بروید.

به تعویق انداختن کارها

راه سریع برای ردیف کردن یک کار برای یک متد، استفاده از ()with_delay در یک رکورد یا مدل است:

در اینجا، متد ()print_confirmation_document به صورت ناهمزمان به عنوان یک کار اجرا می شود. ()with_delay می تواند چندین پارامتر را برای تعریف دقیق تر نحوه اجرای کار در نظر بگیرد (اولویت، ...).

همه آرگومان‌های ارسال شده به متد در حال تأخیر در کار ذخیره می‌شوند و هنگامی که به صورت ناهمزمان اجرا می‌شود به متد ارسال می‌شوند، از جمله self، بنابراین رکورد فعلی در طول اجرای کار حفظ می‌شود (هشدار: متن حفظ نمی‌شود).

وابستگی ها را می توان بین کارها بیان کرد. برای شروع یک گراف از کارها، از ()delayable روی یک رکورد یا مدل استفاده کنید. کد زیر معادل ()with_delay اما با استفاده از فرم طولانی است:

متد های Delayable Objects خودش را برمی گرداند، بنابراین می توان از آن به عنوان یک الگوی سازنده استفاده کرد که در برخی موارد امکان ساخت کارها را به صورت پویا فراهم می کند:

ساده ترین راه برای تعریف وابستگی استفاده از (on_done(job روی Delayable است:

Delayable ها را می توان زنجیره ای کرد تا گراف های پیچیده تری را با استفاده از ()chain و ()group اولیه تشکیل دهند. یک زنجیره نشان دهنده دنباله ای از کارها است که باید به ترتیب اجرا شوند، یک گروه نشان دهنده کارهایی است که می توانند به صورت موازی اجرا شوند. استفاده از ()chain یک اثر مشابه با استفاده از چندین متد ()on_done تو در تو دارد اما خواناتر است. هر دو را می‌توان برای تشکیل یک نمودار ترکیب کرد، برای مثال می‌توانیم [A] کارها را گروه کنیم، که گروه دیگری [B] از کارها را مسدود می‌کند. زمانی و تنها زمانی که تمام کارهای گروه [A] اجرا می شوند، کارهای گروه [B] اجرا می شوند. کد به شکل زیر خواهد بود:

هنگامی که یک شکست در یک گراف از کارها اتفاق می افتد، اجرای کارهایی که به کار شکست خورده وابسته هستند متوقف می شود. آنها در  حالت wait_dependencies باقی می ماند تا زمانی که کار "والد" آنها موفقیت آمیز باشد. این می تواند به دو صورت اتفاق بیفتد: یا کار والد دوباره امتحان می کند و در تلاش دوم موفق می شود، یا کار والد به صورت دستی توسط یک کاربر "set to done" می شود. در این دو حالت وابستگی برطرف شده و پردازش گراف ادامه خواهد داشت. از طرف دیگر، کار ناموفق و تمام کارهای وابسته به آن می توانند توسط کاربر لغو شوند. کارهای دیگر نمودار که به کار شکست خورده وابسته نیستند در هر صورت به اجرای خود ادامه می دهند.