اتوماسیون فرایند: API، workflow یا RPA؟

«می‌خواهیم این فرایند خودکار شود»؛ ولی کدام نوع خودکارسازی؟ سه خانوادهٔ اصلی وجود دارد: اتصال مستقیم با API، ابزار گردش‌کار (workflow) که چند API را به‌هم می‌دوزد، و RPA یا اتوماسیون رابط کاربری که مثل یک انسان روی صفحه کار می‌کند. انتخاب غلط، بعد از چند ماه به «ربات‌های شکننده» یا «کد سفارشی بی‌صاحب» تبدیل می‌شود. این مقاله انتخاب را بر پایهٔ استثناها انجام می‌دهد، نه بر پایهٔ مسیر خوشحال.

مرز منابع: ترتیب ترجیح و جدول مقایسه را از راهنمای رسمی Microsoft برای Power Automate خوانده‌ایم و رفتار گردش‌کار خطا را از مستندات n8n. هر دو فروشندهٔ ابزارند؛ فقط ساختار روش را نقل می‌کنیم و ادعای کارایی یا هزینه نداریم. معیارهای تصمیم و مثال‌ها توصیهٔ نویسنده‌اند. قوانین مرتبط با اتوماسیون و داده در ایران بررسی نشده است. برای مفهوم عمومی اتصال نرم‌افزارها API چیست و REST API چیست را بخوانید.

ترتیب ترجیح

راهنمای Microsoft ترتیب روشنی دارد: ابتدا ببینید آیا برای سیستم هدف کانکتور آماده هست؛ اگر نه، کانکتور سفارشی که از طریق API منتشرشده کار می‌کند «روش ترجیحی» است و API باید در برابر تغییر سیستم مقاوم باشد؛ بعد کانکتور HTTP برای سناریوهای یک‌باره؛ و آخر اتوماسیون مرورگر یا دسکتاپ که حرکات صفحه‌کلید و ماوس را تقلید می‌کند. جدول مقایسهٔ همان راهنما می‌گوید اتوماسیون مرورگر و دسکتاپ «به‌راحتی تحت‌تأثیر تغییر سیستم» قرار می‌گیرند و کانکتورها و HTTP این‌طور نیستند. ما همین ترتیب را می‌پذیریم و آن را با پرسش‌های استثنا کامل می‌کنیم.

ستون‌های «بالا/پایین» جمع‌بندی ما از جدول Microsoft است؛ مقدار دقیق به سامانهٔ شما بستگی دارد.

پرسش‌های استثنا: انتخاب واقعی

بسیاری از پروژه‌های اتوماسیون روی «مسیر خوشحال» تصمیم می‌گیرند. تصمیم را با این پرسش‌ها بگیرید (توصیهٔ نویسنده):

1. این فرایند چند استثنا دارد؟ اگر هر روز چند مورد استثنا دارد که انسان باید قضاوت کند، یک مسیر «ارجاع به انسان» لازم است.
2. اگر مرحله‌ای شکست بخورد، چه باید شود؟ دوباره امتحان، هشدار، ثبت در صف دستی؟
3. اگر دو بار اجرا شود چه می‌شود؟ (تکرار سفارش، دوبار ارسال پیامک)؛ طراحی ایدمپوتنت نیاز است.
4. داده کجا نگه‌داری می‌شود و چه کسی آن را می‌بیند؟ (کلیدها، توکن‌ها، اطلاعات شخصی.)
5. اگر سیستم هدف تغییر کند، چه کسی می‌فهمد؟ RPA معمولاً بی‌صدا می‌شکند.

چه زمانی API مستقیم؟

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

چه زمانی ابزار گردش‌کار؟

برای اتصال‌های متوسط بین چند سیستم: «وقتی فرم پر شد، سرنخ را در CRM بساز، به تیم پیام بده». مزیت: سرعت ساخت و دیده‌شدن جریان. n8n مثال خوبی از رفتار مورد انتظار است: برای هر گردش‌کار می‌توان گردش‌کار خطا گذاشت که با Error Trigger شروع می‌شود و هنگام شکست اجرا می‌شود (مثلاً هشدار ایمیلی)، و گره Stop and Error شکست را عمداً ایجاد می‌کند تا مسیر خطا اجرا شود. معنایش: خطا یک مسیر طراحی‌شده است. هر گردش‌کار تولیدی شما هم باید مسیر خطا و مالک داشته باشد، و جریان‌های حساس (مالی) باید جدا از جریان‌های ساده‌اند.

چه زمانی RPA؟

فقط وقتی سیستم هدف کانکتور یا API ندارد، فرایند ثابت است و تغییر قریب‌الوقوع نیست؛ و باید آن را «پل موقت» تلقی کنید. برای ربات رابط کاربری:

• مالک مشخص و هشدار بر شکست.
• مستندسازی انتخاب‌گرها (selector) و داده‌های نمونه برای تست.
• برنامهٔ جایگزینی با API هر زمان که سیستم آن را عرضه کرد.
• حساب کاربری سرویس با حداقل دسترسی و ثبت اقدام‌ها.

مثال فرضی: از فرم سایت تا CRM

فرایند: کاربر فرم «درخواست مشاوره» را پر می‌کند؛ سرنخ در CRM ساخته می‌شود؛ به تیم فروش اعلان می‌رسد. «مسیر خوشحال» سه گام است، اما استثناهای واقعی این‌ها هستند (مثال نویسنده):

با این جدول، انتخاب ابزار روشن‌تر می‌شود: چون استثناها ساده و بدون منطق مالی‌اند، یک ابزار گردش‌کار با مسیر خطا کافی است؛ اما اگر همین فرم قرار بود مستقیماً سفارش مالی بسازد، کد با تست و ایدمپوتنت انتخاب بهتری بود.

از کجا شروع کنیم؟

1. یک فرایند کوچک با ارزش روشن و حجم متوسط را انتخاب کنید.
2. مسیر خوشحال و پنج استثنای اصلی را بنویسید.
3. مالک، ماشه و معیار موفقیت را مشخص کنید (مثلاً «تعداد کار دستی در هفته» را قبل و بعد بسنجید).
4. اول نسخهٔ ساده را بسازید و فقط چند هفته با نظارت اجرا کنید.
5. بعد استثناها را به‌تدریج به مسیر خودکار بیاورید؛ نه همه را از ابتدا.

جدول تصمیم

ماشه‌ها

راهنمای Microsoft سه نوع ماشه را می‌شمارد: خودکار (مثلاً رسیدن ایمیل یا ایجاد ردیف)، دستی/فوری و زمان‌بندی‌شده (مثلاً هر جمعه). برای هر خودکارسازی بنویسید ماشه چیست، چند بار ممکن است تکرار شود، و اگر دو بار فعال شد چه می‌شود.

پایش و مالکیت

هر اتوماسیون «سیستم عملیاتی» است: نیاز به مالک، پایش و مستندات دارد. شمار اجرای موفق/ناموفق، تأخیر، و تعداد موارد ارجاع‌شده به انسان را بسنجید؛ مفاهیم پایه در پایش سیستم با متریک و هشدار آمده است.

اشتباهات رایج

• انتخاب ابزار قبل از نوشتن فرایند و استثناها.
• RPA برای سیستمی که API دارد.
• گردش‌کار بصری برای منطق مالی بدون تست.
• نبودن مسیر خطا و مالک.
• اجرای تکراری بدون ایدمپوتنت.
• رمزها و توکن‌ها داخل خود گردش‌کار یا اسکریپت.

چک‌لیست

1. فرایند و استثناهای آن مکتوب است.
2. ترتیب کانکتور/API ← HTTP ← RPA بررسی شده است.
3. مسیر خطا، هشدار و مالک تعریف شده است.
4. اجرای تکراری بی‌اثر است (ایدمپوتنت) یا خطر آن پذیرفته شده است.
5. اسرار در مخزن امن نگه‌داری می‌شوند، نه در متن گردش‌کار.
6. برای RPA برنامهٔ جایگزینی با API نوشته شده است.
7. پایش اجرای موفق/ناموفق و ارجاع به انسان برقرار است.

منابع و مراجع

• Determining which automation method to use (Power Automate planning guidance) — Microsoft (MicrosoftDocs/power-automate-docs, GitHub)، 2022-03-16.
• Handle errors gracefully — n8n Docs.