نود Stop and Error در N8N

نود Stop and Error در N8N

نود Stop and Error یکی از نودهای کنترلی و بسیار کاربردی در N8N است که برای متوقف کردن عمدی اجرای ورکفلو و ایجاد خطا استفاده می‌شود. این نود زمانی مفید است که بخواهید در صورت نامعتبر بودن داده‌ها، شکست یک شرط مهم، نبود اطلاعات ضروری یا رخ دادن یک وضعیت غیرقابل قبول، اجرای فرآیند را متوقف کنید و یک پیام خطای مشخص ثبت شود.

به زبان ساده، این نود مثل یک ترمز اضطراری در ورکفلو عمل می‌کند. هر جا که ادامه اجرای اتوماسیون می‌تواند باعث ارسال داده اشتباه، ثبت اطلاعات ناقص، اجرای درخواست اشتباه یا ایجاد هزینه اضافی شود، می‌توانید از Stop and Error استفاده کنید.

معرفی نود در N8N

نود Stop and Error برای متوقف کردن اجرای ورکفلو با تولید یک خطا استفاده می‌شود. این خطا در Execution History نود N8N ثبت می‌شود و در صورت فعال بودن Error Workflow، می‌تواند باعث اجرای ورکفلو مدیریت خطا شود.

  • نام نود: Stop and Error
  • دسته‌بندی: Action / Flow Control
  • نوع عملکرد: توقف اجرای ورکفلو و ایجاد خطای سفارشی
  • کاربرد اصلی: کنترل شرایط بحرانی، اعتبارسنجی داده‌ها، جلوگیری از ادامه اجرای اشتباه و فعال‌سازی فرآیندهای مدیریت خطا

در بسیاری از ورکفلوها، همه مراحل نباید همیشه اجرا شوند. گاهی لازم است اگر یک مقدار خاص وجود نداشت، اگر پاسخ API معتبر نبود، اگر کاربر مجوز نداشت یا اگر داده ورودی ناقص بود، اجرای کل جریان متوقف شود. در چنین شرایطی Stop and Error انتخاب مناسبی است.

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

نود Stop and Error معمولاً در بخش‌هایی از ورکفلو استفاده می‌شود که نیاز به کنترل کیفیت داده، توقف شرطی یا مدیریت خطا وجود دارد.

اعتبارسنجی اطلاعات ورودی

فرض کنید یک فرم ثبت‌نام دارید و اطلاعات کاربران از طریق Webhook وارد N8N می‌شود. اگر ایمیل، شماره موبایل یا شناسه کاربر خالی باشد، ادامه فرآیند مثل ثبت در CRM یا ارسال پیام خوش‌آمدگویی منطقی نیست. در این حالت می‌توانید با نود IF بررسی کنید که فیلد ایمیل وجود دارد یا نه، و در مسیر خطا از Stop and Error استفاده کنید.

  • Webhook اطلاعات فرم را دریافت می‌کند.
  • IF بررسی می‌کند که فیلد email خالی نباشد.
  • اگر email وجود نداشت، Stop and Error اجرا می‌شود.
  • پیام خطا در Execution ثبت می‌شود.

جلوگیری از ارسال درخواست اشتباه به API

در پروژه‌هایی که با APIهای خارجی کار می‌کنند، ارسال درخواست اشتباه می‌تواند باعث محدودیت، هزینه، خطای امنیتی یا ثبت داده نادرست شود. با Stop and Error می‌توانید قبل از ارسال درخواست، شرایط لازم را بررسی کنید.

مثال: قبل از ارسال سفارش به یک API فروشگاهی، بررسی کنید که مقدار orderId و totalPrice معتبر باشد. اگر totalPrice صفر یا منفی بود، اجرای ورکفلو متوقف شود.

مدیریت خطا در ورکفلوهای حساس

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

ترکیب با نود IF

یکی از رایج‌ترین ترکیب‌ها، استفاده از Stop and Error بعد از نود IF است. نود IF شرط را بررسی می‌کند و اگر شرط برقرار نبود، Stop and Error اجرا می‌شود.

  • IF: آیا فیلد customer_id وجود دارد؟
  • True: ادامه ورکفلو
  • False: اجرای Stop and Error با پیام Customer ID is missing

ترکیب با نود Switch

در سناریوهایی که چند حالت مختلف دارید، می‌توانید از Switch استفاده کنید و برای حالت‌های نامعتبر، مسیر را به Stop and Error وصل کنید.

مثال: وضعیت سفارش فقط باید یکی از مقادیر pending، paid یا cancelled باشد. اگر مقدار دیگری دریافت شد، Stop and Error اجرا شود.

ترکیب با Code Node

گاهی لازم است اعتبارسنجی پیچیده‌تری انجام دهید. می‌توانید در Code Node داده‌ها را بررسی و یک فیلد مثل isValid یا errorMessage تولید کنید، سپس با IF نتیجه را به Stop and Error هدایت کنید.

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

نود Stop and Error تنظیمات ساده‌ای دارد، اما همین تنظیمات در طراحی ورکفلوهای حرفه‌ای اهمیت زیادی دارند. این نود معمولاً دو روش اصلی برای تعریف خطا در اختیار شما قرار می‌دهد: پیام خطا یا آبجکت خطا.

لیست پارامترها

نام پارامتر نوع داده توضیح کاربرد مثال عملی
Error Type Options مشخص می‌کند خطا به چه شکلی ایجاد شود؛ به صورت پیام متنی ساده یا به صورت آبجکت JSON. Error Message
Error Message String متن خطایی که هنگام توقف ورکفلو نمایش داده و ثبت می‌شود. این گزینه زمانی استفاده می‌شود که Error Type روی Error Message باشد. Customer email is required
Error Object JSON یک آبجکت JSON برای تعریف خطای ساختاریافته. این گزینه برای زمانی مناسب است که می‌خواهید جزئیات بیشتری مثل کد خطا، نام فیلد، مقدار ورودی یا منبع خطا ذخیره کنید. {“code”:”MISSING_EMAIL”,”field”:”email”,”message”:”Email is required”}

Error Type

پارامتر Error Type تعیین می‌کند خطا به چه فرمتی ایجاد شود. معمولاً دو حالت اصلی دارد:

  • Error Message: برای ثبت یک پیام خطای ساده و خوانا
  • Error Object: برای ثبت خطا به صورت ساختاریافته و قابل پردازش

برای کاربران مبتدی، استفاده از Error Message ساده‌تر است. اما در ورکفلوهای حرفه‌ای، Error Object انتخاب بهتری است چون می‌توانید اطلاعات بیشتری را در خطا ذخیره کنید.

Error Message

این فیلد زمانی نمایش داده می‌شود که Error Type روی Error Message باشد. مقدار این فیلد همان متنی است که هنگام توقف اجرای ورکفلو ثبت می‌شود.

نمونه پیام‌های مناسب:

  • Required field email is missing
  • Invalid order status received
  • Payment amount must be greater than zero
  • API response does not contain customerId

می‌توانید در این فیلد از Expressionهای N8N هم استفاده کنید تا پیام خطا بر اساس داده‌های ورودی ساخته شود.

مثال:

Invalid order status: {{$json.status}}

اگر مقدار status برابر archived باشد، خطا می‌تواند به این شکل ثبت شود:

Invalid order status: archived

Error Object

این فیلد زمانی استفاده می‌شود که بخواهید خطا را به صورت JSON تعریف کنید. استفاده از Error Object در پروژه‌های بزرگ بسیار کاربردی است، چون اطلاعات خطا را قابل تحلیل و استاندارد می‌کند.

نمونه Error Object:

{  "code": "VALIDATION_ERROR",  "message": "Customer email is missing",  "field": "email",  "source": "Webhook Form",  "severity": "high"}

نمونه Error Object با Expression:

{  "code": "INVALID_STATUS",  "message": "Received unsupported order status",  "status": "{{$json.status}}",  "orderId": "{{$json.orderId}}"}

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

  • اگر از Error Object استفاده می‌کنید، ساختار JSON باید معتبر باشد.
  • در پیام خطا اطلاعات محرمانه مثل رمز عبور، توکن API یا اطلاعات بانکی قرار ندهید.
  • پیام خطا را واضح و قابل فهم بنویسید تا هنگام بررسی Execution سریع متوجه مشکل شوید.
  • برای خطاهای قابل دسته‌بندی، از کد خطا استفاده کنید؛ مثل MISSING_FIELD یا INVALID_AMOUNT.
  • اگر هدف فقط توقف مسیر بدون ثبت خطا است، Stop and Error انتخاب مناسبی نیست و باید از طراحی شرطی یا نودهای کنترل جریان دیگر استفاده شود.

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

نود Stop and Error می‌تواند در مسیر اجرای ورکفلو داده ورودی دریافت کند، اما هدف آن پردازش و تولید خروجی عادی نیست. این نود با اجرای خود باعث توقف Workflow Execution می‌شود.

ورودی نود

ورودی این نود معمولاً داده‌ای است که از نود قبلی وارد می‌شود. Stop and Error می‌تواند از همین داده‌ها برای ساخت پیام خطا یا Error Object استفاده کند.

نمونه داده ورودی:

{  "orderId": "ORD-1005",  "customerEmail": "",  "totalPrice": 250000,  "status": "paid"}

در این مثال، customerEmail خالی است. بنابراین می‌توان با یک IF بررسی کرد که این فیلد خالی است و سپس Stop and Error را اجرا کرد.

نمونه پیام خطا بر اساس ورودی

Customer email is missing for order {{$json.orderId}}

خروجی خطای ثبت‌شده:

Customer email is missing for order ORD-1005

خروجی نود

Stop and Error خروجی عادی برای ادامه ورکفلو تولید نمی‌کند، چون اجرای ورکفلو را متوقف می‌کند. بعد از اجرای این نود، نودهای بعدی در همان مسیر اجرا نمی‌شوند.

  • خروجی موفق: ندارد
  • نتیجه اجرا: توقف Workflow Execution
  • ثبت خطا: در Execution History
  • امکان فعال‌سازی Error Workflow: بله، در صورت تنظیم بودن

نمونه ساختار Error Object

{  "code": "MISSING_REQUIRED_FIELD",  "message": "customerEmail is required",  "field": "customerEmail",  "orderId": "ORD-1005",  "timestamp": "2026-05-18T10:30:00.000Z"}

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

استفاده از Stop and Error برای اعتبارسنجی چندمرحله‌ای

در ورکفلوهای واقعی، معمولاً یک شرط کافی نیست. ممکن است بخواهید چندین فیلد را بررسی کنید. برای این کار می‌توانید از ترکیب Set، Code، IF و Stop and Error استفاده کنید.

مثال اعتبارسنجی:

  • آیا email وجود دارد؟
  • آیا amount عددی مثبت است؟
  • آیا status در لیست وضعیت‌های مجاز قرار دارد؟
  • آیا userId معتبر است؟

اگر هرکدام از این موارد نامعتبر بود، Stop and Error با پیام مشخص اجرا می‌شود.

ساخت خطاهای استاندارد برای تیم‌ها

در تیم‌های فنی بهتر است همه خطاها الگوی یکسان داشته باشند. به جای پیام‌های پراکنده، می‌توانید از Error Object استاندارد استفاده کنید.

{  "code": "VALIDATION_ERROR",  "message": "Invalid input data",  "details": {    "field": "amount",    "reason": "Amount must be greater than zero"  },  "workflow": "Invoice Automation",  "severity": "medium"}

این روش باعث می‌شود بررسی خطاها در لاگ‌ها، Error Workflow یا سیستم‌های مانیتورینگ ساده‌تر شود.

ترکیب با Error Trigger

اگر در N8N برای ورکفلو خود Error Workflow تنظیم کرده باشید، اجرای Stop and Error می‌تواند آن را فعال کند. این قابلیت برای ارسال اعلان خطا به Slack، Telegram، Email یا سیستم مانیتورینگ بسیار کاربردی است.

سناریوی نمونه:

  • Webhook داده سفارش را دریافت می‌کند.
  • IF داده‌ها را بررسی می‌کند.
  • در صورت خطای اعتبارسنجی، Stop and Error اجرا می‌شود.
  • Error Workflow فعال می‌شود.
  • یک پیام خطا به Slack تیم فنی ارسال می‌شود.

جلوگیری از هزینه‌های اضافی

اگر در ادامه ورکفلو از APIهای پولی، مدل‌های هوش مصنوعی، ارسال پیامک یا سرویس‌های محدود استفاده می‌کنید، Stop and Error می‌تواند قبل از رسیدن داده نامعتبر به آن بخش‌ها، اجرای فرآیند را متوقف کند.

مثال: اگر متن ورودی کاربر خالی بود، قبل از ارسال آن به OpenAI یا هر سرویس AI دیگر، Stop and Error اجرا شود.

استفاده از Expression در پیام خطا

یکی از قابلیت‌های مهم Stop and Error، امکان استفاده از Expression در پیام خطا است. با این کار می‌توانید خطاهای دقیق‌تر و قابل ردیابی‌تر تولید کنید.

Order {{$json.orderId}} failed validation because amount is {{$json.amount}}

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

ثبت شناسه رکورد در خطا

در ورکفلوهایی که با رکوردهای متعدد کار می‌کنند، همیشه شناسه رکورد را در پیام یا آبجکت خطا قرار دهید.

{  "code": "CRM_UPDATE_FAILED",  "message": "Missing CRM contact ID",  "contactEmail": "{{$json.email}}",  "sourceRecordId": "{{$json.id}}"}

با این روش، پیدا کردن رکورد مشکل‌دار در سیستم منبع بسیار سریع‌تر انجام می‌شود.

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

محدودیت‌های نود Stop and Error

  • این نود برای ادامه دادن جریان طراحی نشده است و پس از اجرا، مسیر را متوقف می‌کند.
  • خروجی عادی برای نودهای بعدی تولید نمی‌کند.
  • برای مدیریت خطاهای قابل بازیابی مناسب نیست؛ چون اجرای ورکفلو را شکست‌خورده می‌کند.
  • اگر پیام خطا بیش از حد کلی باشد، دیباگ کردن سخت می‌شود.
  • اگر Error Object JSON نامعتبر داشته باشد، خود پیکربندی نود می‌تواند باعث خطا شود.

خطای رایج: پیام خطا نامفهوم است

یکی از اشتباهات رایج، استفاده از پیام‌های کلی مثل Error یا Failed است. این پیام‌ها در زمان بررسی Execution کمک زیادی نمی‌کنند.

نمونه نامناسب:

Error

نمونه مناسب:

Customer email is missing for order {{$json.orderId}}

خطای رایج: JSON نامعتبر در Error Object

اگر از Error Object استفاده می‌کنید، باید JSON معتبر وارد کنید. فراموش کردن کوتیشن، کاما یا آکولاد باعث خطا می‌شود.

نمونه نامعتبر:

{  code: "INVALID_AMOUNT",  message: "Amount is invalid"}

نمونه معتبر:

{  "code": "INVALID_AMOUNT",  "message": "Amount is invalid"}

خطای رایج: قرار دادن اطلاعات حساس در پیام خطا

پیام خطا ممکن است در Execution History یا سیستم‌های مانیتورینگ ذخیره شود. بنابراین نباید اطلاعات حساس را در آن قرار دهید.

  • توکن API
  • رمز عبور
  • کدهای امنیتی
  • اطلاعات کامل کارت بانکی
  • کلیدهای خصوصی یا Secretها

خطای رایج: استفاده از Stop and Error به جای شرط‌گذاری ساده

اگر فقط می‌خواهید یک مسیر خاص اجرا نشود ولی اجرای کلی ورکفلو شکست‌خورده محسوب نشود، بهتر است از IF، Switch، No Operation یا طراحی مسیرهای جداگانه استفاده کنید. Stop and Error زمانی مناسب است که واقعاً می‌خواهید اجرای ورکفلو با خطا متوقف شود.

راه‌حل‌های پیشنهادی برای خطاهای رایج

  • برای هر خطا یک پیام واضح و قابل ردیابی بنویسید.
  • از کد خطاهای استاندارد مثل VALIDATION_ERROR یا MISSING_FIELD استفاده کنید.
  • قبل از Stop and Error، داده‌ها را با IF یا Code بررسی کنید.
  • برای پروژه‌های حساس، Error Workflow جداگانه بسازید.
  • در Error Object فقط اطلاعات لازم و غیرمحرمانه را ثبت کنید.

ایده ها

  • سیستم اعتبارسنجی فرم‌های ورودی: بررسی داده‌های دریافتی از Webhook و توقف اجرای ورکفلو در صورت نبود فیلدهای ضروری مثل email، phone یا name.
  • کنترل سفارش‌های فروشگاهی: توقف فرآیند ثبت سفارش اگر مبلغ سفارش صفر، وضعیت سفارش نامعتبر یا شناسه مشتری خالی باشد.
  • مانیتورینگ کیفیت داده‌ها: بررسی داده‌های واردشده از Google Sheets، Airtable یا CRM و ایجاد خطا برای رکوردهای ناقص یا ناسازگار.
  • جلوگیری از مصرف APIهای پولی: توقف ورکفلو قبل از ارسال درخواست به سرویس‌های گران‌قیمت مثل AI، پیامک انبوه یا APIهای محدود، در صورت ناقص بودن ورودی.
  • فعال‌سازی هشدارهای تیم فنی: ترکیب Stop and Error با Error Trigger برای ارسال پیام خطا به Slack، Telegram یا Email هنگام رخ دادن شرایط بحرانی.

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

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

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

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

6 + 3 =