با افزایش تعداد اتوماسیون‌ها در n8n، ممکن است با مشکلی روبه‌رو شوید: چند Workflow مختلف دارید که بخش‌هایی از آن‌ها کار مشابهی انجام می‌دهند. برای مثال، در چند فرایند باید اطلاعات مشتری را بررسی کنید، داده‌ها را استانداردسازی کنید یا یک پیام اطلاع‌رسانی بسازید.
اگر منطق این عملیات را در تمام Workflowها تکرار کنید، نگهداری و توسعه پروژه دشوارتر می‌شود. با تغییر یک قانون، ممکن است مجبور شوید چند Workflow مختلف را اصلاح کنید.
یکی از راهکارهای مناسب برای حل این مشکل، استفاده از Sub-workflow در n8n است. در این روش، یک وظیفه مشخص را در Workflow جداگانه‌ای پیاده‌سازی می‌کنید و از Workflowهای دیگر برای اجرای آن کمک می‌گیرید.
در این مقاله یاد می‌گیرید Sub-workflow چیست، چه تفاوتی با Workflow اصلی دارد، چگونه آن را طراحی کنید و چطور در یک مثال عملی از آن برای پردازش اطلاعات مشتری استفاده کنید.
Sub-workflow در n8n چیست؟
Sub-workflow به Workflowای گفته می‌شود که برای انجام یک وظیفه مشخص طراحی شده و می‌تواند از طریق یک Workflow دیگر فراخوانی شود.
برای مثال، فرض کنید یک سیستم فروش دارید که از چند مسیر مختلف سفارش دریافت می‌کند:
- ثبت سفارش از طریق سایت
- دریافت سفارش از طریق فرم
- دریافت سفارش از یک API
- وارد کردن سفارش از فایل اکسل
هرکدام از این مسیرها ممکن است به پردازش اطلاعات سفارش نیاز داشته باشند. به‌جای اینکه منطق پردازش را در تمام Workflowها تکرار کنید، می‌توانید یک Sub-workflow بسازید که وظیفه استانداردسازی و آماده‌سازی اطلاعات سفارش را بر عهده بگیرد.
ساختار کلی به این صورت خواهد بود:
Workflow ثبت سفارش سایت
|
v
Sub-workflow
^
|
Workflow دریافت سفارش API
هر دو Workflow اصلی می‌توانند از منطق مشترک استفاده کنند، بدون اینکه مجبور باشند تمام مراحل پردازش را جداگانه پیاده‌سازی کنند.
نکته مهم این است که Sub-workflow معمولاً به‌عنوان یک مفهوم طراحی استفاده می‌شود؛ یعنی Workflow فرعی همان Workflow مستقلی است که برای فراخوانی از سایر Workflowها آماده کرده‌اید.
تفاوت Workflow اصلی و Sub-workflow
برای درک بهتر این مفهوم، باید وظیفه هرکدام را مشخص کنیم.
Workflow اصلی فرایند کلی را مدیریت می‌کند. ممکن است با Webhook شروع شود، اطلاعاتی از یک API دریافت کند یا طبق برنامه زمانی اجرا شود.
Sub-workflow وظیفه مشخصی را انجام می‌دهد؛ مانند اعتبارسنجی داده، تبدیل ساختار اطلاعات یا آماده‌سازی درخواست API.
| ویژگی | Workflow اصلی | Sub-workflow |
|---|---|---|
| وظیفه اصلی | مدیریت فرایند کلی | انجام یک بخش مشخص از فرایند |
| نحوه شروع | Trigger متناسب با فرایند | معمولاً Trigger مخصوص فراخوانی از Workflow دیگر |
| ورودی | داده‌های Trigger یا Nodeهای قبلی | داده‌های ارسالی از Workflow فراخوانی‌کننده |
| خروجی | نتیجه فرایند اصلی | نتیجه پردازش بخش فرعی |
| استفاده مجدد | وابسته به طراحی | مناسب برای استفاده در چند Workflow |
این تقسیم‌بندی به معنای آن نیست که Sub-workflow هیچ‌وقت به‌صورت مستقل آزمایش نمی‌شود. در زمان توسعه و عیب‌یابی، می‌توانید آن را مطابق قابلیت‌های نسخه n8n خود آزمایش کنید.
تفاوت Execute Workflow و Sub-workflow چیست؟
این دو اصطلاح به هم مرتبط هستند، اما یکسان نیستند.
- Sub-workflow: به Workflow فرعی و نقش آن در ساختار اتوماسیون اشاره می‌کند.
- Execute Workflow: به قابلیت یا Node مورد استفاده برای فراخوانی و اجرای Workflow دیگر اشاره دارد.
برای مثال، شما یک Workflow به نام Customer Processor می‌سازید. این Workflow نقش Sub-workflow را دارد. سپس در Workflow اصلی از Node مربوط به اجرای Workflow دیگر استفاده می‌کنید تا آن را فراخوانی کنید.
بنابراین، Sub-workflow چیزی است که طراحی می‌کنید و Execute Workflow روشی است که برای اجرای آن از Workflow دیگر به کار می‌برید.
برای آموزش کامل نحوه تنظیم Node فراخوانی و اجرای آن، می‌توانید مقاله «آموزش Execute Workflow در n8n؛ اجرای Workflow تو در تو با مثال عملی» را نیز مطالعه کنید.
چه زمانی باید از Sub-workflow استفاده کنیم؟
استفاده از Sub-workflow همیشه ضروری نیست. برای یک اتوماسیون کوچک با چند Node ساده، ممکن است نگه داشتن تمام مراحل در یک Workflow انتخاب مناسب‌تری باشد.
اما در شرایط زیر، ساخت Workflow فرعی می‌تواند مفید باشد.
۱. زمانی که منطق یکسان در چند Workflow تکرار می‌شود
فرض کنید در چند فرایند باید شماره تلفن مشتری را پاک‌سازی کنید، فاصله‌های اضافی را حذف کنید و قالب خروجی را استاندارد کنید.
می‌توانید این منطق را در یک Sub-workflow قرار دهید و در تمام فرایندهای مورد نیاز آن را فراخوانی کنید.
۲. زمانی که Workflow بیش از حد بزرگ شده است
اگر یک Workflow شامل ده‌ها مرحله برای دریافت اطلاعات، اعتبارسنجی، پردازش، ارسال پیام و ثبت گزارش باشد، پیدا کردن خطاها و توسعه آن می‌تواند دشوار شود.
با جدا کردن بخش‌های مستقل، ساختار پروژه خواناتر می‌شود.
۳. زمانی که چند نفر روی یک پروژه کار می‌کنند
وقتی وظایف هر Workflow مشخص باشد، تقسیم مسئولیت بین اعضای تیم آسان‌تر می‌شود. یک نفر می‌تواند روی پردازش سفارش و فرد دیگری روی ارسال اعلان کار کند.
۴. زمانی که می‌خواهید یک بخش را جداگانه آزمایش کنید
اگر پردازش اطلاعات مشتری در یک Sub-workflow قرار داشته باشد، می‌توانید آن را با داده‌های نمونه آزمایش کنید، بدون اینکه لازم باشد هر بار تمام مراحل دریافت سفارش را اجرا کنید.
آموزش ساخت Sub-workflow در n8n با مثال عملی
در این مثال، یک سیستم ساده برای پردازش اطلاعات مشتری می‌سازیم.
Workflow اصلی اطلاعات مشتری را آماده می‌کند و به Workflow فرعی می‌فرستد. Workflow فرعی نام و ایمیل را دریافت می‌کند و یک خروجی استاندارد برمی‌گرداند.
دو Workflow خواهیم داشت:
Customer Registration: دریافت اطلاعات مشتریCustomer Processor: پردازش اطلاعات مشتری
نام برخی Nodeها یا گزینه‌های تنظیماتی ممکن است بر اساس نسخه n8n متفاوت باشد.
مرحله اول: ساخت Workflow فرعی
ابتدا یک Workflow جدید ایجاد کنید و نام آن را Customer Processor قرار دهید.
در ابتدای این Workflow، Trigger مخصوص اجرای Workflow توسط Workflow دیگر را اضافه کنید. این Trigger در رابط کاربری n8n معمولاً با عنوانی مانند When Executed by Another Workflow شناخته می‌شود.
این Node نقطه شروع Workflow فرعی است و اطلاعاتی را دریافت می‌کند که Workflow اصلی برای آن ارسال می‌کند.
در صورت پشتیبانی نسخه شما از تعریف ورودی‌های مشخص، فیلدهای زیر را به‌عنوان ورودی در نظر بگیرید:
| فیلد | نوع داده | توضیح |
|---|---|---|
name | String | نام مشتری |
email | String | ایمیل مشتری |
تعریف ورودی‌ها باعث می‌شود مشخص باشد Workflow فرعی برای اجرا به چه اطلاعاتی نیاز دارد.
اگر در نسخه شما نحوه تعریف ورودی‌ها متفاوت است، از گزینه‌های موجود در تنظیمات همان Trigger استفاده کنید.
مرحله دوم: اضافه کردن Edit Fields
پس از Trigger، یک Node از نوع Edit Fields (Set) اضافه کنید.
این Node برای انتخاب، تغییر نام و آماده‌سازی فیلدهای خروجی استفاده می‌شود.
فیلدهای زیر را تعریف کنید:
| نام فیلد خروجی | مقدار |
|---|---|
customer_name | {{ $json.name }} |
customer_email | {{ $json.email }} |
processing_status | processed |
برای مقدار customer_name، حالت Expression را فعال کنید و عبارت زیر را وارد کنید:
{{ $json.name }}
برای ایمیل نیز از این عبارت استفاده کنید:
{{ $json.email }}
در این مثال، name و email از داده ورودی خوانده می‌شوند و با نام‌های جدید در خروجی قرار می‌گیرند.
اگر گزینه نگه‌داشتن فیلدهای ورودی در تنظیمات Edit Fields فعال یا قابل انتخاب باشد، آن را بر اساس نیاز خود تنظیم کنید. در این مثال، هدف تولید خروجی استاندارد و مشخص است.
مرحله سوم: بررسی خروجی Workflow فرعی
خروجی مورد انتظار می‌تواند شبیه نمونه زیر باشد:
{
"customer_name": "Ali Ahmadi",
"customer_email": "ali@example.com",
"processing_status": "processed"
}
این مقادیر نمونه هستند و باید با اطلاعات ورودی واقعی جایگزین شوند.
در این مرحله، Workflow فرعی وظیفه مشخصی دارد: دریافت اطلاعات مشتری و تولید خروجی استاندارد.
Workflow را ذخیره کنید.
مرحله چهارم: ساخت Workflow اصلی
یک Workflow جدید ایجاد کنید و نام آن را Customer Registration قرار دهید.
برای آزمایش اولیه، از Manual Trigger استفاده کنید تا بتوانید Workflow را به‌صورت دستی اجرا کنید.
بعد از Manual Trigger، یک Node از نوع Edit Fields اضافه کنید و اطلاعات نمونه زیر را بسازید:
| فیلد | مقدار |
|---|---|
name | Ali Ahmadi |
email | ali@example.com |
خروجی این Node باید شامل دو فیلد name و email باشد.
مرحله پنجم: فراخوانی Sub-workflow
پس از Edit Fields، Node مربوط به اجرای Workflow دیگر را اضافه کنید. این Node در رابط کاربری n8n ممکن است با عنوان Execute Sub-workflow یا عنوانی مشابه نمایش داده شود.
سپس تنظیمات را انجام دهید:
- Workflow فرعی
Customer Processorرا انتخاب کنید. - تنظیمات ورودی را بررسی کنید تا اطلاعات Node قبلی به Workflow فرعی منتقل شود.
- در صورت وجود گزینه‌های مربوط به انتظار برای پایان اجرا، آن را مطابق نیاز خود تنظیم کنید.
- تنظیمات مربوط به دریافت خروجی را بررسی کنید تا نتیجه پردازش در Workflow اصلی قابل استفاده باشد.
در این مثال، Workflow اصلی باید اطلاعات name و email را به Workflow فرعی ارسال کند.
اگر نسخه n8n شما گزینه‌هایی برای تعیین شیوه انتخاب Workflow یا نحوه اجرای آن ارائه می‌دهد، گزینه‌ای را انتخاب کنید که با ساختار پروژه شما سازگار باشد.
مرحله ششم: اجرای آزمایشی
Workflow اصلی را اجرا کنید.
اگر تنظیمات صحیح باشند، اطلاعات مشتری به Workflow فرعی منتقل می‌شود و خروجی پردازش‌شده تولید خواهد شد.
پس از اجرای موفق، خروجی مورد انتظار مشابه نمونه زیر است:
{
"customer_name": "Ali Ahmadi",
"customer_email": "ali@example.com",
"processing_status": "processed"
}
برای اطمینان، اطلاعات ورودی و خروجی هر دو Workflow را بررسی کنید. اگر فیلدی در خروجی وجود ندارد، بررسی کنید آیا در ورودی Workflow فرعی وجود داشته و آیا Node پردازش آن را درست تنظیم کرده‌اید.
استفاده از یک Sub-workflow در چند Workflow
یکی از مزایای اصلی Sub-workflow این است که می‌توانید آن را از چند Workflow اصلی فراخوانی کنید.
فرض کنید Customer Processor آماده است. اکنون سه Workflow دارید:
- ثبت مشتری از طریق فرم سایت
- وارد کردن مشتری از فایل اکسل
- دریافت اطلاعات مشتری از یک API
هر سه Workflow می‌توانند اطلاعات را با ساختار مشخصی به Customer Processor ارسال کنند.
فرم سایت ---------+
|
فایل اکسل --------+----> Customer Processor
|
API --------------+
با این ساختار، منطق استانداردسازی اطلاعات در یک مکان نگهداری می‌شود.
اگر در آینده بخواهید نحوه استانداردسازی ایمیل یا نام مشتری را تغییر دهید، می‌توانید Workflow فرعی را اصلاح کنید؛ در نتیجه لازم نیست همان منطق را در تمام Workflowهای اصلی تغییر دهید.
البته تغییر ساختار ورودی یا خروجی Sub-workflow ممکن است بر Workflowهای استفاده‌کننده اثر بگذارد. بنابراین، هنگام تغییر فیلدها باید سازگاری با تمام فراخوانی‌کنندگان را بررسی کنید.
طراحی قرارداد ورودی و خروجی
برای ساخت Sub-workflow قابل استفاده مجدد، باید مشخص باشد چه داده‌ای دریافت می‌کند و چه نتیجه‌ای برمی‌گرداند.
به این تعریف می‌توان قرارداد ورودی و خروجی گفت.
برای مثال، قرارداد Customer Processor می‌تواند چنین باشد:
ورودی:
{
"name": "Sara Mohammadi",
"email": "sara@example.com"
}
خروجی:
{
"customer_name": "Sara Mohammadi",
"customer_email": "sara@example.com",
"processing_status": "processed"
}
با وجود این قرارداد، Workflow اصلی می‌داند چه اطلاعاتی را باید ارسال کند و پس از پایان پردازش چه فیلدهایی را می‌تواند مصرف کند.
اگر فیلدهای ورودی وجود نداشته باشند چه می‌شود؟
فرض کنید Workflow فرعی انتظار دارد فیلد email وجود داشته باشد، اما Workflow اصلی آن را ارسال نمی‌کند.
در این شرایط ممکن است خروجی ناقص تولید شود یا یکی از مراحل پردازش با مشکل مواجه شود.
برای جلوگیری از این مسئله:
- ورودی‌های مورد نیاز را مشخص کنید.
- وجود فیلدهای ضروری را بررسی کنید.
- برای داده‌های نامعتبر رفتار مشخصی در نظر بگیرید.
- در صورت نیاز، خطا را ثبت کنید یا نتیجه ناموفق برگردانید.
همچنین می‌توانید پیش از فراخوانی Sub-workflow در Workflow اصلی، اعتبارسنجی اولیه انجام دهید.
مدیریت خطا در Sub-workflow
جدا کردن منطق در Workflow فرعی به این معنا نیست که خطاها به‌صورت خودکار حل می‌شوند. باید مشخص کنید اگر یکی از مراحل Sub-workflow شکست خورد، Workflow اصلی چه رفتاری داشته باشد.
برای مثال، اگر Sub-workflow مسئول آماده‌سازی اطلاعات برای یک API باشد و درخواست API با خطا مواجه شود، باید تصمیم بگیرید که:
- اجرای Workflow اصلی متوقف شود؛
- خطا ثبت شود و مسیر جایگزین اجرا شود؛
- یا در شرایط مناسب، عملیات مجدداً تلاش شود.
انتخاب رفتار به اهمیت عملیات بستگی دارد. برای مثال، شکست در ساخت یک گزارش غیرضروری ممکن است با شکست در ثبت سفارش یا تراکنش مالی یکسان نباشد.
برای طراحی مدیریت خطا، می‌توانید از تنظیمات خطای Nodeها و قابلیت‌های مدیریت خطای n8n استفاده کنید.
همچنین اگر Workflow فرعی عملیاتی انجام می‌دهد که تکرار آن مشکل‌ساز است، مانند ارسال پیام یا ثبت سفارش، باید احتمال اجرای مجدد را در نظر بگیرید. استفاده از شناسه یکتا یا سازوکار جلوگیری از ثبت تکراری در سیستم مقصد می‌تواند مفید باشد.
برای آشنایی بیشتر با این موضوع، مقاله «آموزش Error Handling در n8n؛ مدیریت خطاها و جلوگیری از توقف Workflow» را مطالعه کنید.
نکات مهم برای ساخت Sub-workflowهای حرفه‌ای
۱. هر Sub-workflow یک وظیفه مشخص داشته باشد
بهتر است هر Workflow فرعی مسئولیت مشخصی داشته باشد؛ برای مثال، پردازش اطلاعات مشتری یا آماده‌سازی داده برای API.
اگر یک Sub-workflow هم‌زمان چندین وظیفه نامرتبط انجام دهد، استفاده مجدد و نگهداری آن دشوار می‌شود.
۲. نام‌گذاری واضح انتخاب کنید
نام‌هایی مانند Workflow 1 یا Test در پروژه‌های بزرگ کمک زیادی نمی‌کنند.
به‌جای آن‌ها، از نام‌های توصیفی استفاده کنید:
Customer ProcessorOrder ValidatorPrepare API RequestNotification Builder
۳. وابستگی‌ها را مشخص کنید
اگر Workflow فرعی به Credentials، متغیرهای محیطی یا تنظیمات خاصی نیاز دارد، این وابستگی‌ها را مشخص کنید.
در غیر این صورت، ممکن است Workflow در یک محیط به‌درستی اجرا شود، اما پس از انتقال به محیط دیگر به دلیل نبود Credentials یا تنظیمات لازم شکست بخورد.
۴. از تغییر ناگهانی قرارداد ورودی و خروجی خودداری کنید
اگر چند Workflow از یک Sub-workflow استفاده می‌کنند، تغییر نام فیلدهای خروجی ممکن است همه آن‌ها را تحت تأثیر قرار دهد.
قبل از اعمال تغییرات، محل‌های استفاده از Sub-workflow را بررسی و سپس Workflowهای وابسته را آزمایش کنید.
۵. تعداد فراخوانی‌ها را کنترل کنید
اگر Workflow اصلی تعداد زیادی Item تولید کند، ممکن است تعداد اجرای Workflow فرعی نیز افزایش پیدا کند.
برای مثال، اگر قرار باشد اطلاعات هزار مشتری پردازش شود، باید رفتار اجرای Sub-workflow، تعداد فراخوانی‌ها و محدودیت منابع را بررسی کنید.
۶. از فراخوانی حلقه‌ای جلوگیری کنید
ساختاری که در آن Workflow A، Workflow B را فراخوانی کند و Workflow B دوباره Workflow A را اجرا کند، ممکن است به اجرای تکراری یا مصرف غیرضروری منابع منجر شود.
مسیر فراخوانی Workflowها را روشن نگه دارید و از ایجاد چرخه‌های ناخواسته جلوگیری کنید.
مشکلات رایج Sub-workflow در n8n
Sub-workflow اجرا نمی‌شود
ابتدا بررسی کنید Workflow فرعی در دسترس است و Node فراخوانی به Workflow صحیح اشاره می‌کند.
سپس جزئیات Execution را بررسی کنید تا مشخص شود مشکل هنگام فراخوانی رخ داده یا داخل یکی از Nodeهای Workflow فرعی.
داده ورودی به Sub-workflow نمی‌رسد
خروجی Node قبل از فراخوانی را بررسی کنید. مطمئن شوید فیلدهای مورد انتظار وجود دارند و تنظیمات ورودی Workflow فرعی با ساختار داده سازگار است.
اگر از Expression استفاده می‌کنید، مسیرهایی مانند {{ $json.name }} را با داده واقعی مقایسه کنید.
خروجی Sub-workflow با انتظار شما متفاوت است
خروجی Nodeهای داخل Workflow فرعی را بررسی کنید. ممکن است یکی از Nodeها فیلدهای ورودی را حذف کرده باشد یا آخرین مرحله، خروجی مورد انتظار را تولید نکند.
همچنین بررسی کنید Workflow اصلی برای دریافت نتیجه تنظیم شده باشد.
پس از تغییر Sub-workflow، Workflowهای دیگر خراب می‌شوند
اگر نام یا ساختار فیلدهای خروجی را تغییر داده باشید، Workflowهای وابسته ممکن است دیگر نتوانند اطلاعات مورد نیاز خود را دریافت کنند.
در چنین شرایطی، قرارداد ورودی و خروجی را بررسی کنید و تمام Workflowهایی را که از Sub-workflow استفاده می‌کنند، مجدداً آزمایش کنید.
جمع‌بندی
Sub-workflow در n8n روشی برای تقسیم اتوماسیون‌های بزرگ به بخش‌های کوچک‌تر و قابل استفاده مجدد است. به‌جای تکرار یک منطق در چند Workflow، می‌توانید آن را در یک Workflow فرعی پیاده‌سازی کنید و از بخش‌های مختلف سیستم فراخوانی کنید.
برای طراحی اصولی Sub-workflow، وظیفه آن را مشخص کنید، ورودی و خروجی روشنی تعریف کنید، وابستگی‌ها را مدیریت کنید و رفتار خطاها را در نظر بگیرید.
اگر تعداد اتوماسیون‌های شما افزایش پیدا کرده یا بخش‌هایی از آن‌ها منطق مشترکی دارند، استفاده درست از Sub-workflow می‌تواند نگهداری و توسعه پروژه‌های n8n را ساده‌تر کند.
سوالات متداول
Sub-workflow در n8n چیست؟
Sub-workflow یک Workflow است که برای انجام وظیفه مشخصی طراحی شده و می‌تواند از Workflowهای دیگر فراخوانی شود. از آن برای کاهش تکرار و جداسازی منطق استفاده می‌شود.
تفاوت Sub-workflow با Execute Workflow چیست؟
Sub-workflow به خود Workflow فرعی اشاره دارد؛ Execute Workflow نام قابلیت یا Node مورد استفاده برای فراخوانی Workflow دیگر است.
آیا می‌توان یک Sub-workflow را در چند Workflow استفاده کرد؟
بله. می‌توانید یک Workflow فرعی را طوری طراحی کنید که چند Workflow اصلی با ارسال ورودی‌های سازگار از آن استفاده کنند.
آیا Sub-workflow باید ورودی و خروجی مشخص داشته باشد؟
برای استفاده مجدد و نگهداری آسان، بهتر است ورودی‌ها و خروجی‌های آن روشن و مستند باشند. این کار از ناسازگاری داده‌ها و خطاهای ناشی از تغییر ساختار جلوگیری می‌کند.
آیا استفاده از Sub-workflow سرعت n8n را افزایش می‌دهد؟
نه لزوماً. هدف اصلی Sub-workflow بهبود ساختار، کاهش تکرار و ساده‌تر شدن نگهداری است. سرعت اجرا به نوع عملیات، حجم داده‌ها، تعداد فراخوانی‌ها و منابع سرور بستگی دارد.
چه زمانی نباید از Sub-workflow استفاده کنیم؟
اگر Workflow بسیار کوچک است و منطق مشترکی برای استفاده مجدد وجود ندارد، جداسازی آن ممکن است پیچیدگی غیرضروری ایجاد کند. بهتر است زمانی از Sub-workflow استفاده کنید که جداسازی واقعاً به خوانایی، استفاده مجدد یا نگهداری بهتر کمک کند.
