هذا الدليل يقدّم سبعة أمثلة عملية كاملة لأتمتة مهامك بـn8n، كل مثال بهدفه ومُشغّله (Trigger) وعُقده (Nodes) بالترتيب ونقاط الانتباه فيه. تبدأ من مثال بسيط يستقبل Webhook ويرسل تنبيهًا إلى Slack، ثم تتدرّج إلى مزامنة مجدوَلة عبر Cron وHTTP Request وعقدة IF، ونماذج تُسجَّل في Google Sheets، ومراقبة RSS، ومزامنة تطبيقين عبر API، وسير عمل كامل بمعالجة أخطاء وإعادة محاولة. ستجد جداول مرجعية للعُقد والمشغّلات وحالات الاستخدام والأخطاء الشائعة وأفضل الممارسات. ولأن n8n تُستضاف ذاتيًا لتعمل على مدار الساعة، فإن تشغيلها يحتاج خادم VPS مستقرًّا — وهذا ما نربطه عمليًا في كل مثال.
كل مثال هنا مصمَّم ليُنفَّذ كما هو: تفتح محرّر n8n، تُنشئ workflow جديدًا، وتضيف العُقد بالترتيب المذكور. الهدف ليس الإطلاع النظري بل أن تخرج بأتمتة تعمل فعلًا في بيئتك. وإن كنت ما زلت في بداية الطريق مع الأداة نفسها (التثبيت والمفاهيم الأساسية)، فارجع إلى الدليل الأشمل لـn8n ثم عُد إلى هنا للتطبيق.
رتّبنا الأمثلة تصاعديًّا في الصعوبة عن قصد. الأمثلة الأولى تعرّفك على لبنة واحدة جديدة في كل مرّة: المثال الأول يقدّم المُشغّل الفوري (Webhook)، والثاني يضيف الجدولة والشرط، والثالث الكتابة في خدمة خارجية، وهكذا حتى نصل في المثال السابع إلى دمج كل ما سبق مع طبقة معالجة الأخطاء. هذا التدرّج يعني أنك إن أتقنت المثال الأول فهمت آليًّا نصف المثال الثاني، فلا تقفز إلى الأمثلة المتقدّمة قبل أن يعمل البسيط بين يديك. وفي نهاية كل مثال جدول مرجعي يلخّص المُشغّل والعُقد والناتج، يصلح كبطاقة سريعة ترجع إليها لاحقًا دون إعادة قراءة الشرح كاملًا.
ما الذي تحتاجه قبل البدء بالأمثلة؟
قبل تنفيذ أي مثال، تأكّد من توفّر بيئة n8n جاهزة. لا تحتاج خبرة برمجية واسعة، لكن تحتاج فهمًا لثلاثة مفاهيم تتكرّر في كل workflow: المُشغّل (Trigger) الذي يبدأ التنفيذ، العُقد (Nodes) التي تعالج البيانات وتنقلها، والاعتمادات (Credentials) التي تخزّن مفاتيح الوصول إلى الخدمات الخارجية بأمان. هذه الثلاثة هي قواعد كل سير عمل مهما كبر: مُشغّل واحد في البداية، سلسلة عُقد في المنتصف، واعتمادات تربط العُقد بالعالم الخارجي بأمان. متى استوعبت أدوارها قرأت أي workflow معقّد كأنه جملة مفهومة لا كلغز.
نقطة جوهرية تتعلّق بكيفية انتقال البيانات: في n8n لا تنتقل قيمة واحدة بل "عناصر" (items) بهيئة JSON من عقدة إلى التالية، وكل عقدة تستقبل مخرجات سابقتها فتعدّلها أو تضيف إليها أو تتفرّع بناءً عليها. لهذا تكثر عقدة Set في الأمثلة: دورها أن تضمن أن البيانات الواصلة للعقدة التالية نظيفة ومسمّاة بوضوح، فلا تفاجئك حقول مفقودة أو أنواع خاطئة في منتصف السير.
الأمثلة هنا تفترض أن n8n تعمل على نطاق ثابت مع شهادة SSL، لأن عُقد Webhook خصوصًا تحتاج عنوانًا عامًا (public URL) لتستقبل الطلبات من الخدمات الخارجية. تشغيلها على جهازك المحلي يكفي للتجربة، لكن الإنتاج الفعلي يتطلّب خادمًا يعمل دون انقطاع. لهذا السبب يستضيف معظم المستخدمين n8n على خادم VPS صغير يضمن التشغيل المستمر والعنوان العام.
| العنصر | لماذا تحتاجه | البديل أثناء التجربة |
|---|---|---|
| نسخة n8n تعمل | بيئة بناء وتشغيل الـworkflows | نسخة محلية عبر Docker |
| نطاق + SSL | لاستقبال Webhooks خارجيًا | نفق مؤقّت (tunnel) للاختبار |
| Credentials للخدمات | الوصول الآمن لـSlack وSheets وغيرها | مفاتيح اختبار محدودة الصلاحية |
| فهم Trigger/Node | لبناء المنطق بشكل صحيح | المراجعة في الدليل الأساسي |
أنواع العُقد التي ستستخدمها في الأمثلة
العُقد في n8n تنقسم إلى فئات وظيفية. فهم دور كل فئة يجعل قراءة الأمثلة أسهل، لأن كل مثال ما هو إلا تركيب من هذه اللبنات:
| نوع العقدة | الوظيفة | أمثلة |
|---|---|---|
| مُشغّل (Trigger) | يبدأ تنفيذ سير العمل | Webhook، Schedule، RSS Feed Trigger |
| إجراء (Action) | ينفّذ عملية على خدمة | Slack، Google Sheets، Send Email |
| طلب عام | يخاطب أي API بـHTTP | HTTP Request |
| تحويل | يهيّئ البيانات ويعيد تشكيلها | Set، Edit Fields، Code |
| تحكّم | يتحكّم في مسار التدفّق | IF، Switch، Merge، Loop |
| مساعدة | عمليات مساندة | Wait، NoOp، Error Trigger |
أنواع المشغّلات (Triggers) ومتى تستخدم كلًّا منها
اختيار المُشغّل الصحيح هو نصف نجاح الـworkflow. المُشغّل يحدّد "متى" يعمل السير، وهذا قرار جوهري يؤثّر في الموثوقية والتكلفة:
| المُشغّل | يعمل عند | مثال استخدام |
|---|---|---|
| Webhook | وصول طلب HTTP خارجي | نموذج موقع يرسل بيانات فورًا |
| Schedule (Cron) | وقت محدّد متكرّر | تقرير يومي الساعة 8 صباحًا |
| RSS Feed Trigger | ظهور عنصر جديد في خلاصة | مراقبة مدوّنة أو مصدر أخبار |
| App Trigger | حدث داخل تطبيق مربوط | رسالة جديدة، صفّ جديد |
| Manual Trigger | الضغط يدويًا للاختبار | تجربة السير أثناء البناء |
| Error Trigger | فشل أي workflow آخر | تنبيه عند تعطّل الأتمتة |
المثال الأول: من Webhook إلى تنبيه Slack
هذا أبسط مثال عملي ومدخل ممتاز لفهم تدفّق البيانات: يستقبل n8n طلبًا خارجيًا (Webhook)، يهيّئ محتواه، ثم يرسله كرسالة منسّقة إلى قناة Slack. سيناريو واقعي شائع: عند إرسال أحد العملاء نموذج تواصل في موقعك، يصلك تنبيه فوري في فريق الدعم دون فتح البريد.
قيمة هذا المثال أنه يعلّمك الفكرة المركزية كلها في ثلاث عُقد: حدث يصل من الخارج، تحويل للبيانات، ثم إجراء على خدمة. كل مثال لاحق ليس إلا توسيعًا لهذا الهيكل الثلاثي: تُبدّل المُشغّل، أو تُضاعف عُقد التحويل، أو تستبدل الإجراء النهائي بخدمة أخرى. لذلك يستحقّ منك إتقانًا حقيقيًّا قبل الانتقال لما بعده.
الهدف: إشعار فوري في Slack عند وصول حدث خارجي (نموذج، طلب، تنبيه نظام). المُشغّل: عقدة Webhook تستقبل طلب POST. العُقد بالترتيب: Webhook ← Set (تهيئة الحقول) ← Slack (إرسال رسالة).
الخطوات بالترتيب
- أنشئ workflow جديدًا وأضف عقدة Webhook. اضبط الطريقة على
POSTوانسخ عنوان الـWebhook الذي يولّده n8n (عنوان الإنتاج، وليس عنوان الاختبار، عند النشر). - أضف عقدة Set (أو Edit Fields) لاستخراج الحقول التي تهمّك من الطلب الوارد وتسميتها بوضوح: الاسم، البريد، الرسالة. هذه الخطوة تجعل الرسالة النهائية نظيفة بدل تمرير الـJSON الخام.
- أضف عقدة Slack، واختر إجراء "Send a Message"، واختر القناة، ثم اكتب نصّ الرسالة مستخدمًا قيم الحقول من عقدة Set.
نصّ الرسالة في عقدة Slack يمكن أن يستعمل التعبيرات لإدراج البيانات الديناميكية مثل:
طلب جديد من: {{ $json.name }}
البريد: {{ $json.email }}
الرسالة: {{ $json.message }}
نقاط الانتباه
- استخدم دائمًا عنوان الإنتاج للـWebhook بعد تفعيل الـworkflow (Active)؛ عنوان الاختبار يعمل فقط أثناء النقر على "Listen for test event".
- أمّن الـWebhook إن أمكن بفحص توقيع أو مفتاح سرّي في الترويسة (Header) لتمنع الطلبات المزيّفة.
- إن كانت بنية الطلب الوارد غير ثابتة، أضف عقدة IF بعد Webhook لرفض الطلبات الناقصة بدل تمرير بيانات فاسدة إلى Slack.
- اضبط استجابة الـWebhook نفسه: يمكن أن يردّ فورًا برمز 200 ثم يكمل المعالجة، أو ينتظر اكتمال السير ليردّ بنتيجته. الخيار الأول أفضل عندما يكون المرسِل خدمة لا تحتمل انتظارًا طويلًا.
في الإنتاج، يُنصَح بإضافة عقدة Set ثانية قبل Slack لصياغة الرسالة بتنسيق غني (عناوين، روابط، رموز) بدل نصّ خام، فالتنبيه الواضح يُقرأ ويُتصرَّف بناءً عليه أسرع. كما يمكن توجيه الرسالة إلى قناة مختلفة حسب نوع الطلب عبر عقدة Switch، فتذهب طلبات الدعم لقناة وطلبات المبيعات لأخرى من السير نفسه.
| الجانب | التفصيل |
|---|---|
| المُشغّل | Webhook (POST) |
| العُقد | Webhook → Set → Slack |
| الناتج | رسالة فورية في قناة Slack |
| حالة شائعة | تنبيه فريق الدعم بنموذج جديد |
المثال الثاني: مزامنة مجدوَلة عبر Cron وHTTP وIF
هنا ننتقل من رد الفعل على حدث خارجي إلى التنفيذ المُجدوَل: workflow يعمل تلقائيًا في وقت محدّد، يجلب بيانات من API خارجي، يفحص شرطًا، ويتصرّف بناءً على النتيجة. مثال واقعي: مراقبة سعر منتج أو حالة خدمة كل ساعة، وإرسال بريد فقط عند تجاوز عتبة معيّنة.
الهدف: فحص دوري لمصدر بيانات واتخاذ إجراء مشروط (بريد عند تحقّق الشرط). المُشغّل: عقدة Schedule (Cron) في وقت متكرّر. العُقد بالترتيب: Schedule ← HTTP Request ← IF ← (Send Email عند "نعم" / NoOp عند "لا").
الخطوات بالترتيب
- أضف عقدة Schedule واضبط التكرار (مثلًا كل ساعة، أو يوميًا في توقيت محدّد). للتحكّم الدقيق استخدم تعبير Cron مباشرة.
- أضف عقدة HTTP Request لجلب البيانات من الـAPI. اضبط الطريقة على
GETوحدّد عنوان النقطة (endpoint)، وأضف الترويسات أو مفتاح الوصول عبر Credentials إن لزم. - أضف عقدة IF لفحص قيمة من الاستجابة (مثلًا: هل السعر أقل من حدّ معيّن؟ هل الحالة "down"؟).
- على فرع "true" أضف عقدة Send Email (أو Slack)؛ على فرع "false" يمكن ترك الفرع فارغًا أو وضع عقدة NoOp.
تعبير Cron نموذجي لتشغيل المهمة كل ساعة عند الدقيقة صفر:
0 * * * *
نقاط الانتباه
- اضبط فترة التكرار بحكمة: التكرار المفرط يستهلك موارد الخادم ويتجاوز حدود معدّل الطلبات (rate limits) لدى الـAPI الخارجي.
- استخدم Credentials لتخزين مفاتيح الـAPI بدل كتابتها مباشرة في عقدة HTTP Request.
- عقدة IF حسّاسة لنوع البيانات؛ تأكّد من مقارنة رقم برقم ونصّ بنصّ، وحوّل النوع في عقدة Set إن لزم.
- وثّق سبب الجدولة في تعليق داخل السير (مثلًا: "كل ساعة لأن المصدر يحدّث بيانات السعر ساعيًّا")، فهذا يمنع من يصونه لاحقًا من تغيير التوقيت عشوائيًّا.
فرق مهم بين Schedule هنا وWebhook في المثال الأول: المُشغّل الزمني لا يعتمد على طرف خارجي يدفع البيانات، بل يبادر بسحبها (polling). هذا يجعله أبسط في الإعداد وأكثر تحكّمًا، لكنه يضيف تأخيرًا بمقدار فترة التكرار: لن تعرف بالتغيير لحظة وقوعه بل في أقرب موعد فحص. اختر فترة قصيرة للأحداث الحسّاسة زمنيًّا، وفترة أطول لما يتحمّل تأخيرًا، موازنًا بين سرعة الاكتشاف واستهلاك الموارد وحدود معدّل المصدر.
| الجانب | التفصيل |
|---|---|
| المُشغّل | Schedule (Cron) |
| العُقد | Schedule → HTTP Request → IF → Email/NoOp |
| الناتج | بريد تنبيهي عند تحقّق الشرط |
| حالة شائعة | مراقبة سعر أو حالة خدمة دوريًّا |
تشغيل سير مجدوَل بدقّة على مدار الساعة يفترض أن خادمك لا ينام ولا ينقطع — وهذا بالضبط ما يميّز VPS مخصّص عن الحلول المؤقّتة أو المحلية.
سحابة الأتمتة n8n من wpressly
شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.
ابدأ مع سحابة الأتمتةالمثال الثالث: من نموذج (Form/Webhook) إلى Google Sheets
تسجيل بيانات النماذج في جدول بيانات حيّ من أكثر حالات الاستخدام طلبًا، لأنه يحوّل n8n إلى جسر بين موقعك وبين قاعدة بيانات بسيطة يطّلع عليها الفريق دون أدوات معقّدة. كل إرسال نموذج يصبح صفًّا جديدًا في Google Sheets فورًا.
الهدف: أرشفة كل إرسال نموذج كصفّ في Google Sheets دون تدخّل يدوي. المُشغّل: عقدة Webhook (أو n8n Form Trigger) تستقبل بيانات النموذج. العُقد بالترتيب: Webhook/Form ← Set (تنظيف الحقول) ← Google Sheets (Append Row).
الخطوات بالترتيب
- أضف مُشغّلًا: إمّا Webhook يستقبل بيانات النموذج من موقعك، أو n8n Form Trigger الذي يولّد نموذجًا جاهزًا باستضافة n8n نفسها.
- أضف عقدة Set لمطابقة حقول النموذج مع أعمدة الجدول بالترتيب الصحيح، وتنظيف القيم (إزالة الفراغات، توحيد التواريخ).
- أضف عقدة Google Sheets، اختر إجراء "Append Row"، حدّد الملف وورقة العمل، واربط كل عمود بالحقل المناسب.
نقاط الانتباه
- اضبط Credentials لـGoogle عبر OAuth2 وامنح الصلاحية لورقة العمل المحدّدة فقط، لا للحساب بالكامل.
- رتّب أسماء الأعمدة في الصف الأول من الجدول لتطابق أسماء الحقول، فهذا يبسّط الربط ويقلّل الأخطاء.
- لتفادي التكرار عند إعادة الإرسال، يمكن إضافة عقدة Google Sheets للقراءة أوّلًا ثم IF للتحقّق من عدم وجود الصف مسبقًا.
- أضف عمودًا للطابع الزمني (timestamp) يُملأ تلقائيًّا في عقدة Set بقيمة الوقت الحالي، فتعرف لاحقًا متى وصل كل سجلّ دون الاعتماد على ترتيب الصفوف.
هذا المثال يحوّل n8n عمليًّا إلى طبقة وسيطة بين موقعك وبين تخزين بسيط مرن. ميزته أن غير التقنيين في فريقك يقرؤون البيانات مباشرة في جدول مألوف، ويبنون فوقه مخططات أو تصفية دون لمس قاعدة بيانات. وعندما يكبر الحجم وتضيق إمكانات Google Sheets، يكفي استبدال العقدة الأخيرة بعقدة قاعدة بيانات حقيقية مع بقاء بقية السير كما هو — وهذا جوهر مرونة الأتمتة المبنية بلبنات.
| الجانب | التفصيل |
|---|---|
| المُشغّل | Webhook / Form Trigger |
| العُقد | Webhook → Set → Google Sheets (Append) |
| الناتج | صفّ جديد لكل إرسال نموذج |
| حالة شائعة | جمع leads أو تسجيلات فعالية |
المثال الرابع: مراقبة RSS أو منتج وإرسال إشعار
الأتمتة لا تنتظر دائمًا حدثًا يصلك، بل قد تذهب هي لتراقب مصدرًا خارجيًا نيابة عنك. هذا المثال يراقب خلاصة RSS (مدوّنة، مصدر أخبار، أو صفحة منتج تنشر تحديثاتها كـfeed) ويرسل إشعارًا عند ظهور عنصر جديد.
الهدف: متابعة مصدر متغيّر تلقائيًا والتنبيه عند كل جديد. المُشغّل: عقدة RSS Feed Trigger (أو Schedule + RSS Read). العُقد بالترتيب: RSS Trigger ← Set (انتقاء العنوان والرابط) ← Slack/Telegram (إشعار).
الخطوات بالترتيب
- أضف عقدة RSS Feed Trigger وأدخل عنوان الخلاصة (feed URL). تتولّى العقدة تتبّع العناصر الجديدة فلا تكرّر الإشعارات.
- أضف عقدة Set لانتقاء الحقول المفيدة: عنوان العنصر، الرابط، تاريخ النشر، ومقتطف موجز.
- أضف عقدة إشعار (Slack أو Telegram أو Send Email) وصُغ الرسالة بالعنوان والرابط.
نقاط الانتباه
- بعض الخلاصات تُحدَّث ببطء؛ اضبط فترة الفحص بما يناسب وتيرة المصدر لتفادي الفحص الزائد.
- إن كان المصدر لا يقدّم RSS، استخدم HTTP Request لجلب الصفحة ثم عقدة Code/HTML لاستخراج المعلومة، مع مقارنة بالقيمة السابقة للكشف عن التغيّر.
- خزّن آخر عنصر تمّت معالجته (في متغيّر أو قاعدة بيانات بسيطة) إن استخدمت Schedule بدل المُشغّل المخصّص، لتفادي تكرار الإشعارات.
| الجانب | التفصيل |
|---|---|
| المُشغّل | RSS Feed Trigger / Schedule |
| العُقد | RSS → Set → Slack/Telegram |
| الناتج | إشعار عند كل عنصر جديد |
| حالة شائعة | متابعة منافس أو مصدر أخبار |
المثال الخامس: مزامنة تطبيقين عبر API
كثير من الأعمال تستخدم أكثر من أداة لا تتكلّم مع بعضها: CRM في جهة، أداة دعم في أخرى، جدول بيانات ثالث. هذا المثال يبني جسرًا يزامن البيانات بين تطبيقين عبر الـAPI، فيُنشئ سجلًّا في التطبيق الثاني كلّما ظهر سجلّ جديد في الأول.
الهدف: إبقاء تطبيقين متّسقين دون إدخال يدوي مزدوج. المُشغّل: App Trigger للتطبيق المصدر (أو Schedule + HTTP Request للسحب الدوري). العُقد بالترتيب: Trigger ← HTTP Request (قراءة) ← Set (مطابقة الحقول) ← HTTP Request (كتابة في الوجهة).
الخطوات بالترتيب
- حدّد المُشغّل: استخدم عقدة التطبيق المخصّصة إن وُجدت (مثل "On new record")، أو عقدة Schedule تسحب الجديد دوريًا عبر HTTP Request.
- أضف عقدة HTTP Request لقراءة السجلّات الجديدة من التطبيق المصدر (مع ترشيح بالتاريخ أو معرّف آخر سجلّ).
- أضف عقدة Set لتحويل بنية البيانات من شكل المصدر إلى شكل الوجهة (تسمية الحقول، تحويل الأنواع).
- أضف عقدة HTTP Request بطريقة
POSTلإنشاء السجلّ في التطبيق الوجهة عبر الـAPI الخاص به.
نقاط الانتباه
- وحّد التعامل مع الترقيم (Pagination) في عقدة القراءة إن كانت السجلّات كثيرة، وإلا ستفوتك بيانات.
- احفظ معرّف آخر سجلّ تمّت مزامنته لتفادي التكرار في الدورة التالية (idempotency).
- راقب حدود معدّل الطلبات لكلا التطبيقين، وأضف عقدة Wait بين الطلبات إن لزم لتفادي الحظر المؤقّت.
- قرّر اتّجاه المزامنة بوضوح: أحادية (من المصدر للوجهة فقط) أم ثنائية. المزامنة الثنائية أقوى لكنها تفتح باب التعارض (تعديل السجلّ نفسه في الجهتين)، وتحتاج منطق "أيّ نسخة تفوز" مدروسًا.
المزامنة بين الأنظمة من أكثر الأتمتة قيمةً لأنها تقتل الإدخال المزدوج وما يصاحبه من أخطاء بشرية وتأخير. لكنها أيضًا الأكثر حساسية: خطأ في مطابقة الحقول أو في منطق منع التكرار يضرب بياناتك في مكانين دفعة واحدة. لذلك ابدأ بمزامنة أحادية الاتجاه على عيّنة صغيرة، تحقّق من النتائج يدويًّا، ثم وسّع النطاق تدريجيًّا قبل تشغيلها على كامل البيانات.
| الجانب | التفصيل |
|---|---|
| المُشغّل | App Trigger / Schedule |
| العُقد | Trigger → HTTP (قراءة) → Set → HTTP (كتابة) |
| الناتج | سجلّ متطابق في التطبيق الوجهة |
| حالة شائعة | مزامنة CRM مع أداة دعم |
المثال السادس: تلخيص أو معالجة دورية
بعض المهام لا ترسل بيانات فحسب بل تعالجها وتلخّصها: تجميع أرقام اليوم، إعداد تقرير مختصر، أو تنظيف بيانات متراكمة. هذا المثال يبني تقريرًا دوريًّا يُجمَّع من مصدر ويُرسَل ملخّصًا جاهزًا للقراءة.
الهدف: إنتاج ملخّص دوري (يومي/أسبوعي) من بيانات خام وإرساله. المُشغّل: عقدة Schedule (Cron) في نهاية اليوم أو الأسبوع. العُقد بالترتيب: Schedule ← HTTP Request/Database (جلب) ← Code أو Aggregate (تلخيص) ← Send Email/Slack.
الخطوات بالترتيب
- أضف عقدة Schedule بتوقيت إنتاج التقرير (مثلًا كل اثنين الساعة 9 صباحًا للتقرير الأسبوعي).
- أضف عقدة جلب البيانات: HTTP Request من API، أو عقدة قاعدة بيانات (Postgres/MySQL) لاستعلام السجلّات.
- أضف عقدة Code أو عقدة Aggregate/Summarize لتجميع الأرقام واحتساب المجاميع والمتوسّطات وصياغة نصّ الملخّص.
- أضف عقدة Send Email أو Slack لإرسال الملخّص النهائي بصيغة مقروءة.
مثال مبسّط لكود التجميع داخل عقدة Code:
const total = items.reduce((sum, item) => sum + item.json.amount, 0);
return [{ json: { total, count: items.length } }];
نقاط الانتباه
- احرص أن يتعامل الكود مع حالة "لا بيانات" (مصفوفة فارغة) فلا يفشل السير عند يوم بلا نشاط.
- إن كان التلخيص نصّيًّا معقّدًا، يمكن دمج عقدة نموذج لغوي، لكن ابقِ المنطق الحسابي في عقدة Code لضمان الدقّة.
- وثّق صيغة التقرير في تعليق داخل الـworkflow ليفهمه من يصونه لاحقًا.
| الجانب | التفصيل |
|---|---|
| المُشغّل | Schedule (Cron) |
| العُقد | Schedule → جلب → Code/Aggregate → Email/Slack |
| الناتج | تقرير ملخّص دوري |
| حالة شائعة | تقرير مبيعات أسبوعي تلقائي |
المثال السابع: سير عمل بمعالجة أخطاء وإعادة محاولة
الأتمتة الإنتاجية الحقيقية تتعامل مع الفشل بأناقة، لا تنهار عند أوّل خطأ. هذا المثال هو نسخة "صلبة" من أي workflow سابق: يضيف إعادة المحاولة عند الفشل المؤقّت، ومسارًا للتعامل مع الأخطاء، وتنبيهًا للمشرف عند الفشل النهائي.
الهدف: سير موثوق يقاوم الأعطال المؤقّتة ويُبلّغ عند الفشل الحقيقي. المُشغّل: أي مُشغّل (Webhook/Schedule) + Error Trigger منفصل للتنبيه. العُقد بالترتيب: Trigger ← عقدة العملية (مع Retry On Fail) ← IF (نجاح؟) ← مسار النجاح / مسار التعويض؛ وworkflow ثانٍ يبدأ بـError Trigger ← Slack تنبيه.
الخطوات بالترتيب
- في عقدة العملية الحرجة (مثل HTTP Request)، فعّل خيار Retry On Fail واضبط عدد المحاولات والمهلة بينها، لمعالجة الأعطال العابرة في الشبكة أو الخدمة.
- اضبط سلوك العقدة عند الفشل: إمّا "Stop Workflow" للمهام التي يجب ألّا تكمل ناقصة، أو "Continue (using error output)" لتمرير الخطأ إلى مسار تعويض.
- أضف عقدة IF بعد العملية للتحقّق من نجاحها وتوجيه التدفّق إلى مسار النجاح أو مسار التعامل مع الفشل.
- أنشئ workflow منفصلًا يبدأ بعقدة Error Trigger ويرسل تنبيه Slack تلقائيًّا عند فشل أي سير آخر، مع تفاصيل الخطأ واسم الـworkflow.
نقاط الانتباه
- لا تُكثر من إعادة المحاولة على الأخطاء الدائمة (مثل 401 أو 404)؛ إعادة المحاولة مفيدة للأخطاء المؤقّتة (مثل 429 أو انقطاع شبكة).
- اربط Error Trigger بقناة تنبيه فعّالة (Slack/بريد) لتعرف بالفشل فور حدوثه لا بعد أيام.
- استخدم عقدة Wait بين المحاولات للعمليات التي تتأثّر بحدود المعدّل، فإعادة المحاولة الفورية قد تفاقم الحظر.
| الجانب | التفصيل |
|---|---|
| المُشغّل | أي مُشغّل + Error Trigger |
| العُقد | Trigger → عملية (Retry) → IF → نجاح/تعويض |
| الناتج | سير موثوق + تنبيه عند الفشل |
| حالة شائعة | حماية أي أتمتة إنتاجية حرجة |
حالات استخدام إضافية حسب المجال
الأمثلة السبعة قوالب قابلة للتكييف. الجدول التالي يربط كل مجال بأتمتة عملية والعُقد التي تبنيها بها، لتنطلق منه مباشرة:
| المجال | الأتمتة | العُقد الأساسية |
|---|---|---|
| التسويق | إضافة lead جديد إلى CRM وإرسال ترحيب | Webhook → Set → CRM → Email |
| الدعم | تذكرة جديدة تُنشئ تنبيه فريق | App Trigger → IF → Slack |
| التجارة | طلب جديد يحدّث المخزون وجدول | Webhook → HTTP → Google Sheets |
| المحتوى | منشور جديد يُنشر على منصّات متعدّدة | RSS → Set → عدّة عُقد نشر |
| العمليات | نسخة احتياطية مجدوَلة لبيانات | Schedule → Database → تخزين |
| الموارد البشرية | طلب إجازة يُوجَّه للموافقة | Form → IF → Email → Sheets |
أخطاء شائعة
كثير من المشاكل في n8n تتكرّر لدى المبتدئين، ومعرفتها مسبقًا يوفّر ساعات من التشخيص. الجدول التالي يجمع أبرزها مع حلّها العملي:
| المشكلة | السبب | الحل |
|---|---|---|
| Webhook لا يستقبل شيئًا | استخدام عنوان الاختبار، أو الـworkflow غير مفعّل | فعّل الـworkflow واستخدم عنوان الإنتاج |
| عقدة IF تعطي نتيجة خاطئة | مقارنة نص برقم أو فرق نوع | حوّل النوع في Set قبل المقارنة |
| فشل Credentials فجأة | انتهاء صلاحية توكن OAuth | أعد توثيق الاعتماد وجدّد الصلاحية |
| تكرار البيانات | لا يوجد فحص idempotency | احفظ معرّف آخر سجلّ وتحقّق منه |
| تجاوز حدّ المعدّل (429) | طلبات متلاحقة بسرعة | أضف عقدة Wait أو وسّع فترة Schedule |
| السير يتوقّف عند خطأ بسيط | لا توجد معالجة أخطاء | فعّل Retry On Fail وأضف Error Trigger |
| بطء التنفيذ | معالجة دفعات ضخمة دفعة واحدة | قسّم البيانات أو استخدم Loop/Batches |
من أكثر الأخطاء كلفةً تشغيل n8n على بيئة غير مستقرّة: نسخة محلية تُغلق مع الجهاز، أو خادم ضعيف يتعثّر تحت الحمل. عندها تفشل الـworkflows المجدوَلة بصمت، فتكتشف لاحقًا أن تقاريرك ومزامناتك توقّفت منذ أيام.
أفضل الممارسات (Credentials, معالجة الأخطاء, الأداء)
بناء workflow يعمل مرّة شيء، وبناء أتمتة إنتاجية موثوقة شيء آخر. هذه الممارسات تفصل بين الاثنين، وتنقسم إلى ثلاثة محاور: الأمان، الموثوقية، والأداء.
الأمان وإدارة الـCredentials
- خزّن كل المفاتيح في Credentials الخاصة بـn8n ولا تكتبها يدويًا داخل العُقد، فهي تُشفَّر وتُعاد استخدامها بأمان.
- امنح كل اعتماد أقلّ صلاحية ممكنة (least privilege): مفتاح بصلاحية القراءة فقط إن كانت المهمّة قراءة.
- أمّن عُقد Webhook بمفتاح سرّي أو توقيع في الترويسة، وفعّل المصادقة الأساسية على واجهة n8n نفسها.
معالجة الأخطاء والموثوقية
- اجعل لكل workflow إنتاجي Error Trigger يبلّغك عند الفشل، فلا تكتشف الأعطال بالصدفة.
- فعّل Retry On Fail على العُقد التي تخاطب خدمات خارجية، فالأعطال المؤقّتة كثيرة.
- اختبر مسار الفشل عمدًا (أدخل بيانات خاطئة) للتأكّد أن السير يتصرّف كما خطّطت.
الأداء واستقرار الخادم
- جنّب معالجة دفعات ضخمة دفعة واحدة؛ استخدم Loop Over Items أو قسّم العمل لتقليل استهلاك الذاكرة.
- استخدم قاعدة بيانات خارجية (Postgres) لـn8n في الإنتاج بدل التخزين الافتراضي، فهي أكثر متانة تحت الحمل.
- راقب موارد الخادم (RAM وCPU) خصوصًا مع الـworkflows الكثيرة المتزامنة، ووسّع الخادم عند الحاجة.
| المحور | الممارسة | الفائدة |
|---|---|---|
| الأمان | Credentials + أقل صلاحية | منع تسريب المفاتيح |
| الأمان | تأمين Webhook والواجهة | منع الطلبات المزيّفة |
| الموثوقية | Error Trigger + Retry | اكتشاف الأعطال ومعالجتها |
| الموثوقية | اختبار مسار الفشل | لا مفاجآت في الإنتاج |
| الأداء | معالجة على دفعات | استهلاك ذاكرة أقل |
| الأداء | Postgres للإنتاج | متانة تحت الحمل |
كل هذه الممارسات تفترض أساسًا واحدًا: خادمًا يعمل دون انقطاع بموارد كافية ووصول كامل. الاستضافة الذاتية لـn8n على VPS مخصّص هي ما يجعل التشغيل المستمر والتأمين والأداء ممكنًا فعلًا، بخلاف البيئات المؤقّتة التي تنهار تحت الحمل أو تُغلق مع الجهاز.
سحابة الأتمتة n8n من wpressly
شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.
ابدأ مع سحابة الأتمتةكيف تشخّص workflow متعطّلًا؟
عندما تتوقّف أتمتة عن العمل، اتّبع مسار تشخيص منظّمًا بدل التخمين. ابدأ من سجلّ التنفيذ (Executions) في n8n الذي يعرض كل تشغيل ونتيجته والعقدة التي فشلت بالضبط. افتح آخر تنفيذ فاشل وتفحّص مدخلات ومخرجات كل عقدة لتحديد أين انكسر التدفّق.
إن كان الفشل في عقدة خارجية، تحقّق من الاعتماد (هل انتهت صلاحيته؟) ومن استجابة الخدمة (هل أعادت خطأ 4xx أو 5xx؟). إن كان السير لا يبدأ أصلًا، فالمشكلة في المُشغّل: Webhook بعنوان خاطئ، أو Schedule لم يُفعّل، أو الـworkflow نفسه غير نشط. أمّا إن توقّف التنفيذ كليًّا عبر كل الـworkflows، فالأرجح أن المشكلة على مستوى الخادم: نفاد الذاكرة، أو توقّف خدمة n8n، أو امتلاء القرص. هنا تُراجَع سجلّات الخادم وموارده مباشرة.
الخلاصة
أمثلة هذا الدليل تغطّي العمود الفقري للأتمتة العملية بـn8n: استقبال الأحداث عبر Webhook، التنفيذ المجدوَل بـSchedule، الفحص الشرطي بـIF، تخاطب الـAPIs بـHTTP Request، تسجيل البيانات في Google Sheets، مراقبة المصادر، مزامنة التطبيقات، التلخيص الدوري، وأخيرًا تصليب كل ذلك بمعالجة الأخطاء وإعادة المحاولة. كل مثال قالب قابل للتكييف: غيّر العقدة الأخيرة من Slack إلى بريد، أو من Sheets إلى قاعدة بيانات، وستحصل على أتمتة جديدة بالمنطق نفسه.
المفتاح أن تبدأ بمثال بسيط يعمل، ثم تضيف الموثوقية تدريجيًّا: Credentials آمنة، معالجة أخطاء، وحدود معدّل محترمة. ومع نموّ عدد الـworkflows، يصبح استقرار الخادم العامل الحاسم. لتعميق فهمك للأداة من جذورها راجع الدليل الأشمل لـn8n، ولاختيار البيئة المناسبة للتشغيل المستمر اطّلع على تشغيله على VPS.
سحابة الأتمتة n8n من wpressly
شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.
ابدأ مع سحابة الأتمتةالأسئلة الشائعة
هل أحتاج خبرة برمجية لبناء هذه الأمثلة؟ لا تحتاج خبرة واسعة. معظم الأمثلة تُبنى بالعُقد الجاهزة وواجهة السحب والربط دون كتابة كود. تظهر الحاجة للكود فقط في حالات التلخيص أو التحويل المعقّد عبر عقدة Code، وحتى هناك تكفي أسطر قليلة بسيطة.
ما الفرق بين عنوان Webhook الاختباري وعنوان الإنتاج؟ عنوان الاختبار يعمل فقط أثناء الضغط على "Listen for test event" ويتوقّف بعد التقاط طلب واحد، وهو للتجربة. عنوان الإنتاج يعمل دائمًا بشرط أن يكون الـworkflow مفعّلًا (Active). الخلط بينهما أكثر أسباب "الـWebhook لا يستقبل شيئًا".
كيف أمنع تكرار معالجة نفس البيانات؟ احفظ معرّفًا فريدًا لآخر سجلّ تمّت معالجته (في متغيّر أو جدول)، وأضف عقدة IF تتحقّق من عدم وجوده مسبقًا قبل المعالجة. هذا المبدأ يُسمّى idempotency وهو جوهري في المزامنة والمراقبة الدورية.
أيّ مُشغّل أختار بين Webhook وSchedule؟ استخدم Webhook عندما يأتيك الحدث من الخارج فورًا (نموذج، طلب، تنبيه نظام)، واستخدم Schedule عندما تريد الذهاب لفحص مصدر في وقت محدّد متكرّر. القاعدة: رد الفعل على حدث = Webhook، الفحص الدوري = Schedule.
كيف أتعامل مع حدود معدّل الطلبات (rate limits)؟ أضف عقدة Wait بين الطلبات المتلاحقة، ووسّع فترة التكرار في Schedule، وفعّل Retry On Fail مع مهلة كافية للأخطاء من نوع 429. تجنّب إرسال دفعات كبيرة دفعة واحدة إلى API محدود المعدّل.
هل يمكن ربط n8n بأي خدمة ليس لها عقدة جاهزة؟ نعم، عبر عقدة HTTP Request العامة التي تخاطب أي API يدعم REST. تضبط الطريقة والعنوان والترويسات والمصادقة يدويًا، فتصل عمليًّا إلى أي خدمة لها واجهة برمجية حتى دون تكامل مخصّص.
أين أرى سبب فشل workflow؟ في قسم Executions داخل n8n، الذي يسجّل كل تشغيل ونتيجته. افتح التنفيذ الفاشل وستجد العقدة التي توقّفت عندها بالضبط مع مدخلاتها ومخرجاتها ورسالة الخطأ، وهذا نقطة البداية الصحيحة لأي تشخيص.
هل أشغّل n8n محليًّا أم على خادم؟ محليًّا للتعلّم والتجربة فقط. أمّا الإنتاج الفعلي فيحتاج خادمًا يعمل على مدار الساعة بعنوان عام ثابت، لأن الـworkflows المجدوَلة وعُقد Webhook تتطلّب توفّرًا مستمرًّا. الخيار العملي هو استضافة n8n على VPS مخصّص.
كيف أؤمّن الـCredentials في n8n؟ خزّنها دائمًا في نظام Credentials المدمج (المشفّر) ولا تضعها كنصّ صريح داخل العُقد. امنح كل اعتماد أقل صلاحية تكفي المهمّة، وراجع الصلاحيات دوريًّا، وفعّل المصادقة على واجهة n8n نفسها لمنع الوصول غير المصرّح.
ما أبسط مثال أبدأ به؟ مثال Webhook إلى Slack (الأول في هذا الدليل) هو الأفضل للبداية: ثلاث عُقد فقط، ويوضّح تدفّق البيانات من المُشغّل إلى الإجراء بأقل تعقيد. بعد إتقانه ستفهم المنطق العام الذي تتكرّر عليه كل الأمثلة الأخرى.