التعامل مع مشاكل تنسيق حمولة webhook المتقطعة باستخدام رسم خرائط JSON ديناميكي في n8n

أسئلة
1

مرحباً بالجميع،

أواجه عائقاً منطقياً في سير عمل الأتمتة وأردت أن أرى كيف يتعامل الآخرون مع بيانات webhook الفوضوية الواردة.

السيناريو: لدي خدمة خارجية ترسل البيانات عبر webhook لتفعيل سير عمل n8n. ومع ذلك، قد تتغير بنية حمولة JSON الواردة أحياناً اعتماداً على نوع الحدث — أحياناً تكون المفاتيح متداخلة، وأحياناً أخرى يتم إرجاعها كمصفوفات مسطحة.

ما حاولته: أنا حالياً أستخدم عقد IF قياسية وعقدة Code تشغل JavaScript للتحقق من وجود المفاتيح قبل تعيينها إلى عقد HTTP Request اللاحقة. لكن عندما يحدث تحول في المخطط بشكل غير متوقع، يسبب أخطاء في التنفيذ اللاحق.

هل قام أي شخص ببناء نمط نظيف وقوي لتطبيع مخططات webhook المتقلبة داخل n8n قبل تمرير البيانات إلى التطبيقات اللاحقة؟ هل تستخدم سير عمل معالجة أخطاء فرعية محددة أو معالجة تعبيرات متقدمة؟

أقدر أي رؤى أو أفضل ممارسات يمكنك مشاركتها!

2

مرحباً @Maaz أهلاً وسهلاً!
النمط المرن هو التوقف عن التفريع بناءً على الحمولة الخام وتطبيعها مرة واحدة فقط، في عقدة Code واحدة مباشرة بعد Webhook، إلى مخطط ثابت يمكن لكل عقدة في المصب الاعتماد عليه. أجبر الشكل واقرأ المفاتيح بحذر هناك، بحيث لا يؤثر تحول المخطط سوى على تلك العقدة الواحدة بدلاً من كسر عقد HTTP Request:

const p = $json.body ?? $json;
const rows = Array.isArray(p) ? p : (Array.isArray(p.items) ? p.items : [p]);

return rows.map(r => ({
  json: {
    id:    r.id    ?? r.data?.id ?? null,
    email: r.email ?? r.data?.customer?.email ?? null,
    type:  r.event ?? r.type ?? 'unknown',
    raw:   r,
  }
}));

?. و ?? هي الأجزاء التي توفر المرونة: فهي تقرأ المفاتيح المتداخلة أو المفقودة دون رفع استثناء، بحيث يصبح المفتاح المنقول أو الغائب null بدلاً من أن يكون خطأ صارم. من هناك، قم بالتوجيه على نوع معياري باستخدام عقدة Switch بدلاً من IFs المتسلسلة (كل فرع لا يزال ينبعث من نفس المجالات)، اضبط On Error على Continue (باستخدام مخرجات الخطأ) على عقد HTTP Request بحيث يذهب عنصر واحد سيء إلى فرع خطأ بدلاً من إيقاف التشغيل، وأشر سير العمل إلى سير عمل Error Trigger مخصص ضمن Options > Settings بحيث يتم اكتشاف أي شيء يزحف لاحقاً والتنبيه عنه.