القسم 1 - الخطوة 2.5 - خطأ 422 في طلب HTTP Post (عقدة SendToPriorityQueue)

أكاديمية n8n N8N102: التكاملات: APIs وسير العمل المتصلة
1
  • إصدار n8n: 2.30.7 (Cloud)
  • قاعدة البيانات (الافتراضي: SQLite): افتراضي
  • إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main): افتراضي
  • تشغيل n8n عبر (Docker, npm, n8n cloud, desktop app): n8n cloud
  • نظام التشغيل: Windows 11

مرحباً،

على الرغم من أن عقدة HTTP POST Request الأخرى تعمل بشكل صحيح، فإن عقدة SendToPriorityQueue تُرجع الخطأ التالي:

طلبك غير صحيح أو لم تتمكن الخدمة من معالجته [العنصر 0]

واحد أو أكثر من المعاملات المطلوبة مفقودة. تأكد من إرسال assessment_id وبيانات الطلب.

اعتقدت أنها قد تكون مشكلة في الإدخال، لأن الفرق الوحيد بين هذا وطلب HTTP Post الذي يعمل بشكل صحيح هو أن الإدخال في الحالة الأولى، قائمة الطلبات، مغلفة في كائن محدد يسمى enriched_orders، بينما في طلب POST الذي يفشل، الإدخال عبارة عن مصفوفة طلبات غير محددة - لا يوجد كائن مُحيط، لكن تعليمات الدورة لا تتطلب ذلك لذا لا يمكنني معرفة ما الذي أخطأت فيه.

إليك JSON لطلب POST:

{
"body": {
"order_id": "ORD-014",
"customer_id": "CUST-004",
"customer_name": "DataFlow Ltd",
"subscription": "Enterprise"
},
"headers": {
"x-assessment-id": "0a238a9ad1137d3bf5cf2df2e7355e3b",
"مخفي": "مخفي",
"accept": "application/json,text/html,application/xhtml+xml,application/xml,text/;q=0.9, image/;q=0.8, /;q=0.7"
},
"method": "POST",
"uri": "``https://learn.app.n8n.cloud/webhook/course/n8n102/priority-queue``",
"gzip": true,
"rejectUnauthorized": true,
"followRedirect": true,
"resolveWithFullResponse": true,
"sendCredentialsOnCrossOriginRedirect": false,
"followAllRedirects": true,
"timeout": 300000,
"encoding": null,
"json": false,
"useStream": true

2

إن dump الخيارات هذا هو كائن الطلب الداخلي لـ n8n، وهناك شيئان يبرزان فيه: “json”: false، وليس هناك رأس content-type في أي مكان في القائمة.

لذا فإن نقطة النهاية تتلقى على الأرجح body لا يتم تحليله كـ JSON، مما ينتج عنه بالضبط “missing one or more required parameters” الذي تراه حتى لو كانت الحقول موجودة بوضوح في payload. الخادم لا يجد order_id لأنه لم يقم أبداً بتحليل body إلى حقول.

سأقارن بين عقدتي HTTP Request الخاصة بك على Body Content Type تحديداً (Send Body، ثم Body Content Type، ثم JSON) بدلاً من مقارنتك بشكل البيانات. إذا كانت العقدة العاملة مضبوطة على JSON وهذه ليست كذلك، فإن هذا الاختلاف وحده يشرح ذلك، و enriched_orders wrapper هو herring أحمر.

هناك شيئان سيحسمان الأمر بسرعة:

  1. فعّل “Include Response Headers and Status” على العقدة المعطلة. جسم 422 عادة ما يذكر الحقل الذي لم يتمكن من العثور عليه، مما يحول هذا من تخمين إلى إجابة بسطر واحد.

  2. أعد توجيه العقدة المعطلة مؤقتاً إلى عقدة Webhook في سير عمل آخر وقم بإطلاقها مرة واحدة. هذا يوضح لك بالضبط ما يصل، سواء content-type وما إذا كان body قد وصل كحقول محللة أو كسلسلة واحدة. عادة ما يكون أسرع من التفكير فيه.

شيء واحد لا يمكنني معرفته من هنا: ما إذا كان نقطة النهاية تريد أيضاً assessment_id في body، وليس فقط كرأس x-assessment-id. الخطأ يذكر “assessment_id and order data” معاً، وهذا يقرأ كما لو أنه يتوقع كليهما في payload، لكن هذا يعتمد على عقد API الخاص بالدورة. إذا كان جسم الاستجابة من الخطوة 1 يذكره، فهذه هي إجابتك.