نود Wait در N8N

نود Wait در N8N

نود Wait یکی از کاربردی‌ترین نودها برای کنترل زمان در ورکفلوهاست. با این نود می‌توانید اجرای روند را برای چند ثانیه/دقیقه/ساعت متوقف کنید، یا تا رسیدن به یک زمان مشخص صبر کنید. نتیجه این کار، ساخت اتوماسیون‌های واقعی‌تر و پایدارتر است؛ مثل رعایت محدودیت نرخ API، فاصله‌گذاری بین پیام‌ها، یا زمان‌بندی دقیق مراحل.

معرفی نود در N8N

نود Wait وظیفه دارد اجرای ورکفلو را به‌صورت کنترل‌شده متوقف (Pause) کند و سپس ادامه دهد. این نود برای مدیریت تاخیر (Delay) و زمان‌بندی (Scheduling داخلی) داخل یک جریان استفاده می‌شود.

  • کارکرد اصلی: ایجاد مکث در اجرای ورکفلو تا مدت زمان مشخص یا تا زمان/تاریخ مشخص
  • دسته‌بندی نود: Function (کنترل جریان و زمان)
  • اهمیت در ورکفلوها: جلوگیری از فشار به سرویس‌های خارجی، زمان‌بندی پیام‌ها/درخواست‌ها، همگام‌سازی با رویدادهای زمانی، و افزایش پایداری اجرای اتوماسیون

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

1) رعایت Rate Limit API (جلوگیری از خطای 429)

اگر به یک API درخواست‌های پشت سر هم می‌زنید (مثلاً ارسال پیام یا دریافت داده)، می‌توانید بین درخواست‌ها 200 تا 1000 میلی‌ثانیه مکث بگذارید تا سرویس شما را محدود نکند.

  • سناریو: Google Sheets / Notion / Telegram / WhatsApp API
  • ترکیب پیشنهادی: Split In Batches → HTTP Request → Wait → ادامه batch

2) فاصله‌گذاری بین پیام‌ها برای جلوگیری از اسپم

در ارسال پیام‌های اطلاع‌رسانی (مثلاً پیامک/تلگرام/ایمیل)، بهتر است بین هر پیام کمی تاخیر بگذارید تا هم نرخ ارسال کنترل شود و هم تجربه کاربر بهتر باشد.

  • سناریو: ارسال پیام به لیست کاربران پس از یک رویداد
  • ترکیب پیشنهادی: CRM Trigger → Set/IF → Wait → Email/Telegram

3) اجرای مرحله دوم در زمان مشخص (مثلاً فردا ساعت 9)

گاهی لازم است یک مرحله از فرآیند دقیقاً در زمان مشخص انجام شود؛ مثلاً بعد از ثبت سفارش، پیگیری روز بعد انجام شود.

  • سناریو: ثبت لید → فردا 09:00 پیام پیگیری
  • ترکیب پیشنهادی: Webhook → Create Record → Wait (تا تاریخ/زمان) → Send Message

4) صبر برای تکمیل پردازش سرویس‌های غیرهمزمان

برخی سرویس‌ها بعد از ارسال درخواست، نتیجه را با تاخیر آماده می‌کنند (مثلاً تولید فایل، گزارش یا پردازش ویدیو). می‌توانید چند دقیقه صبر کنید و سپس مرحله دریافت نتیجه را اجرا کنید.

  • سناریو: درخواست ساخت گزارش → 2 دقیقه مکث → دریافت لینک گزارش
  • ترکیب پیشنهادی: HTTP Request (Start Job) → Wait → HTTP Request (Check Status)

پارامترها و تنظیمات

تنظیمات نود Wait بسته به حالت انتخابی (Mode) تغییر می‌کند. هدف اصلی همیشه یک چیز است: تعیین اینکه ورکفلو چقدر یا تا چه زمانی متوقف بماند.

فهرست پارامترها

  • Mode (حالت انتظار) | نوع داده: Option/Enum | توضیح: تعیین می‌کند انتظار بر اساس مدت زمان باشد یا تا یک تاریخ/زمان مشخص | مثال: Delay / Until
  • Amount (مقدار) | نوع داده: Number | توضیح: تعداد واحدهای زمانی برای مکث (در حالت Delay) | مثال: 10
  • Unit (واحد) | نوع داده: Option | توضیح: واحد زمان (ثانیه/دقیقه/ساعت/روز و…) برای Amount | مثال: Seconds
  • Wait Till (زمان/تاریخ مقصد) | نوع داده: DateTime/String | توضیح: زمان دقیق برای ادامه اجرای ورکفلو (در حالت Until) | مثال: 2026-02-07T09:00:00+03:30
  • Timezone (منطقه زمانی) | نوع داده: String/Option | توضیح: تعیین منطقه زمانی برای تفسیر زمان مقصد (در حالت Until) | مثال: Asia/Tehran

مثال عملی برای هر حالت

حالت Delay (مکث به مدت مشخص)

  • Mode: Delay
  • Amount: 30
  • Unit: Seconds

کاربرد: بین دو درخواست HTTP یا بین ارسال پیام‌ها 30 ثانیه مکث ایجاد می‌کند.

حالت Until (صبر تا زمان مشخص)

  • Mode: Until
  • Wait Till: 2026-02-07T09:00:00+03:30
  • Timezone: Asia/Tehran

کاربرد: ورکفلو را تا ساعت 9 صبح زمان تهران نگه می‌دارد و سپس ادامه می‌دهد.

نکات مهم هنگام پیکربندی

  • انتخاب واحد مناسب: برای تاخیرهای کوتاه، ثانیه مناسب است؛ برای زمان‌بندی‌های روزانه، حالت Until دقیق‌تر و قابل‌فهم‌تر است.
  • توجه به Timezone: اگر ورکفلو روی سرور با منطقه زمانی متفاوت اجرا می‌شود، حتماً Timezone را مشخص کنید تا اختلاف ساعت رخ ندهد.
  • استفاده از Expression: می‌توانید زمان انتظار را از داده‌های ورودی محاسبه کنید (مثلاً از فیلد dueDate یا nextFollowUpAt).
  • اجتناب از مکث‌های خیلی طولانی در طراحی بد: برای فرآیندهای بسیار بلندمدت، طراحی باید طوری باشد که مدیریت و خطایابی آسان بماند (مثلاً ثبت وضعیت در دیتابیس و ادامه کار با Trigger یا Schedule).

ورودی‌ها و خروجی‌ها

ورودی (Input)

نود Wait معمولاً آیتم‌های ورودی را بدون تغییر ساختاری دریافت می‌کند. هر آیتمی که وارد Wait می‌شود، بعد از پایان انتظار، همان آیتم به مرحله بعدی منتقل می‌شود.

خروجی (Output)

خروجی نود Wait همان داده‌های ورودی است (Pass-through). یعنی این نود برای تغییر داده نیست، بلکه برای کنترل زمان اجرای جریان است.

نمونه JSON ورودی/خروجی

فرض کنید ورودی شما یک آیتم مانند زیر باشد:

{  "userId": 123,  "phone": "+989121234567",  "message": "پیگیری سفارش",  "nextSendAt": "2026-02-07T09:00:00+03:30"}

اگر Wait را روی حالت Until و با Expression برابر nextSendAt تنظیم کنید، پس از رسیدن زمان، خروجی همان داده خواهد بود:

{  "userId": 123,  "phone": "+989121234567",  "message": "پیگیری سفارش",  "nextSendAt": "2026-02-07T09:00:00+03:30"}

نکات پیشرفته و ترفندها

1) انتظار پویا با Expression

می‌توانید Amount یا Wait Till را با Expression از روی فیلدهای ورودی بسازید. مثال: زمان ارسال بعدی داخل داده ذخیره شده است و Wait Till از همان مقدار خوانده می‌شود.

  • Wait Till: {{$json.nextSendAt}}

2) کنترل Batchها با Split In Batches + Wait

برای پردازش لیست بزرگ (مثلاً 500 کاربر) بهتر است آن را batch کنید و بین batchها یا بین آیتم‌ها مکث بگذارید تا هم منابع کمتر مصرف شود و هم rate limit رعایت شود.

  • الگو: Split In Batches (size=10) → Loop → HTTP Request/Send Message → Wait (2s) → Next Batch

3) جلوگیری از هم‌زمانی ناخواسته

اگر چند اجرای همزمان دارید، Wait به‌تنهایی قفل (Lock) ایجاد نمی‌کند. برای جلوگیری از تداخل، می‌توانید از ترکیب‌هایی مثل Data Store/DB برای ثبت وضعیت یا از الگوهای صف (Queue) استفاده کنید و سپس Wait را فقط برای فاصله‌گذاری زمانی به کار ببرید.

4) طراحی پایدار برای زمان‌های طولانی

برای زمان‌های طولانی (مثلاً چند روز)، بهتر است علاوه بر Wait، یک شناسه پیگیری در دیتابیس ثبت کنید تا اگر نیاز به بررسی/گزارش داشتید، وضعیت قابل مشاهده باشد. این کار در خطایابی و مانیتورینگ بسیار موثر است.

محدودیت‌ها و خطاها

محدودیت‌ها

  • Wait داده را تغییر نمی‌دهد: اگر نیاز به ساخت/تبدیل تاریخ دارید، از Set، Date & Time، Function یا Code Node استفاده کنید.
  • برای کنترل هم‌زمانی کافی نیست: اگر هدف شما جلوگیری از اجرای همزمان چند ورکفلو روی یک منبع است، باید از مکانیزم‌های قفل/صف استفاده شود.
  • وابستگی به تنظیمات زمان سرور و تایم‌زون: در حالت Until اگر تایم‌زون مشخص نباشد، ممکن است اختلاف زمانی رخ دهد.

خطاهای رایج و راه‌حل‌ها

  • زمان اشتباه (اختلاف چند ساعت): علت معمول، Timezone یا فرمت تاریخ است. راه‌حل: Timezone را صریح تنظیم کنید (مثلاً Asia/Tehran) و از ISO 8601 استفاده کنید.
  • Wait Till نامعتبر: اگر مقدار تاریخ از ورودی می‌آید و خالی/غلط است، نود خطا می‌دهد یا رفتار نامشخص ایجاد می‌شود. راه‌حل: قبل از Wait با IF بررسی کنید فیلد تاریخ وجود دارد و معتبر است.
  • کند شدن ورکفلو در پردازش‌های انبوه: اگر برای هر آیتم Wait طولانی گذاشته شود، مدت اجرای کلی زیاد می‌شود. راه‌حل: batching، کاهش delay، یا استفاده از زمان‌بندی‌های مناسب‌تر (مثل schedule + ذخیره وضعیت).

ایده ها

  • سیستم پیگیری لیدها: ثبت لید و ارسال پیام اول، سپس Wait تا فردا صبح و ارسال پیام دوم
  • ارسال تدریجی کمپین: تقسیم کاربران به batch و ارسال پیام با فاصله برای جلوگیری از مسدود شدن سرویس پیام‌رسان
  • پایش وضعیت سفارش: بعد از ثبت سفارش، Wait چند دقیقه و سپس چک وضعیت پرداخت/ارسال از API
  • زمان‌بندی انتشار محتوا: آماده‌سازی متن/تصویر و Wait تا زمان انتشار، سپس ارسال به شبکه اجتماعی
  • کنترل بار روی دیتابیس: اجرای کوئری‌های سنگین در ساعات کم‌مصرف با Wait تا ساعت مشخص

منابع و مستندات اصلی

دسته بندی: N8N برچسب ها:

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

پنج × 5 =