أنا أصمم سير عمل آلي لنشر المنشورات على Instagram لمشروع تسويق عقاري، وأود الحصول على تعليقات من الأشخاص الذين بنوا سير عمل مشابه باستخدام n8n.
الهيكل المعماري الحالي:
Obsidian Brain (مصدر واحد للحقيقة)
↓
Google Drive
↓
n8n
↓
قراءة الملاحظات الجاهزة لـ Instagram
↓
تحليل Markdown
↓
الذكاء الاصطناعي ينشئ التعليق + الوسوم + الحث على اتخاذ إجراء
↓
الموافقة عبر Slack
↓
تمت الموافقة؟
├── لا → تحرير / إعادة إنشاء
└── نعم
↓
Instagram Graph API
↓
النشر على Instagram
↓
تحديث Obsidian Brain
الهدف هو الحفاظ على Obsidian Brain كمصدر واحد للحقيقة مع ضمان مراجعة كل منشور على Instagram في Slack قبل نشره تلقائياً.
أود الحصول على تعليقاتك بشأن:
• هل هذا الهيكل المعماري منطقي؟
• هل كنت ستغير أو تبسط أي شيء؟
• هل هناك أي اختناقات أو مشاكل شائعة؟
• هل هناك طريقة أفضل لتنظيم هذا سير العمل في n8n؟
مرحبا Glven!
التدفق منطقي بالنسبة لي، لكن أود أن أتحقق من بعض الأشياء الأخرى:
إذا كان Obsidian مصدر الحقيقة الرئيسي لديك، فلا تدع Slack يصبح مكانًا مخفيًا تضيع فيه تحديثات الحالة: أود التأكد من حفظ جميع التفاصيل الرئيسية مباشرة في Obsidian بحيث يمكنك الحفاظ عليه كمصدر الحقيقة الوحيد لكل شيء.
أيضًا قبل النشر، سأجري فحصًا إضافيًا للموافقات المكررة/إعادة المحاولات لأن Slack وإعادة محاولات API يمكن أن تنطلق أحيانًا أكثر من مرة. وجود معرّف نشر/محتوى فريد وفحص idempotency يمكن أن ينقذك من المنشورات المكررة العرضية.
أخيرًا، قد يستحق الفرع “no” أيضًا تقسيمه إلى تحرير يدوي مقابل إعادة إنشاء مقابل رفض بدلاً من التعامل معهم جميعًا بنفس الطريقة، لكن بشكل عام إنها سير عمل نظيف جدًا!
الشكل سليم والنقاط التي أثارها Lupel حول كتابة الحالة مرة أخرى إلى Obsidian والحماية من الموافقات المكررة هي النقاط الصحيحة. ثلاثة أشياء حول خطوة النشر ستسبب لك مشاكل، لأن Instagram لا يعمل بالطريقة التي يعنيها عقدة Publish واحدة.
النشر عبارة عن استدعاءات API متعددة، وليس واحدة. تقوم بـ POST إلى /media لإنشاء حاوية والحصول على creation_id، ثم POST إلى /media_publish مع هذا المعرّف. الحاوية ليست جاهزة في اللحظة التي يتم إنشاؤها، لذلك بين الاثنين تحتاج إلى الاستطلاع عن الحاوية باستخدام fields=status_code حتى تعود FINISHED. النشر أثناء كونها لا تزال IN_PROGRESS يفشل، وبالنسبة لأي شيء بخلاف صورة صغيرة، فإن الفجوة طويلة بما يكفي لتهم.
هذا يؤدي إلى مشكلة ترتيب محددة لتصميمك. تنتهي صلاحية الحاويات بعد 24 ساعة. إذا أنشأت الحاوية قبل موافقة Slack، وجلست الموافقة خلال نهاية أسبوع أو كان شخص ما غائباً، فإن النشر يفشل على حاوية منتهية الصلاحية حتى لو تمت الموافقة على كل شيء بشكل صحيح. أنشئ الحاوية بعد عودة الموافقة، وليس قبلها. خطوة الموافقة محددة بسرعة الإنسان والحاوية ليست كذلك.
الذي يصطاد معظم الأشخاص الذين يستخدمون مكدس البرامج الخاص بك بالضبط: Instagram تجلب الصورة من خادم URL عام من جانب الخادم. رابط مشاركة Google Drive العادي لا يعيد بايتات الصورة، بل يعيد صفحة HTML، لذلك فشل إنشاء الحاوية أو ينتج عنه شيء غير مفيد. تحتاج إلى رابط مباشر يستجيب للملف الفعلي ونوع المحتوى الصحيح. من الجدير اختبار هذا الاستدعاء الفردي بمفرده قبل توصيل الباقي، لأن الخطأ الذي ينتجه غير واضح.
من الجدير أيضاً معرفته قبل تحجيمه: الحساب مقيد بـ 50 منشور منشور في فترة 24 ساعة متدحرجة، وتزامن Obsidian عبر Drive متسق في النهاية، لذلك قد تكون الملاحظة المقروءة في اللحظة التي تصل فيها ملف مكتوب جزئياً. يوفر التأخير القصير أو فحص الاكتمال قبل التحليل جلسة تصحيح أخطاء محيرة لاحقاً.
عملية Graph API ذات الخطوتين هي الجزء الذي يسبب المشاكل عادة، خاصة إذا كان موافقة Slack في المنتصف وقد تنتهي صلاحية الحاوية. ملاحظة الترتيب أعلاه هي الملاحظة المهمة.
إذا كنت لا تريد الحفاظ على هذه البنية الأساسية، فهناك عقدة مجتمعية من n8n تنشر على Instagram (و TikTok و YouTube و X) بعد تحميل الوسائط. هل حاولت النشر باستخدام Chat33؟ قد يكون أبسط من إدارة استدعاءات Graph بنفسك.
نحن نشغّل جدولنا الخاص على موقعنا، لذا كل هذا يأتي من الأشياء التي انهارت علينا.
الرمز المميز هو ما سأصلحه أولاً، لأنه يحدث في اليوم الذي لا ينظر إليه أحد. انتهى بنا الحال ببناء جزء يبقي المفتاح حياً بنفسه، حتى لا تستيقظ سير العمل على واحد ميت.
الذي سيكلفك الوقت هو الفيديو. مع صورة عادية، تمر المكالمتان بشكل جيد ويبدو أنها حلت. ضع فيديو وإنستاجرام لا يزال يستقبل الملف عندما تصل مكالمة النشر، لذا الحاوية ليست جاهزة. يجب أن تكون السلسلة: افتح التحميل، انتظر حتى تبلغ الحاوية عن جاهزيتها، ثم انشر.
يعمل لدينا على cron، لذا نوزع ذلك على عمليات التمرير بدلاً من النوم داخل التشغيل. التمرير الأول يحضر ويفتح، والتمرير الثاني ينشر، والتمرير الثالث موجود لحالة عدم جاهزية الوسائط. هذا الثالث هو ما أوقف الأعطال التي لم يكن أحد يراها.
واجهناها أولاً في الريلز. استمرت الكاروسيلات في العمل لفترة، ربما لأن الصور خفيفة بما يكفي للوصول في الوقت المناسب، لذا تركتها، ثم بدأت تفشل أيضاً واضطررت إلى بناء نفس الشيء لها.
على حد 50 لكل 24 ساعة متدحرجة: هذا يقع على حساب إنستاجرام، لذا لا تأخذه أي أداة. الطابور مسألة مختلفة. لا يوجد سبب لكي يحد الجدول من مدى المتقدمة التي يمكنك الذهاب إليها، والحد الأدنى لدينا سيحتفظ بفتحة بعد ثلاث سنوات ويطلقها بعد ذلك. مع القوائم التي لها تاريخ إطلاق، هذا هو الجزء الجدير بالحصول عليه.
بخصوص خطوة Slack الخاصة بك: إنشاء الحاوية بعد الموافقة هو الخيار الصحيح، لكن إذا قام نفس التشغيل بالنشر مباشرة بعد إنشاؤها، فسيعضك الفيديو هناك بالضبط. وإذا كانت قوائمك صوراً اليوم، فلن يظهر أي من هذا حتى يدخل جولة الفيديو الأولى.
تدفق obsidian → markdown → ai caption منطقي، لكن أعتقد أن الاختناق الحقيقي سيكون في حلقة موافقة Slack، وليس في النشر.
هناك عدة أشياء تستحق الاختبار قبل توسيع النطاق:
أضف مهلة زمنية على خطوة sendAndWait بحيث لا تبقى العناصر عالقة في obsidian limbo إذا لم يوافق أحد لمدة يوم
قم بإنشاء نسخ من التعليقات المُنشأة بواسطة الذكاء الاصطناعي بدلاً من الكتابة فوقها عند إعادة التوليد، حيث يريد مراجعو الامتثال العقاري عادةً معرفة ما تغير
اختبر حدود معدل واجهة برمجة تطبيقات Instagram Graph مبكراً، فهي أصعب مما يتوقعه الناس بمجرد أن تبدأ في النشر يومياً عبر عروض متعددة
شيء واحد أود تغييره من الناحية الهيكلية: قم بتحليل markdown وإنشاء التعليق بالتوازي بدلاً من التسلسل، سيقلل من وقت التشغيل والخطوة ai لا تعتمد فعلياً على انتهاء التحليل أولاً في معظم الحالات
أعجبني الشكل العام، خاصة الحفاظ على خطوة موافقة بشرية قبل النشر.
الشيء الرئيسي الذي أود توضيحه هو نموذج الحالة. يجب أن تحتوي كل مشاركة على معرّف محتوى مستقر وحالة مثل مسودة أو قيد الانتظار للموافقة أو تحتاج إلى تعديل أو موافق عليها أو تم إنشاء الحاوية أو منشورة أو فشلت. بهذه الطريقة، Slack هو مجرد سطح موافقة، وليس المكان الذي تعيش فيه حالة سير العمل بشكل سري.
سأيضاً حفظ التسمية التوضيحية النهائية الموافق عليها / عنوان URL الوسائط مرة أخرى إلى Obsidian قبل النشر. إذا فشلت المشاركة لاحقاً، فستظل لديك المنتج النهائي الموافق عليه بالضبط بدلاً من محاولة إعادة بنائه من سجل Slack.