Overview
إذا لم تصل إشعارات إيصالات التسليم (DLR) من BroadNet إلى خادمك، فغالبًا ما يكون السبب في جانب المُستقبِل: إما لعدم وجود عنوان URL لرد الاستدعاء (callback) مُهيأ في الحساب، أو لأن عنوان URL غير مُتاح للعامة عبر HTTPS، أو لأن نقطة النهاية لا تُعيد استجابة HTTP 200 بسرعة. تُرسل المنصة إيصال تسليم JSON (يتضمن MessageId وStatus وBatchId وغيرها) إلى عنوان URL الخاص بك عند وصول كل رسالة إلى حالتها النهائية - تحقق من عنوان URL والاستجابة وجدار الحماية أولًا.
لم يتم تكوين عنوان URL لرد الاستدعاء (callback) (أو تم تكوينه بشكل خاطئ).
لا تعمل خطافات DLR إلا إذا تم تعيين عنوان URL لرد الاستدعاء (callback) في حسابك. إذا لم يتم تكوين أي عنوان URL، أو إذا كان يشير إلى مضيف قديم أو خاطئ، فلن يتم إرسال أي شيء ولن يظهر أي خطأ من جانبك. تأكد من عنوان URL الخاص بـ DLR/webhook في الحساب، وإذا لم تتمكن من استقبال الإشعارات إطلاقًا، فاسحب الحالة عند الطلب (عبر واجهة HTTP القديمة: GET /websmpp/websmsstatus مع معرّف الاستجابة).
- تتطلب خطافات الويب تعيين عنوان URL لرد الاستدعاء في الحساب.
- عنوان URL المفقود/القديم يعني عدم وصول أي تقارير دون أي خطأ ظاهر.
- تأكد من أن عنوان URL الخاص بـ DLR المُكوّن مُحدّث.
- البديل: اسحب الحالة عند الطلب (واجهة HTTP القديمة: /websmpp/websmsstatus).
نقطة النهاية غير قابلة للوصول إليها بشكل عام عبر بروتوكول HTTPS
تستخدم المنصة بروتوكول POST من الإنترنت العام، لذا فإن استخدام localhost أو عنوان IP خاص أو شهادة TLS غير موثوقة/موقعة ذاتيًا أو قائمة عناوين IP مسموح بها تستثني مُرسلينا، سيؤدي جميعها إلى منع وصول رد الاتصال. لذا، يُنصح بتوفير نقطة نهاية HTTPS عامة بشهادة صالحة، وفي حال استخدام قائمة عناوين مسموح بها، يُرجى السماح بعناوين BroadNet الصادرة. اختبر عنوان URL من خارج شبكتك قبل توجيه اللوم إلى المنصة.
- يجب أن يكون عنوان URL عامًا بتقنية HTTPS مع شهادة صالحة.
- لن يتم استلام الطلبات من خلال localhost أو عناوين IP الخاصة أو الشهادات الموقعة ذاتيًا.
- قم بإضافة مُرسلي BroadNet إلى قائمة السماح إذا كنت تقوم بتصفية حركة الرسائل الواردة.
- قم بتشغيل الأمر curl للوصول إلى نقطة النهاية من خارج شبكتك للتأكد من إمكانية الوصول إليها.
نقطة النهاية لا تُرجع رمز الاستجابة 200 بسرعة
يجب أن يستجيب جهازك برمز HTTP 200 فورًا. إذا أعاد رمز خطأ 4xx/5xx، أو تجاوز المهلة، أو توقف أثناء تنفيذ عمليات معقدة، فسيتم التعامل مع عملية التسليم على أنها فاشلة وإعادة المحاولة مع تأخير متزايد - وهو ما يبدو كـ "فقدان" أو تأخير في إشعارات الويب. أعد رمز 200 فورًا وقم بمعالجة طلب DLR بشكل غير متزامن (ضعه في قائمة الانتظار، ثم نفّذ العمل).
- تأكيد الاستجابة برمز HTTP 200 سريع.
- 5xx/4xx/انتهاء المهلة ← إعادة محاولات بتأخير متزايد (تبدو كأنها رسائل مفقودة).
- لا تقم بعمل بطيء قبل الرد.
- قم بإرجاع 200، ثم قم بمعالجة DLR خارج مسار الطلب.
ليست مشكلة في Webhook، فالرسالة لم تُرسل نهائياً بعد.
لا يتم إرسال تقرير DLR إلا عند وصول الرسالة إلى حالة نهائية (DELIVRD أو UNDELIV). إذا كانت الرسالة لا تزال في قائمة الانتظار أو مُجدولة، فلا يوجد تقرير مطلوب بعد - وهذا أمر طبيعي، وليس عطلاً في Webhook. تأكد من الحالة الفعلية للرسالة بسحب الحالة (واجهة HTTP القديمة: /websmpp/websmsstatus) قبل استنتاج وجود عطل في Webhook، وقم بمطابقة التقارير باستخدام MessageId أو BatchId.
- لا تُرسَل تقارير DLR إلا عند الحالة النهائية (DELIVRD / UNDELIV).
- الرسائل التي في قائمة الانتظار أو المجدولة ليس لها تقرير DLR بعد.
- تحقق من الحالة الفعلية بسحبها (واجهة HTTP القديمة: /websmpp/websmsstatus) قبل إجراء المزيد من عمليات تصحيح الأخطاء.
- طابق التقارير بناءً على MessageId أو BatchId.