آموزش Execute Workflow در n8n؛ اجرای Workflow تو در تو با مثال عملی

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

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

در n8n می‌توانید از قابلیت Execute Workflow برای اجرای یک Workflow از داخل Workflow دیگر استفاده کنید. Workflow فراخوانی‌شده معمولاً با نام Sub-workflow شناخته می‌شود.

در این مقاله یاد می‌گیرید Execute Workflow چیست، چگونه آن را تنظیم کنید، داده‌ها را بین Workflowها انتقال دهید و یک مثال عملی از ارسال اطلاعات مشتری به یک Workflow جداگانه بسازید.

Execute Workflow در n8n چیست؟

Execute Workflow قابلیتی است که به شما اجازه می‌دهد هنگام اجرای یک Workflow، Workflow دیگری را نیز فراخوانی کنید.

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

ساختار کلی به این شکل خواهد بود:

Workflow اصلی

      |

      v

Execute Workflow

      |

      v

Workflow فرعی

      |

      v

پردازش اطلاعات

      |

      v

بازگشت نتیجه به Workflow اصلی

Workflow اصلی مسئول مدیریت فرایند کلی است و Workflow فرعی یک وظیفه مشخص را انجام می‌دهد.

نکته مهم این است که Execute Workflow با Trigger زمان‌بندی‌شده تفاوت دارد. در این روش، اجرای Workflow فرعی به‌واسطه فراخوانی از Workflow دیگر آغاز می‌شود، نه صرفاً به دلیل رسیدن زمان مشخص.

چرا باید از Execute Workflow استفاده کنیم؟

استفاده از Workflowهای قابل استفاده مجدد چند مزیت مهم دارد.

۱. جلوگیری از تکرار کد و منطق

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

اما اگر این منطق را در یک Workflow جداگانه قرار دهید، تمام Workflowهای اصلی می‌توانند از همان پیاده‌سازی استفاده کنند.

۲. ساده‌تر شدن Workflowهای بزرگ

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

با تقسیم فرایند به بخش‌های مستقل، هر Workflow وظیفه مشخصی خواهد داشت.

۳. نگهداری و توسعه آسان‌تر

اگر نحوه ارسال پیام یا پردازش اطلاعات مشتری تغییر کند، می‌توانید Workflow مربوط به همان عملیات را اصلاح کنید، بدون اینکه مجبور باشید ساختار تمام Workflowهای اصلی را تغییر دهید.

۴. استفاده مجدد در پروژه‌های مختلف

می‌توانید Workflowهایی برای کارهای عمومی بسازید؛ مانند:

• اعتبارسنجی و استانداردسازی اطلاعات
• تبدیل فرمت داده‌ها
• ثبت گزارش اجرای عملیات
• آماده‌سازی اطلاعات برای ارسال به API
• ساخت پیام‌های اطلاع‌رسانی
• پردازش اطلاعات دریافتی از فرم‌ها

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

تفاوت Workflow اصلی و Sub-workflow چیست؟

Workflow اصلی فرایند کلی را مدیریت می‌کند. Sub-workflow بخشی از عملیات را بر عهده می‌گیرد و از Workflow اصلی فراخوانی می‌شود.

Sub-workflow الزاماً یک قابلیت مستقل با نوع خاصی از فایل نیست؛ منظور، Workflowای است که برای فراخوانی از Workflowهای دیگر طراحی شده است.

آموزش ساخت اولین Sub-workflow در n8n

برای یادگیری بهتر، یک مثال ساده می‌سازیم.

فرض کنید یک Workflow اصلی اطلاعات مشتری را دریافت می‌کند و سپس باید این اطلاعات را به یک Workflow دیگر ارسال کند تا نام مشتری را استانداردسازی کند.

در این مثال، از دو Workflow استفاده می‌کنیم:

1. Workflow اصلی: دریافت و ارسال اطلاعات مشتری
2. Workflow فرعی: پردازش اطلاعات مشتری و برگرداندن نتیجه

نام Nodeها و بعضی گزینه‌های رابط کاربری ممکن است با توجه به نسخه n8n کمی متفاوت باشند.

مرحله اول: ساخت Workflow فرعی

ابتدا یک Workflow جدید ایجاد کنید و نام آن را به شکل زیر قرار دهید:

Customer Data Processor

این Workflow وظیفه پردازش اطلاعات مشتری را بر عهده خواهد داشت.

در ابتدای Workflow، Trigger مربوط به اجرای Workflow توسط Workflow دیگر را اضافه کنید. این Trigger در نسخه‌های مختلف n8n ممکن است با عنوانی مانند When Executed by Another Workflow نمایش داده شود.

این Node نقطه شروع Workflow فرعی است و امکان دریافت داده از Workflow فراخوانی‌کننده را فراهم می‌کند.

در تنظیمات Trigger، ورودی مورد نیاز را تعریف کنید. اگر نسخه n8n شما امکان تعریف ورودی‌های مشخص را ارائه می‌دهد، می‌توانید فیلدهای زیر را تعریف کنید:

• name از نوع String
• email از نوع String

تعریف ورودی‌ها باعث می‌شود ساختار داده مورد انتظار Workflow فرعی روشن باشد. در برخی نسخه‌ها یا تنظیمات، نحوه تعیین ورودی‌ها ممکن است متفاوت باشد؛ بنابراین گزینه‌های موجود در نسخه نصب‌شده خود را بررسی کنید.

مرحله دوم: پردازش اطلاعات ورودی

بعد از Trigger، یک Node از نوع Edit Fields (Set) اضافه کنید.

هدف این Node ساخت خروجی استاندارد برای مشتری است.

برای مثال، فیلدهای زیر را در خروجی تنظیم کنید:

برای دریافت نام از داده ورودی می‌توانید از Expression زیر استفاده کنید:

{{ $json.name }}

و برای دریافت ایمیل:

{{ $json.email }}

اگر ورودی Trigger شما ساختار دیگری داشته باشد، باید مسیر Expressionها را با همان ساختار هماهنگ کنید.

در این مرحله، خروجی Workflow فرعی تقریباً چنین خواهد بود:

{

  "customer_name": "Ali Ahmadi",

  "customer_email": "ali@example.com",

  "status": "processed"

}

مقادیر بالا صرفاً نمونه هستند.

از آنجا که در این مثال از Edit Fields استفاده می‌کنیم، خروجی Node شامل فیلدهایی خواهد بود که در آن تنظیم کرده‌اید. اگر گزینه‌های حفظ فیلدهای ورودی در نسخه شما وجود دارد و می‌خواهید اطلاعات اولیه نیز حفظ شوند، تنظیمات مربوط به آن را بررسی کنید.

مرحله سوم: ذخیره Workflow فرعی

Workflow را ذخیره کنید.

برای اجرای آن از Workflow اصلی، لازم است Workflow فرعی در دسترس باشد و تنظیمات دسترسی یا اجازه اجرای آن با نحوه فراخوانی سازگار باشد.

در این مثال نیازی نیست Workflow فرعی را با Webhook یا Schedule Trigger اجرا کنید؛ قرار است Workflow اصلی آن را فراخوانی کند.

ساخت Workflow اصلی و اجرای Workflow فرعی

حالا یک Workflow جدید ایجاد کنید و نام آن را به شکل زیر قرار دهید:

Customer Registration

برای شروع تست، می‌توانید از Manual Trigger استفاده کنید.

مرحله چهارم: آماده‌سازی اطلاعات مشتری

بعد از Manual Trigger، یک Node از نوع Edit Fields اضافه کنید و اطلاعات نمونه مشتری را در آن قرار دهید.

برای مثال:

با اجرای این بخش، Workflow اصلی اطلاعاتی مشابه زیر تولید می‌کند:

{

  "name": "Ali Ahmadi",

  "email": "ali@example.com"

}

این داده قرار است به Workflow فرعی ارسال شود.

مرحله پنجم: اضافه کردن Execute Sub-workflow

پس از Node آماده‌سازی اطلاعات، Node مربوط به اجرای Workflow دیگر را اضافه کنید. این Node در رابط کاربری n8n ممکن است با عنوان Execute Sub-workflow یا عنوانی نزدیک به آن نمایش داده شود.

سپس تنظیمات زیر را بررسی کنید:

1. Workflow فرعی Customer Data Processor را انتخاب کنید.
2. تنظیمات ورودی را بررسی کنید تا داده‌های ورودی از Node قبلی به Workflow فرعی منتقل شوند.
3. اگر گزینه تعیین نحوه اجرای Workflow فرعی وجود دارد، آن را مطابق نیاز خود تنظیم کنید.
4. اگر می‌خواهید Workflow اصلی منتظر تکمیل Workflow فرعی بماند و خروجی آن را دریافت کند، حالت اجرای مناسب برای انتظار و دریافت نتیجه را انتخاب کنید.

در بسیاری از نسخه‌ها، اطلاعات ورودی Node قبلی به‌عنوان داده ورودی اجرای Workflow فرعی در دسترس قرار می‌گیرد؛ بااین‌حال، تنظیمات ورودی و گزینه‌های اجرای Node را در نسخه نصب‌شده خود بررسی کنید.

مرحله ششم: اجرای آزمایشی

Workflow اصلی را اجرا کنید.

در صورت صحیح بودن تنظیمات، اطلاعات مشتری به Workflow فرعی منتقل می‌شود و Nodeهای آن اجرا خواهند شد.

خروجی مورد انتظار این مثال می‌تواند به شکل زیر باشد:

{

  "customer_name": "Ali Ahmadi",

  "customer_email": "ali@example.com",

  "status": "processed"

}

این خروجی نتیجه پردازش داده در Workflow فرعی است. اگر اجرای Node به‌گونه‌ای تنظیم شده باشد که Workflow اصلی منتظر نتیجه بماند، خروجی برگشتی در ادامه Workflow اصلی قابل استفاده خواهد بود.

اگر بعد از Execute Workflow یک Node دیگر قرار دهید، می‌توانید خروجی برگشتی را با Expressionهایی مانند نمونه زیر بخوانید:

{{ $json.customer_name }}

وضعیت دقیق خروجی به ساختار داده و تنظیمات Nodeهای شما بستگی دارد.

انتقال داده بین Workflowها در n8n چگونه انجام می‌شود؟

یکی از نکات کلیدی هنگام کار با Execute Workflow، شناخت ساختار داده‌های ورودی و خروجی است.

در n8n، داده‌ها معمولاً به شکل Itemهایی منتقل می‌شوند که اطلاعات هر Item در بخش json قرار دارد.

برای مثال:

{

  "name": "Sara Mohammadi",

  "email": "sara@example.com"

}

در Workflow فرعی، بسته به ساختار ورودی، می‌توانید با Expression زیر به نام مشتری دسترسی پیدا کنید:

{{ $json.name }}

اگر Workflow فرعی اطلاعات را تغییر دهد و خروجی جدیدی تولید کند، Workflow اصلی می‌تواند نتیجه را در Nodeهای بعدی مصرف کند؛ به شرط اینکه تنظیمات اجرا امکان دریافت خروجی را فراهم کرده باشد.

آیا می‌توان چند مشتری را به Workflow فرعی ارسال کرد؟

بله. اگر Workflow اصلی چند Item تولید کند، می‌توانید آن‌ها را به Workflow فرعی ارسال کنید. رفتار دقیق پردازش به نحوه تنظیم ورودی و اجرای Sub-workflow وابسته است.

برای مثال، داده ورودی می‌تواند شامل چند مشتری باشد:

[

  {

    "name": "Ali Ahmadi",

    "email": "ali@example.com"

  },

  {

    "name": "Sara Mohammadi",

    "email": "sara@example.com"

  }

]

در طراحی چنین Workflowهایی باید مشخص کنید که قصد پردازش تک‌تک Itemها را دارید یا می‌خواهید داده‌ها را به‌صورت یک مجموعه پردازش کنید.

همچنین اگر تعداد Itemها زیاد باشد، تنظیمات مربوط به اجرای هر Item یا دسته‌بندی آن‌ها را بررسی کنید تا فشار غیرضروری به سرویس‌ها وارد نشود.

مثال کاربردی: ارسال اطلاعات مشتری به Workflow مستقل

فرض کنید یک فرم ثبت‌نام دارید و اطلاعات آن از طریق Webhook وارد n8n می‌شود.

می‌خواهید پس از دریافت اطلاعات:

1. اطلاعات اولیه بررسی شود.
2. داده‌های مشتری استانداردسازی شوند.
3. اطلاعات برای ثبت در سیستم مقصد آماده شوند.
4. نتیجه پردازش در Workflow اصلی مورد استفاده قرار بگیرد.

می‌توانید ساختار را به این شکل طراحی کنید:

Webhook

   |

   v

اعتبارسنجی اولیه

   |

   v

Execute Sub-workflow

   |

   +----> Workflow پردازش مشتری

   |             |

   |             v

   |       استانداردسازی داده

   |             |

   |             v

   |       خروجی پردازش

   |

   v

ادامه فرایند اصلی

در این ساختار، منطق پردازش مشتری در یک Workflow مستقل قرار می‌گیرد و Workflow اصلی فقط آن را فراخوانی می‌کند.

بعداً می‌توانید همین Workflow فرعی را از یک Workflow دیگر نیز اجرا کنید؛ برای مثال، فرایند ثبت سفارش یا واردکردن اطلاعات از فایل اکسل.

اگر اعتبارسنجی اولیه در چند پروژه مشترک است، می‌توانید آن را نیز در یک Workflow جداگانه قرار دهید؛ البته بهتر است فقط زمانی این کار را انجام دهید که جداسازی واقعاً به کاهش تکرار یا ساده‌تر شدن نگهداری کمک کند.

مدیریت خطا در Execute Workflow

هنگام اجرای Workflow فرعی ممکن است خطاهایی رخ دهند؛ برای مثال:

• Workflow فرعی در دسترس نباشد.
• ورودی‌های ارسالی با ساختار مورد انتظار هماهنگ نباشند.
• یکی از Nodeهای Workflow فرعی با خطا مواجه شود.
• درخواست API در داخل Workflow فرعی ناموفق باشد.
• اجرای Workflow فرعی به دلیل محدودیت زمانی یا تنظیمات زیرساخت با مشکل روبه‌رو شود.

برای مدیریت این شرایط، فقط به وجود Execute Workflow اکتفا نکنید؛ رفتار خطا را نیز طراحی کنید.

۱. بررسی ساختار ورودی

مطمئن شوید Workflow اصلی تمام فیلدهای مورد نیاز را ارسال می‌کند و Workflow فرعی همان فیلدها را دریافت می‌کند.

برای مثال، اگر Workflow فرعی به email نیاز دارد، نبودن این فیلد باید به شکل قابل پیش‌بینی مدیریت شود.

۲. استفاده از تنظیمات خطای Node

در تنظیمات Nodeهای n8n، بسته به نسخه و نوع Node، ممکن است گزینه‌هایی برای تعیین رفتار هنگام خطا وجود داشته باشد.

اگر می‌خواهید اجرای اصلی در صورت شکست Workflow فرعی متوقف شود، رفتار توقف و گزارش خطا را متناسب با نیاز خود انتخاب کنید.

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

۳. طراحی Error Workflow

برای سناریوهای پیچیده‌تر، می‌توانید از قابلیت‌های مدیریت خطای n8n استفاده کنید و یک Error Workflow برای ثبت و اطلاع‌رسانی خطاها بسازید.

برای آشنایی بیشتر با این موضوع، مقاله «آموزش Error Handling در n8n؛ مدیریت خطاها و جلوگیری از توقف Workflow» را مطالعه کنید.

۴. جلوگیری از اجرای تکراری عملیات

اگر Workflow فرعی عملیاتی مانند ثبت سفارش، ارسال پیام یا ثبت تراکنش انجام می‌دهد، باید به اجرای مجدد آن توجه کنید.

در بعضی شرایط، تلاش مجدد یا تکرار اجرای Workflow ممکن است یک عملیات را دوباره انجام دهد. برای عملیات حساس، از شناسه یکتا، بررسی وضعیت قبلی یا سازوکار Idempotency در سیستم مقصد استفاده کنید.

تفاوت Execute Workflow با Execute Command و HTTP Request

این سه قابلیت کاربرد یکسانی ندارند و انتخاب درست آن‌ها به نیاز پروژه بستگی دارد.

اگر می‌خواهید منطق یک فرایند را در چند Workflow داخلی استفاده کنید، Execute Workflow معمولاً انتخاب مناسبی است.

اگر قرار است با یک سرویس خارجی ارتباط برقرار کنید، HTTP Request گزینه متداول‌تری است.

Execute Command برای اجرای دستورات سیستم‌عامل کاربرد دارد و به دلایل امنیتی ممکن است در محیط شما غیرفعال یا محدود شده باشد. برای فراخوانی یک Workflow داخلی، معمولاً نیازی به استفاده از Execute Command نیست.

تفاوت Execute Workflow با Webhook

ممکن است این سؤال پیش بیاید که چرا به‌جای Execute Workflow از Webhook استفاده نکنیم.

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

اما Execute Workflow برای فراخوانی یک Workflow دیگر از داخل n8n طراحی شده است.

اگر سیستم دیگری خارج از n8n قرار است عملیات را آغاز کند، Webhook می‌تواند گزینه مناسبی باشد. اگر هدف شما فراخوانی یک Workflow داخلی است، Execute Workflow معمولاً ساختار ساده‌تری ایجاد می‌کند.

نکات مهم برای طراحی Sub-workflowهای حرفه‌ای

برای اینکه Workflowهای قابل استفاده مجدد در پروژه‌های واقعی قابل نگهداری باشند، نکات زیر را رعایت کنید.

نام‌گذاری مشخص

به‌جای نام‌هایی مانند Workflow 1 یا Test Workflow، نامی انتخاب کنید که وظیفه Workflow را مشخص کند؛ مانند:

• Customer Data Processor
• Order Validation
• Send Notification
• Prepare API Payload

تعریف قرارداد ورودی و خروجی

مشخص کنید Workflow فرعی چه فیلدهایی دریافت می‌کند و چه نتیجه‌ای برمی‌گرداند.

برای مثال:

ورودی:

{

  "customer_id": 125,

  "email": "customer@example.com"

}

خروجی:

{

  "success": true,

  "customer_id": 125,

  "message": "Customer processed"

}

این ساختار نمونه‌ای از یک قرارداد روشن برای ورودی و خروجی است؛ در پروژه واقعی باید با نیازهای خودتان هماهنگ شود.

جلوگیری از وابستگی غیرضروری

اگر Workflow فرعی برای اجرا به اطلاعات پنهان یا تنظیمات اختصاصی Workflow اصلی وابسته باشد، استفاده مجدد از آن دشوار می‌شود.

تا حد امکان، ورودی‌های لازم را صریح تعریف کنید و وابستگی‌های مربوط به Credentials و تنظیمات محیط اجرا را به‌صورت آگاهانه مدیریت کنید.

توجه به تعداد اجراها

اگر یک Workflow اصلی صدها Item تولید کند و برای هرکدام Workflow فرعی اجرا شود، تعداد اجراها و بار پردازشی می‌تواند افزایش پیدا کند.

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

مراقبت از فراخوانی‌های حلقه‌ای

از طراحی وضعیتی که Workflow A، Workflow B را فراخوانی کند و Workflow B دوباره به‌صورت ناخواسته Workflow A را اجرا کند، خودداری کنید.

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

مشکلات رایج Execute Workflow و روش رفع آن‌ها

Workflow فرعی اجرا نمی‌شود

ابتدا بررسی کنید Workflow مورد نظر در دسترس است، انتخاب آن در Node صحیح انجام شده و تنظیمات دسترسی یا اجرای آن مانع فراخوانی نیست.

سپس جزئیات اجرای Workflow اصلی و فرعی را بررسی کنید تا مشخص شود خطا در مرحله فراخوانی رخ داده یا داخل Workflow فرعی.

داده‌ها به Workflow فرعی منتقل نمی‌شوند

ساختار ورودی Node مربوط به اجرای Workflow را بررسی کنید. مطمئن شوید Node قبلی داده تولید می‌کند و فیلدهایی که Workflow فرعی انتظار دارد، در ورودی موجود هستند.

اگر نام فیلد یا ساختار JSON تغییر کرده باشد، ممکن است Expressionهای Workflow فرعی دیگر به مقدار مورد نظر دسترسی نداشته باشند.

Workflow اصلی خروجی مورد انتظار را دریافت نمی‌کند

بررسی کنید Workflow فرعی واقعاً خروجی تولید می‌کند و تنظیمات Execute Workflow برای انتظار و دریافت نتیجه مناسب است.

همچنین خروجی آخرین Node اجراشده در Workflow فرعی را بررسی کنید. اگر یک Node خروجی مورد انتظار را تولید نکند، ممکن است داده‌ای که به Workflow اصلی برمی‌گردد با چیزی که انتظار دارید متفاوت باشد.

Workflow چند بار اجرا می‌شود

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

برای عیب‌یابی، تعداد Itemهای ورودی و جزئیات Executionها را بررسی کنید. در صورت انجام عملیات حساس، سازوکار جلوگیری از اجرای تکراری را نیز در نظر بگیرید.

جمع‌بندی

قابلیت Execute Workflow در n8n به شما کمک می‌کند فرایندهای بزرگ را به Workflowهای کوچک‌تر و قابل استفاده مجدد تقسیم کنید. با این روش می‌توانید منطق مشترک را فقط یک بار پیاده‌سازی کنید، ساختار Workflowهای اصلی را ساده‌تر نگه دارید و توسعه اتوماسیون‌های پیچیده را آسان‌تر کنید.

برای استفاده صحیح از این قابلیت، باید نحوه انتقال داده‌ها، ساختار ورودی و خروجی، مدیریت خطاها و تعداد اجراها را در نظر بگیرید. همچنین بهتر است هر Sub-workflow وظیفه مشخصی داشته باشد و وابستگی‌های آن به سایر Workflowها تا حد امکان روشن باشند.

اگر در حال ساخت اتوماسیون‌های حرفه‌ای با n8n هستید، یادگیری Execute Workflow یکی از قدم‌های مهم برای طراحی ساختارهای ماژولار و قابل نگهداری است.

سوالات متداول

Execute Workflow در n8n چه کاری انجام می‌دهد؟

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

آیا Sub-workflow باید به‌صورت مستقل فعال باشد؟

برای فراخوانی از طریق Execute Workflow، لازم است Workflow فرعی در دسترس باشد و تنظیمات اجرای آن با این روش سازگار باشد. برخلاف Workflowهایی که با Webhook یا Schedule Trigger به‌صورت مستقل شروع می‌شوند، Sub-workflow معمولاً در پاسخ به فراخوانی Workflow دیگر اجرا می‌شود.

آیا می‌توان خروجی Sub-workflow را در Workflow اصلی استفاده کرد؟

بله. در صورتی که Workflow فرعی خروجی تولید کند و تنظیمات اجرای Node امکان دریافت نتیجه را فراهم کند، می‌توانید خروجی را در Nodeهای بعدی Workflow اصلی استفاده کنید.

آیا Execute Workflow جایگزین HTTP Request است؟

خیر. Execute Workflow برای فراخوانی Workflowهای دیگر در n8n کاربرد دارد؛ HTTP Request برای ارسال درخواست HTTP به APIها و سرویس‌های وب استفاده می‌شود.

آیا می‌توان یک Sub-workflow را از چند Workflow مختلف فراخوانی کرد؟

بله. یکی از کاربردهای اصلی این قابلیت، استفاده مجدد از یک Workflow فرعی در چند Workflow اصلی است. برای این کار بهتر است ورودی‌ها و خروجی‌های آن مشخص و مستقل از جزئیات غیرضروری Workflowهای فراخوانی‌کننده طراحی شوند.

آیا استفاده از Execute Workflow باعث سریع‌تر شدن اجرای اتوماسیون می‌شود؟

نه لزوماً. هدف اصلی این قابلیت، سازمان‌دهی بهتر، استفاده مجدد از منطق و ساده‌تر شدن نگهداری است. سرعت اجرا به تعداد فراخوانی‌ها، حجم داده‌ها، عملیات داخل Workflowها، منابع سرور و تنظیمات اجرا بستگی دارد.