یکی از چالشهای مهم هنگام ساخت اتوماسیون با n8n، مدیریت خطاهایی است که ممکن است در زمان اجرای Workflow اتفاق بیفتند. برای مثال، فرض کنید یک Workflow سفارشهای فروشگاه اینترنتی را دریافت میکند، اطلاعات سفارش را پردازش میکند و سپس آن را به یک سرویس دیگر میفرستد. اگر API مقصد از دسترس خارج شود یا اطلاعات ورودی ناقص باشد، ممکن است اجرای Workflow با خطا مواجه شود.
اگر برای چنین شرایطی راهکاری در نظر نگرفته باشید، احتمال دارد فرایند ناقص بماند، اطلاعرسانی انجام نشود یا بررسی مشکل بهصورت دستی و زمانبر صورت بگیرد.
در n8n قابلیتی به نام Error Handling برای مدیریت خطاها وجود دارد. با استفاده از تنظیمات اجرای Nodeها، مسیرهای کنترل خطا و Workflowهای اختصاصی میتوانید رفتار اتوماسیون را هنگام بروز مشکل مشخص کنید.
در این آموزش، روشهای اصلی مدیریت خطا در n8n را با مثالهای عملی بررسی میکنیم.
Error Handling در n8n چیست؟
Error Handling به مجموعه روشهایی گفته میشود که برای شناسایی، کنترل، ثبت و واکنش به خطاهای یک Workflow استفاده میشوند.
خطا ممکن است در بخشهای مختلف یک اتوماسیون اتفاق بیفتد؛ از جمله:
- دریافت اطلاعات از API
- پردازش دادهها در Code Node
- اتصال به پایگاه داده
- ارسال پیام به تلگرام
- احراز هویت ناموفق در یک سرویس
- دریافت دادههای ناقص یا غیرمنتظره
- بروز خطا در یک سرویس خارجی
برای مدیریت این شرایط، باید مشخص کنید در صورت بروز خطا چه اتفاقی بیفتد. آیا اجرای Workflow متوقف شود؟ آیا اطلاعات خطا برای بررسی ارسال شود؟ آیا فقط یک مورد ناموفق ثبت شود و پردازش موارد دیگر ادامه پیدا کند؟
پاسخ به این پرسشها به منطق کسبوکار شما بستگی دارد.
برای مثال، در یک Workflow ارسال خبرنامه، ممکن است بخواهید خطای ارسال پیام برای یک مخاطب ثبت شود و پردازش مخاطبان دیگر ادامه پیدا کند. اما در یک Workflow مالی، ادامه پردازش پس از خطای اعتبارسنجی یا ثبت تراکنش ممکن است خطرناک باشد.
بنابراین، هدف مدیریت خطا صرفاً جلوگیری از توقف Workflow نیست؛ هدف این است که سیستم در شرایط غیرعادی، رفتاری قابل پیشبینی و قابل بررسی داشته باشد.
روشهای مدیریت خطا در n8n
n8n ابزارهای مختلفی برای کنترل خطا در اختیار شما قرار میدهد. مهمترین آنها عبارتاند از:
| قابلیت | کاربرد |
|---|---|
| Error Workflow و Error Trigger | اجرای یک Workflow جداگانه برای رسیدگی به خطا |
| Stop And Error | ایجاد عمدی خطا و متوقف کردن اجرای جاری |
| On Error و Continue | تعیین رفتار Node هنگام بروز خطا |
| Continue On Fail در نسخهها یا رابطهای قدیمیتر | کنترل ادامه اجرا پس از خطا در تنظیمات قدیمیتر |
| Retry On Fail | تلاش مجدد برای اجرای Node ناموفق |
نام و محل دقیق برخی تنظیمات ممکن است با توجه به نسخه n8n متفاوت باشد. در نسخههای جدیدتر، برای تنظیم رفتار خطا در Nodeها معمولاً باید بخش تنظیمات یا گزینهای با عنوان On Error را بررسی کنید.
در ادامه، کاربرد این قابلیتها را بررسی میکنیم.
۱. ساخت Error Workflow با استفاده از Error Trigger
یکی از روشهای کاربردی مدیریت خطا در n8n، ساخت یک Workflow جداگانه برای رسیدگی به خطاهای Workflowهای دیگر است.
برای مثال، اگر چند اتوماسیون مهم دارید، میتوانید Workflow مشخصی بسازید که هنگام شکست یکی از آنها، اطلاعات مربوط به خطا را دریافت کند و برای مدیر سیستم پیام هشدار بفرستد.
این Workflow معمولاً با Nodeای به نام Error Trigger شروع میشود.
مرحله اول: یک Workflow جدید بسازید
وارد پنل n8n شوید و یک Workflow جدید ایجاد کنید.
برای اینکه نقش آن مشخص باشد، نامی مانند زیر انتخاب کنید:
مدیریت خطاهای سیستم
این Workflow قرار است مسئول دریافت اطلاعات خطا و انجام اقدامات لازم باشد.
مرحله دوم: Node مربوط به Error Trigger را اضافه کنید
در فهرست Nodeها، عبارت Error Trigger را جستوجو کنید و آن را به Workflow اضافه کنید.
این Node برای شروع اجرای Error Workflow در واکنش به خطاهای Workflowهای دیگری استفاده میشود که به آن متصل شدهاند.
نکته مهم این است که Error Trigger مانند یک Trigger معمولی نیست که با فشردن دکمه اجرای دستی، لزوماً یک خطای واقعی را دریافت کند. برای آزمایش آن باید سازوکار واقعی فراخوانی Error Workflow را در نظر بگیرید.
مرحله سوم: اطلاعات خطا را بررسی کنید
وقتی Error Workflow در واکنش به یک خطا اجرا میشود، اطلاعاتی درباره اجرای ناموفق در اختیار شما قرار میگیرد. بسته به نوع خطا و نسخه n8n، این اطلاعات میتواند شامل مواردی مانند نام Workflow، جزئیات خطا، Node ناموفق و شناسه اجرای مربوطه باشد.
برای مشاهده ساختار دقیق دادهها، یک اجرای آزمایشی ایجاد کنید و خروجی Error Trigger را بررسی کنید.
برای نمونه، ممکن است دادههای خطا از نظر مفهومی شامل چنین اطلاعاتی باشند:
{
"workflow": {
"name": "پردازش سفارش"
},
"execution": {
"url": "https://n8n.example.com/execution/123"
},
"error": {
"message": "Request failed"
}
}
این JSON صرفاً نمونهای آموزشی است و ساختار دقیق خروجی واقعی Error Trigger را تضمین نمیکند. در Workflow خودتان باید از نام فیلدهایی استفاده کنید که واقعاً در خروجی Node وجود دارند.
مرحله چهارم: یک اقدام برای مدیریت خطا اضافه کنید
بعد از Error Trigger میتوانید Nodeهای دیگری قرار دهید. برای مثال:
- ارسال هشدار به تلگرام
- ارسال ایمیل به مدیر سیستم
- ثبت اطلاعات خطا در پایگاه داده
- ارسال گزارش به یک سرویس مانیتورینگ
- اطلاعرسانی به تیم پشتیبانی
فرض کنید میخواهید در زمان شکست یک Workflow، به مدیر سیستم هشدار بدهید. در این حالت میتوانید یک Node ارسال پیام اضافه کنید و در متن آن، نام Workflow و پیام خطا را از دادههای دریافتی بخوانید.
برای انتخاب فیلدهای درست، ابتدا خروجی واقعی Error Trigger را بررسی کنید. از نوشتن نام فیلدها بر اساس حدس خودداری کنید.
مرحله پنجم: Error Workflow را فعال و به Workflow اصلی متصل کنید
صرف ساختن Workflow خطا کافی نیست. باید آن را بهعنوان Error Workflow در تنظیمات Workflow اصلی انتخاب کنید.
مراحل کلی:
- Workflow مدیریت خطا را ذخیره کنید.
- مطمئن شوید تنظیمات و Nodeهای آن درست هستند.
- Workflow اصلی را باز کنید.
- به تنظیمات Workflow بروید.
- گزینه مربوط به Error Workflow را پیدا کنید.
- Workflow مدیریت خطا را انتخاب و تنظیمات را ذخیره کنید.
محل دقیق این گزینه ممکن است بین نسخههای n8n تفاوت داشته باشد.
پس از تنظیم، یک اجرای آزمایشی ایجاد کنید که بهصورت کنترلشده با خطا مواجه شود و بررسی کنید آیا Error Workflow مطابق انتظار اجرا میشود یا خیر.
نکته: Error Workflow باید برای اجرای واقعی از طریق خطا تنظیم شده باشد. همچنین، اگر خود Error Workflow شکست بخورد، نباید فرض کنید که خطای آن حتماً توسط همان سازوکار مدیریت خواهد شد. مسیر رسیدگی به شکست Error Workflow را جداگانه بررسی کنید.
۲. استفاده از Stop And Error برای ایجاد خطای کنترلشده
گاهی خطا به دلیل قطعی سرویس یا مشکل شبکه اتفاق نمیافتد، بلکه اطلاعات دریافتی با شرایط مورد انتظار شما مطابقت ندارد.
برای مثال، فرض کنید یک Workflow مبلغ سفارش را دریافت میکند. اگر مبلغ کمتر از صفر باشد، ادامه پردازش نباید انجام شود.
در چنین شرایطی میتوانید با استفاده از Node مربوط به Stop And Error اجرای جاری را بهصورت عمدی با خطا متوقف کنید.
مثال: اعتبارسنجی مبلغ سفارش
فرض کنید داده ورودی Workflow چنین ساختاری دارد:
{
"order_id": 1501,
"amount": -250
}
در این مثال، مبلغ سفارش منفی است و باید قبل از ادامه پردازش بررسی شود.
مرحله اول: داده ورودی را دریافت کنید
ابتدا داده سفارش را از Trigger یا Node قبلی دریافت کنید.
برای مثال، ممکن است اطلاعات از Webhook، فرم یا API وارد Workflow شده باشند.
مرحله دوم: یک Node از نوع IF اضافه کنید
Node مربوط به IF را به Workflow اضافه کنید و شرطی تعریف کنید که مبلغ سفارش را بررسی کند.
برای نمونه، میتوانید شرطی قرار دهید که مشخص کند آیا مقدار amount کمتر از صفر است یا خیر.
اگر ساختار داده ورودی با مثال ما یکسان باشد، Expression مربوط به مبلغ میتواند به این شکل باشد:
{{ $json.amount }}
شرط را با توجه به نوع داده و امکانات نسخه خود تنظیم کنید.
مرحله سوم: مسیر نامعتبر را به Stop And Error متصل کنید
در خروجی مربوط به مبلغ نامعتبر، یک Node از نوع Stop And Error قرار دهید.
در تنظیمات این Node، یک پیام واضح برای خطا تعریف کنید؛ برای مثال:
مبلغ سفارش نامعتبر است و نمیتوان پردازش را ادامه داد.
به این ترتیب، اگر شرط برقرار باشد، اجرای جاری Workflow با خطای مشخصشده متوقف میشود.
مرحله چهارم: مسیر معتبر را جداگانه ادامه دهید
مسیر دیگر IF را به Nodeهای پردازش سفارش متصل کنید. در این مسیر، فقط سفارشهایی که از شرط اعتبارسنجی عبور کردهاند، به مراحل بعدی میروند.
این الگو باعث میشود خطاهای مربوط به دادههای نامعتبر بهجای ایجاد نتایج اشتباه، بهصورت مشخص ثبت شوند.
البته در یک سیستم مالی واقعی، بررسی مبلغ بهتنهایی کافی نیست. باید اعتبارسنجیهای لازم دیگری مانند شناسه سفارش، وضعیت پرداخت، مالکیت سفارش و قواعد کسبوکار نیز اجرا شوند.
۳. ادامه اجرا پس از خطا با تنظیمات On Error
در بعضی Workflowها، شکست یک Node نباید کل فرایند را متوقف کند. برای مثال، فرض کنید اطلاعات ۱۰۰ مخاطب را پردازش میکنید. اگر ارسال پیام برای یک مخاطب ناموفق شود، ممکن است بخواهید پردازش مخاطبان دیگر ادامه پیدا کند.
در n8n میتوانید رفتار Node هنگام بروز خطا را از طریق تنظیمات آن کنترل کنید.
چگونه رفتار خطا را تغییر دهیم؟
- Node موردنظر را باز کنید.
- وارد بخش تنظیمات شوید.
- گزینه مربوط به رفتار هنگام خطا، معمولاً با عنوان
On Error، را پیدا کنید. - گزینه مناسب را با توجه به منطق Workflow انتخاب کنید.
بسته به نسخه n8n، ممکن است گزینههایی برای توقف اجرا، ادامه دادن یا ادامه دادن همراه با خروجی خطا در دسترس باشند.
در برخی رابطها یا نسخههای قدیمیتر، تنظیماتی مانند Continue On Fail دیده میشود. در نسخههایی که تنظیمات به ساختار جدیدتری منتقل شدهاند، باید رفتار معادل را در بخش On Error بررسی کنید.
چه زمانی ادامه اجرا مناسب است؟
ادامه اجرا ممکن است در شرایطی مناسب باشد که هر مورد بهصورت مستقل پردازش میشود؛ برای مثال:
- ارسال پیام برای چند مخاطب مستقل
- پردازش مجموعهای از فایلها
- بررسی فهرستی از محصولات
- ثبت نتیجه پردازش هر ردیف بهصورت جداگانه
اما اگر عملیات به عملیات قبلی وابسته باشد، ادامه دادن بدون بررسی نتیجه میتواند مشکلساز شود.
برای مثال، اگر مرحله ثبت پرداخت شکست بخورد، ادامه دادن به مرحله ارسال سفارش ممکن است باعث شود سفارش بدون ثبت صحیح پرداخت پردازش شود.
بنابراین، انتخاب رفتار خطا باید بر اساس اهمیت عملیات و وابستگی مراحل انجام شود.
تفاوت ادامه اجرا با مدیریت کامل خطا
فعال کردن ادامه اجرا به این معنی نیست که خطا حل شده است.
ممکن است Node ناموفق باشد، اما Workflow همچنان ادامه پیدا کند. اگر نتیجه شکست در جایی ثبت نشود یا بررسی نشود، احتمال دارد مشکل پنهان بماند.
در چنین شرایطی بهتر است:
- اطلاعات خطا ثبت شود.
- وضعیت هر مورد مشخص باشد.
- نتیجه عملیات در مراحل بعدی بررسی شود.
- در صورت نیاز، هشدار مناسب ارسال شود.
هدف این است که اجرای Workflow قابل کنترل باشد، نه اینکه خطاها نادیده گرفته شوند.
۴. ثبت خطاها برای بررسی و عیبیابی
اگر Workflowهای مهم دارید، بهتر است اطلاعات مربوط به خطاهای آنها را به شکلی ثبت کنید که بعداً قابل بررسی باشند.
برای مثال، فرض کنید Workflow پردازش سفارش گاهی با خطا مواجه میشود. اگر فقط پیام خطا را مشاهده کنید، ممکن است نتوانید تشخیص دهید کدام سفارش یا کدام اجرا مشکل داشته است.
ثبت اطلاعات تکمیلی میتواند عیبیابی را سادهتر کند.
مواردی که بسته به نیاز سیستم میتوانید ثبت کنید عبارتاند از:
- نام Workflow
- شناسه اجرای ناموفق
- نام Node ناموفق
- زمان وقوع خطا
- پیام خطا
- شناسه رکورد یا عملیات مرتبط
- وضعیت بررسی خطا
میتوانید این اطلاعات را از طریق Error Workflow به پایگاه داده یا یک سیستم مانیتورینگ ارسال کنید.
از ثبت اطلاعات حساس خودداری کنید
در زمان ثبت خطا، نباید تمام دادههای ورودی و خروجی را بدون بررسی ذخیره کنید.
ممکن است دادههای Workflow شامل اطلاعات شخصی، رمز عبور، توکن API یا اطلاعات مالی باشند. ذخیره این دادهها در یک جدول عمومی یا ارسال آنها به یک سرویس ثبت لاگ میتواند ریسک امنیتی ایجاد کند.
بهتر است فقط اطلاعات لازم برای عیبیابی را ثبت کنید و دسترسی به گزارشها را محدود نگه دارید.
۵. مدیریت خطاهای HTTP Request
یکی از موقعیتهای رایج بروز خطا در n8n، ارسال درخواست به APIهای خارجی است.
فرض کنید Workflow شما از HTTP Request برای دریافت اطلاعات یک سرویس استفاده میکند. درخواست ممکن است با خطاهایی مانند موارد زیر مواجه شود:
400 Bad Request: درخواست از نظر سرویس مقصد نامعتبر است.401 Unauthorized: احراز هویت با مشکل مواجه شده است.403 Forbidden: دسترسی به عملیات موردنظر مجاز نیست.404 Not Found: مسیر یا منبع موردنظر پیدا نشده است.429 Too Many Requests: محدودیت تعداد درخواستها اعمال شده است.500 Internal Server Error: سرور مقصد با خطای داخلی مواجه شده است.
معنای دقیق خطا و راهکار رفع آن به API مقصد بستگی دارد.
برای مدیریت این خطاها، ابتدا مشخص کنید آیا خطا ناشی از داده نامعتبر، مجوز ناکافی، محدودیت سرویس یا مشکل موقت شبکه است.
برای مثال، خطای 401 ممکن است نیازمند اصلاح Credential باشد؛ در حالی که خطای 429 ممکن است به محدود کردن نرخ درخواستها یا استفاده از سازوکار تلاش مجدد نیاز داشته باشد.
در تنظیمات HTTP Request نیز رفتار مربوط به خطا را بررسی کنید. در برخی شرایط، Node میتواند خطا را به شکل خروجی در اختیار مراحل بعدی قرار دهد؛ در شرایط دیگر، اجرا ممکن است متوقف شود یا به Error Workflow برسد. این رفتار به تنظیمات Node و نسخه n8n بستگی دارد.
نکته مهم: برای خطاهای مختلف یک راهکار یکسان در نظر نگیرید. تلاش مجدد برای یک خطای موقت ممکن است مفید باشد، اما برای خطای احراز هویت یا درخواست نامعتبر معمولاً باید علت اصلی برطرف شود.
۶. تفاوت Error Workflow با مسیرهای IF و Switch
ممکن است بپرسید آیا برای مدیریت خطا همیشه باید از Error Workflow استفاده کرد؟
خیر. انتخاب روش به نوع مسئله بستگی دارد.
استفاده از IF و Switch
وقتی دادهها با موفقیت دریافت شدهاند و میخواهید بر اساس مقدار آنها تصمیم بگیرید، معمولاً IF یا Switch مناسب است.
برای مثال:
- اگر موجودی بیشتر از صفر بود، سفارش را ادامه بده.
- اگر وضعیت سفارش لغو شده بود، پردازش را متوقف کن.
- اگر نوع درخواست مشخص بود، آن را به مسیر مربوطه بفرست.
این موارد بخشی از منطق عادی Workflow هستند و لزوماً خطای اجرایی محسوب نمیشوند.
استفاده از Stop And Error
وقتی شرطی برقرار شده که باید اجرای جاری بهعنوان یک خطا متوقف شود، Stop And Error میتواند مناسب باشد.
برای مثال، اگر شناسه سفارش الزامی است اما وجود ندارد، میتوانید خطای مشخصی ایجاد کنید تا عملیات ناقص ادامه پیدا نکند.
استفاده از Error Workflow
وقتی میخواهید در واکنش به شکست یک Workflow، فرایند جداگانهای برای ثبت خطا یا ارسال هشدار اجرا شود، Error Workflow انتخاب مناسبی است.
در پروژههای واقعی میتوانید از هر سه روش در کنار یکدیگر استفاده کنید: IF برای تصمیمگیری عادی، Stop And Error برای شرایط غیرمجاز و Error Workflow برای رسیدگی به شکست اجرا.
۷. اشتباهات رایج در مدیریت خطاهای n8n
اشتباه اول: نادیده گرفتن خطا با ادامه دادن اجرا
ادامه دادن اجرا بدون ثبت یا بررسی نتیجه شکست میتواند باعث ایجاد داده ناقص یا عملیات نادرست شود.
راهکار: مشخص کنید کدام خطاها قابل چشمپوشی هستند و برای خطاهای مهم، ثبت وضعیت یا اطلاعرسانی در نظر بگیرید.
اشتباه دوم: ارسال هشدار بدون اطلاعات کافی
اگر پیام هشدار فقط عبارت «Workflow ناموفق بود» را نشان دهد، بررسی مشکل دشوار خواهد بود.
راهکار: در صورت امکان، نام Workflow، اطلاعات اجرای ناموفق و پیام خطا را در هشدار قرار دهید؛ اما از افشای اطلاعات حساس خودداری کنید.
اشتباه سوم: فرض کردن اینکه همه خطاها موقتی هستند
همه خطاها با اجرای دوباره برطرف نمیشوند. اطلاعات نامعتبر، توکن منقضی و مجوز ناکافی ممکن است همچنان باعث شکست شوند.
راهکار: ابتدا علت خطا را شناسایی کنید و سپس درباره ادامه اجرا یا تلاش مجدد تصمیم بگیرید.
اشتباه چهارم: آزمایش نکردن مسیر خطا
ممکن است Workflow در حالت عادی بهدرستی کار کند، اما هنگام بروز خطا هیچ هشدار یا گزارش مناسبی تولید نکند.
راهکار: خطاهای کنترلشده ایجاد کنید و مطمئن شوید Error Workflow، ثبت گزارش و مسیرهای جایگزین مطابق انتظار عمل میکنند.
اشتباه پنجم: وابسته کردن مدیریت خطا به همان سرویس معیوب
اگر API اصلی از دسترس خارج شده باشد و ارسال هشدار نیز به همان API وابسته باشد، احتمال دارد اطلاعرسانی انجام نشود.
راهکار: برای خطاهای مهم، مسیر اطلاعرسانی را تا حد امکان مستقل از سرویس اصلی طراحی کنید.
جمعبندی
مدیریت خطا در n8n یکی از بخشهای مهم ساخت اتوماسیون قابلاعتماد است. با استفاده از Error Workflow و Error Trigger میتوانید رسیدگی به خطاهای Workflowهای مختلف را متمرکز کنید. Stop And Error امکان ایجاد خطاهای کنترلشده را فراهم میکند و تنظیمات On Error به شما اجازه میدهد رفتار Node را هنگام شکست مشخص کنید.
برای طراحی صحیح Error Handling، ابتدا انواع خطاهای احتمالی را شناسایی کنید، سپس مشخص کنید کدام خطا باید اجرای Workflow را متوقف کند، کدام خطا نیازمند ثبت یا اطلاعرسانی است و در چه شرایطی ادامه پردازش مجاز خواهد بود.
در مقاله بعدی، بهصورت اختصاصی سراغ Retry On Fail در n8n میرویم و بررسی میکنیم چگونه برای خطاهای موقت، تلاش مجدد را تنظیم کنیم و از تکرار ناخواسته عملیات جلوگیری کنیم.
سؤالات متداول
Error Workflow در n8n چیست؟
Error Workflow یک Workflow اختصاصی برای رسیدگی به خطاهای اجرای Workflowهای دیگر است. این Workflow معمولاً با Error Trigger آغاز میشود و میتواند اطلاعات خطا را ثبت کند یا برای مدیر سیستم هشدار بفرستد.
Error Trigger چه کاری انجام میدهد؟
Error Trigger برای آغاز اجرای Error Workflow در واکنش به خطاهای Workflowهای تنظیمشده استفاده میشود. برای استفاده از آن باید Error Workflow را در تنظیمات Workflow اصلی انتخاب کنید.
تفاوت Stop And Error با IF چیست؟
IF برای تصمیمگیری بر اساس شرط و هدایت داده به مسیرهای مختلف استفاده میشود. Stop And Error زمانی کاربرد دارد که بخواهید اجرای جاری را با یک خطای مشخص متوقف کنید.
آیا میتوان پس از خطای یک Node اجرای Workflow را ادامه داد؟
بله، در صورت پشتیبانی Node و تنظیمات نسخه مورد استفاده، میتوانید رفتار ادامه اجرا را انتخاب کنید. با این حال، باید بررسی کنید که ادامه پردازش پس از شکست چه اثری بر صحت دادهها و منطق کسبوکار دارد.
آیا Error Workflow مشکل اصلی را برطرف میکند؟
خیر. Error Workflow معمولاً برای رسیدگی به خطا، ثبت اطلاعات یا اطلاعرسانی استفاده میشود. برطرف کردن علت اصلی ممکن است به اصلاح دادهها، تنظیم Credential، رفع مشکل API یا تغییر منطق Workflow نیاز داشته باشد.
چگونه مدیریت خطا را در n8n آزمایش کنیم؟
یک Workflow آزمایشی بسازید که بهصورت کنترلشده در یک Node مشخص شکست بخورد. سپس بررسی کنید که خطا بهدرستی ثبت میشود، Error Workflow اجرا میشود و هشدارها یا مسیرهای جایگزین رفتار مورد انتظار را دارند. این آزمایش را در محیط تست انجام دهید تا به دادههای واقعی آسیب نرسد.





