مشروع: ربط نموذج طلبات بجدول وإشعار تيليغرام
4–5 أيام شغل مركز، صفر تكلفة، ومخرَج أقرب مشروع بالمسار كله لطلب عميل حقيقي فعلي: نموذج طلب وهمي يستقبله n8n لحظياً، يصنّفه، يسجّله بجدول تتبع، ويرسل إشعار تيليغرام فوري — نفس البنية اللي بيطلبها متجر إلكتروني حقيقي من مهندس أتمتة.
ابدأ خطوات التنفيذ ارجع لخارطة المسارليش هالمشروع بالذات؟
لأنه أقرب سيناريو بالمسار كله لمشروع عميل حقيقي مدفوع الأجر. راجع أرقام السوق الموثقة: مشروع «ربط نموذج بجدول قيود بشرط تصنيف» يُطلب فعلياً على منصات الفريلانس بميزانيات تتراوح 100–250$ — وهاد بالضبط النوع من الطلبات، بس بمقياس أصغر وبيانات وهمية. الفرق الجوهري بينه وبين المشروع الأول أنك هون تنتقل من مُشغّل زمني يفحص الجدول دورياً (Polling) إلى مُشغّل فوري (Webhook) يستجيب لحظة وصول الطلب — نقلة مفهومية أساسية بكل أتمتة حقيقية.
وفيه سبب عملي أعمق: هالمشروع بيعلّمك التصنيف الشرطي — مو كل طلب يُعامَل بنفس الطريقة. طلب بقيمة عالية يستحق تنبيهاً مختلفاً عن طلب عادي، وهاد بالضبط شكل التفكير اللي بيميّز أتمتة مصممة بعناية عن سلسلة عقد موصولة ببعضها بلا منطق. لما تنجح تبني هالمشروع، بتكون بنيت نسخة مصغرة حقيقية من أغلب مشاريع «ربط الأنظمة» اللي بتشوفها بإعلانات الوظائف والمشاريع.
بصراحة كمان: هالمشروع اختبار جديتك بمعالجة الأخطاء. النموذج الأول سامحك بأخطاء صغيرة لأن أثرها محدود، بس هون — أي فشل صامت يعني طلب عميل حقيقي ضاع بلا أن يعرف أحد. التعامل الجدي مع هالاحتمال من اليوم الأول هو الفرق بين مبتدئ ومحترف مبكر.
خطوات التنفيذ الكاملة
المدة الواقعية: 4–5 أيام بمعدل 2–3 ساعات شغل مركز يومياً. لا تقفز لخطوة معالجة الأخطاء بآخر لحظة — بنيها بالتوازي مع باقي السير.
الخطوة 1: اخترع متجراً وهمياً وصمّم حقول نموذج الطلب (ساعة)
اخترع متجراً إلكترونياً بسيطاً — أدوات مكتبية أو منتجات عناية أو إكسسوارات — وحدد 4–5 منتجات بأسعار واضحة. صمّم حقول نموذج طلب واقعية: اسم العميل، رقم الهاتف، المنتج المطلوب، الكمية، والعنوان. هالسياق الموحد بيخليك تبني منطق تصنيف حقيقي (طلب بقيمة عالية = كمية كبيرة أو منتج غالي) بدل بيانات عشوائية بلا معنى تجاري.
الخطوة 2: ابنِ نموذج الطلب واربطه بمُشغّل Webhook (ساعتان)
أنشئ نموذجاً (عبر Google Forms أو نموذج HTML بسيط إن كنت تفضل) يجمع الحقول اللي حددتها بالخطوة الأولى. بسير عمل n8n جديد، أضف عقدة Webhook كمُشغّل أول، وخذ الرابط الفريد اللي تولّده واربطه بنظام إرسال النموذج (عبر تكامل مباشر أو خدمة وسيطة حسب النموذج المختار). جرّب إرسال طلب تجريبي وتأكد أن n8n يستقبل البيانات فوراً — هاد أول اختبار حقيقي لمنطق «الإشعار الفوري» بدل «السؤال الدوري».
الخطوة 3: نظّف ونسّق البيانات الواردة (ساعتان)
البيانات الخام من الـWebhook تصل بصيغة JSON قد تحتوي حقولاً بأسماء غير مريحة أو تنسيقاً غير موحد. أضف عقدة Set تعيد تسمية الحقول بوضوح (اسم العميل، رقم الهاتف، إلخ) وتتأكد أن الحقول الأساسية غير فارغة قبل المتابعة. هالخطوة تبدو ثانوية لكنها أساس استقرار كل ما يليها — بيانات غير منظمة بدري تسبب أخطاء صامتة لاحقاً.
الخطوة 4: أضف شرط تصنيف الطلبات العاجلة (ساعتان)
أضف عقدة IF تفحص قيمة الطلب الإجمالية: إن تجاوزت مبلغاً معيناً (حدده أنت، مثلاً ضعف متوسط سلة الشراء)، صنّف الطلب «عاجل»، وإلا فهو «عادي». هالشرط البسيط هو جوهر «منطق العمل» (Business Logic) اللي بيميز أتمتة مصممة بعناية عن نسخ ولصق بيانات آلي بلا تفكير.
الخطوة 5: سجّل كل طلب بجدول تتبع (ساعة ونصف)
أضف عقدة Google Sheets (Append) تكتب صفاً جديداً بجدول «تتبع الطلبات» يضم كل التفاصيل المنظفة بالإضافة لتصنيف العجلة وتاريخ ووقت الاستلام. هالجدول رح يصير سجل العميل الكامل للطلبات — نفس الوظيفة اللي بيطلبها أي متجر حقيقي من نظام تتبع طلبات بسيط.
الخطوة 6: أرسل إشعار تيليغرام منسّق (ساعتان)
أضف عقدة Switch أو IF تختار صياغة الرسالة حسب التصنيف: رمز مميز ونص «⚡ طلب عاجل» للطلبات عالية القيمة، ورسالة عادية لباقي الطلبات. أرسل الإشعار عبر عقدة HTTP Request أو Telegram لبوت أنشأته بنفس طريقة المشروع الأول. الرسالة المنسّقة بوضوح — لا نص JSON خام — هي التفصيل اللي بيفرّق بين أتمتة احترافية وأتمتة «شغالة بس بشعة».
الخطوة 7: أضف سير عمل معالجة أخطاء وتسجيل الفشل (ساعتان)
ابنِ سير عمل معالجة أخطاء بسيطاً (Error Workflow) يُطلق تلقائياً إن فشلت أي خطوة بالسير الأساسي — يسجّل تفاصيل الفشل بصف منفصل بجدول «سجل الأخطاء» ويرسل لك تنبيهاً شخصياً. جرّب تعطيل الاتصال بالجدول مؤقتاً وأرسل طلباً تجريبياً — تأكد أن الفشل يُسجَّل وينبهك، لا يختفي بصمت.
الخطوة 8: اختبر ببيانات واقعية فوضوية ووثّق النطاق (يوم)
أرسل عشرة طلبات تجريبية بتنويعات واقعية: حقل هاتف بصيغ مختلفة، اسم بأحرف عربية وإنكليزية مختلطة، طلب بقيمة قريبة جداً من عتبة «العاجل» لاختبار الحد الفاصل بدقة. راجع الجدول وإشعارات تيليغرام للتأكد من صحة كل حالة. اكتب صفحة توثيق قصيرة تشرح: ماذا يفعل سير العمل، ما هي حدوده (النطاق)، وكيف يُختبر — هالتوثيق هو ما يميز مشروعاً جاهزاً للتسليم عن تجربة شخصية فقط.
معايير التقييم الذاتي — قيّم حالك بصدق
لا تعتبر المشروع خالصاً قبل ما تحقق كل بند. هالمشروع الأقرب لعقد حقيقي — التساهل هون بيكلفك ثقة عميل فعلي لاحقاً:
- الـWebhook يستقبل البيانات لحظياً وبثبات: اختبرته عدة مرات متتالية بلا أي طلب ضائع أو متأخر.
- شرط التصنيف يعمل بدقة على الحد الفاصل: اختبرت طلباً بقيمة قريبة جداً من العتبة وتأكدت من التصنيف الصحيح بالاتجاهين.
- جدول التتبع كامل ودقيق: كل طلب مسجَّل بكل تفاصيله بلا حقول فارغة غير مبررة.
- إشعار تيليغرام منسّق ومقروء ويميّز العاجل بوضوح: لا نص JSON خام، ولا صياغة موحدة تتجاهل التصنيف.
- معالجة الأخطاء تعمل فعلياً لا نظرياً: اختبرتها بتعطيل أحد الاتصالات عمداً وتأكدت من التسجيل والتنبيه.
- اختبرت ببيانات واقعية فوضوية: صيغ هاتف مختلفة، أسماء بأحرف مختلطة، حالات حدّية بالتصنيف.
- لا مفاتيح أو Tokens ظاهرة بأي مكان: كل بيانات الاعتماد محفوظة بنظام Credentials المشفر حصراً.
- صفحة توثيق قصيرة جاهزة: تشرح النطاق والحدود بلغة يفهمها عميل غير تقني بلا حاجة لشرحك الشفهي.
كيف تعرضه بمعرض أعمالك؟
هالمشروع أقوى قطعة بملف أعمالك المبكر لأنه يطابق تماماً الشكل اللي بيطلبه عميل حقيقي، مو تمريناً مجرداً. أساسيات بناء دليل ملموس بلا خبرة سابقة بتلاقيها بدليل معرض أعمال بلا خبرة — طبّقها هون بالتحديد لأن المشروع أقرب حالة لعقد فعلي.
سطر العرض المقترح: «بنيت أتمتة تستقبل طلبات متجر لحظياً، تصنّفها حسب القيمة، تسجّلها بجدول تتبع، وترسل إشعاراً فورياً — مع معالجة أخطاء كاملة». برسالة التقديم لأي طلب مشروع «ربط نموذج بجدول» أو «إشعار تلقائي عند طلب جديد»، اذكر المشروع مباشرة واعرض توثيقه — العميل اللي بيشوف مشروعاً موثقاً بمعالجة أخطاء واضحة بيثق بك أسرع من عرض نصي عام.
وهو ثاني قطعة من ثلاث: مشروع أتمتة النشر المجدول أثبت فهمك للمُشغّلات الزمنية ومنع التكرار، وهالمشروع أثبت فهمك للاستقبال اللحظي والتصنيف الشرطي، ومشروع لوحة تجميع الفرص من RSS بيضيف برهان معالجة مصادر متعددة على نطاق أوسع.
الأخطاء القاتلة — لا تقع فيها
ترك رابط الـWebhook مفتوحاً بلا أي تحقق
رابط Webhook عام بلا تحقق توقيع أو مفتاح سري معرّض لطلبات مزيفة من أي طرف يكتشف الرابط. حتى بمشروع تدريبي، تمرّن على إضافة تحقق بسيط — هالعادة ضرورية بأي مشروع عميل حقيقي.
اختبار التعديلات على بيانات حقيقية بدل تجريبية
حتى لو المشروع تدريبي بالكامل، تمرّن على فصل بيانات الاختبار عن أي بيانات نهائية ستستخدمها لاحقاً — هذه العادة تحميك مباشرة أول مرة تتعامل فيها مع بيانات عميل حقيقي فعلاً.
تجاهل الحد الفاصل بشرط التصنيف
اختبار الحالات الواضحة فقط (طلب رخيص جداً أو غالٍ جداً) بلا اختبار القيمة القريبة من العتبة يخفي أخطاء منطقية تظهر لاحقاً مع عميل حقيقي بأسوأ توقيت ممكن.
تسليم مشروع بلا توثيق نطاق مكتوب
مشروع يعمل تقنياً لكن بلا شرح واضح لحدوده وطريقة عمله يصعب على أي عميل الوثوق به أو صيانته لاحقاً — التوثيق جزء من المخرَج لا إضافة اختيارية.
أسئلة بتخطر ببالك
ما عندي متجر حقيقي — هل التمرين ببيانات وهمية كافٍ فعلاً؟
نعم تماماً، والدليل موثق بأرقام السوق نفسها: مشاريع «ربط أنظمة» حقيقية على منصات الفريلانس تُطلب بميزانيات مشابهة بغض النظر عن كون منتجك الفعلي حقيقياً أو تدريبياً — المهارة المطلوبة من العميل هي بناء المنطق (Webhook، تصنيف، تسجيل، إشعار)، لا معرفة تفاصيل منتج بعينه. أتقن البنية هون وطبّقها لاحقاً على أي منتج حقيقي يطلبه عميل فعلي بتعديل بسيط بالحقول والمنطق.
شو الفرق العملي بين هالمشروع والمشروع الأول غير نوع المُشغّل؟
الفرق الأعمق هو طبيعة المخاطرة: مشروع النشر المجدول (المشروع الأول) لو تأخر أو فشل مرة، الأثر محدود — منشور تأخر يوماً. أما هون، كل فشل يعني طلب عميل حقيقي محتمل ضاع. هالفرق بيغير طريقة تفكيرك بمعالجة الأخطاء من «إضافة لطيفة» إلى «جزء أساسي غير قابل للتفاوض» من أي أتمتة تستقبل بيانات حساسة لحظياً.
خلصت؟ هي خطوتك الجاية
بنيت أتمتة تستقبل بيانات لحظياً وتصنّفها وتعالج أخطاءها؟ انتقل للمشروع الثالث والأخير — يضيف مهارة معالجة مصادر بيانات متعددة دفعة واحدة.
المشروع التالي: لوحة تجميع الفرص من RSS خارطة مسار الأتمتة والنو-كود
ولما تكمل المشاريع الثلاثة وتجهز ملف أعمالك — دليل أول عميل فريلانس بيفيدك بجزئه عن التقديم الأول وكسب الثقة.