تشخيص الإعلامات التي تم إسقاطها في مراكز إعلام Azure

هل هذه الصفحة مفيدة؟

هل لديك ملاحظات إضافية؟

سيتم إرسال الملاحظات إلى Microsoft: بالضغط على الزر «إرسال»، سيتم استخدام ملاحظاتك لتحسين منتجات Microsoft وخدماتها. نهج الخصوصية.

هناك سؤال شائع حول مراكز إعلام Azure وهو كيفية استكشاف الأخطاء وإصلاحها عند عدم ظهور الإعلامات من أحد التطبيقات على الأجهزة العميلة. يريد العملاء معرفة أين ولماذا تم إسقاط الإشعارات وكيفية حل المشكلة. تحدد هذه المقالة سبب إسقاط الإشعارات أو عدم تلقيها بواسطة الأجهزة. كما يشرح كيفية تحديد السبب الجذري.

من الأهمية بمكان أن نفهم أولا كيف تدفع مراكز الإشعارات الإشعارات إلى الجهاز.

في تدفق إعلام الإرسال النموذجي، يتم إرسال الرسالة من الواجهة الخلفية للتطبيق إلى مراكز الإشعارات. تقوم مراكز الإشعارات بمعالجة جميع التسجيلات. يأخذ في الاعتبار العلامات التي تم تكوينها وتعبيرات العلامات لتحديد الأهداف. الأهداف هي التسجيلات التي تحتاج إلى تلقي إشعار الدفع. يمكن أن تمتد هذه التسجيلات عبر أي من منصاتنا المدعومة: Android و Baidu (أجهزة Android في الصين) و Fire OS (Amazon) iOS و Windows و Windows Phone.

مع تحديد الأهداف ، تدفع Notification Hubs الإشعارات إلى خدمة الإشعارات المباشرة للنظام الأساسي للجهاز. تتضمن الأمثلة خدمة إشعارات الدفع من Apple (APNs) لنظامي التشغيل iOS وmacOS، والمراسلة السحابية Firebase (FCM) لأجهزة Android. تدفع مراكز الإشعارات الإشعارات مقسمة عبر دفعات متعددة من التسجيلات. يتم مصادقته مع خدمة الإعلامات الدفعية المعنية، استنادا إلى بيانات الاعتماد التي قمت بتعيينها في مدخل Azure، ضمن تكوين مركز الإعلامات. ثم تقوم خدمة الإشعارات المباشرة بإعادة توجيه الإشعارات إلى الأجهزة العميلة المعنية.

تقع المرحلة الأخيرة من تسليم الإشعارات بين خدمة الإشعارات المباشرة للنظام الأساسي والجهاز. يمكن أن يفشل تسليم الإشعارات في أي من المراحل الأربع في عملية الإشعار الفوري (العميل ، النهاية الخلفية للتطبيق ، مراكز الإشعارات ، وخدمة الإشعارات المباشرة للنظام الأساسي). لمزيد من المعلومات حول بنية مراكز الإشعارات، راجع نظرة عامة على مراكز الإشعارات.

قد يحدث فشل في تسليم الإشعارات أثناء مرحلة الاختبار / التدريج الأولية. قد تشير الإشعارات التي تم إسقاطها في هذه المرحلة إلى وجود مشكلة في التكوين. في حالة حدوث فشل في تسليم الإشعارات أثناء الإنتاج، قد يتم إسقاط بعض الإشعارات أو جميعها. تتم الإشارة إلى مشكلة أعمق في التطبيق أو نمط المراسلة في هذه الحالة.

يبحث القسم التالي في السيناريوهات التي قد يتم فيها إسقاط الإشعارات، والتي تتراوح من شائعة إلى نادرة.

التكوين الخاطئ لمراكز الإشعارات

لإرسال إشعارات إلى خدمة الإشعارات المباشرة المعنية، يجب على مراكز الإشعارات مصادقة نفسها في سياق طلبك. يجب عليك إنشاء حساب مطور مع خدمة إشعارات النظام الأساسي المستهدف (Microsoft و Apple و Google وما إلى ذلك). بعد ذلك ، يجب عليك تسجيل تطبيقك مع نظام التشغيل حيث تحصل على رمز مميز أو مفتاح تستخدمه للعمل مع PNS المستهدف.

يجب إضافة بيانات اعتماد النظام الأساسي إلى مدخل Azure. إذا لم تصل أي إشعارات إلى الجهاز، فإن الخطوة الأولى هي التأكد من تكوين بيانات الاعتماد الصحيحة في مراكز الإشعارات. يجب أن تتطابق بيانات الاعتماد مع التطبيق الذي تم إنشاؤه ضمن حساب مطور خاص بالنظام الأساسي.

للحصول على إرشادات خطوة بخطوة لإكمال هذه العملية، راجع بدء استخدام مراكز إعلام Azure.

فيما يلي بعض التكوينات الخاطئة الشائعة للتحقق منها:

موقع اسم مركز الإشعارات

تأكد من أن اسم مركز الإشعارات (بدون أخطاء إملائية) هو نفسه في كل موقع من المواقع التالية:

• أين تقوم بالتسجيل من العميل
• مكان إرسال الإشعارات من الواجهة الخلفية
• المكان الذي قمت فيه بتكوين بيانات اعتماد خدمة الإعلامات الفورية

تأكد من استخدام سلاسل تكوين توقيع الوصول المشترك الصحيحة على العميل والواجهة الخلفية للتطبيق. بشكل عام ، يجب عليك استخدام DefaultListenSharedAccessSignature على العميل و DefaultFullSharedAccessSignature على الواجهة الخلفية للتطبيق. يمنح هذا أذونات لإرسال إشعارات إلى مراكز الإشعارات.

تكوين APN

يجب عليك الحفاظ على مركزين مختلفين: أحدهما للإنتاج والآخر للاختبار. يجب تحميل الشهادة التي تستخدمها في بيئة وضع الحماية إلى مركز منفصل عن الشهادة/الموزع الذي ستستخدمه في الإنتاج. لا تحاول تحميل أنواع مختلفة من الشهادات إلى المركز نفسه. سيؤدي ذلك إلى فشل الإشعارات.

إذا قمت عن غير قصد بتحميل أنواع مختلفة من الشهادات إلى نفس الموزع، فيجب حذف الموزع والبدء من جديد باستخدام مركز جديد. إذا لم تتمكن من حذف الموزع لسبب ما، فيجب عليك على الأقل حذف جميع التسجيلات الموجودة من الموزع.

تكوين FCM

1. تأكد من أن مفتاح الخادم الذي حصلت عليه من Firebase يطابق مفتاح الخادم الذي قمت بتسجيله في مدخل Azure.

   

2. تأكد من تكوين معرف Project على العميل. يمكنك الحصول على قيمة معرف Project من لوحة معلومات Firebase.

   

مشكلات التطبيق

العلامات وتعبيرات العلامات

إذا كنت تستخدم علامات أو تعبيرات علامات لتقسيم جمهورك، فمن المحتمل أنه عند إرسال الإشعار، لن يتم العثور على هدف. يستند هذا الخطأ إلى العلامات أو تعبيرات العلامات المحددة في مكالمة الإرسال.

راجع تسجيلاتك للتأكد من تطابق العلامات عند إرسال إشعار. ثم تحقق من إيصال الإشعار من العملاء الذين لديهم هذه التسجيلات فقط.

على سبيل المثال، افترض أن جميع تسجيلاتك في مراكز الإشعارات تستخدم العلامة "السياسة". إذا أرسلت بعد ذلك إشعارا يحمل العلامة "رياضة"، فلن يتم إرسال الإشعار إلى أي جهاز. قد تتضمن الحالة المعقدة تعبيرات العلامة حيث قمت بالتسجيل باستخدام "العلامة A" أو "العلامة B"، ولكنك استهدفت "العلامة A && العلامة B". يوضح لك قسم نصائح التشخيص الذاتي لاحقا في المقالة كيفية مراجعة تسجيلاتك وعلاماتها.

مشكلات القالب

إذا كنت تستخدم قوالب، فتأكد من اتباع الإرشادات الموضحة في القوالب.

التسجيلات غير الصالحة

إذا تم تكوين مركز الإعلام بشكل صحيح وتم استخدام العلامات أو تعبيرات العلامات بشكل صحيح، العثور على أهداف صالحة. وينبغي إرسال إخطارات إلى هذه الأهداف. ثم تقوم مراكز الإشعارات بإطلاق عدة دفعات معالجة بالتوازي. ترسل كل دفعة رسائل إلى مجموعة من التسجيلات.

ملاحظة

نظرا لأن مراكز الإشعارات تعالج الدفعات بالتوازي، فإن الترتيب الذي يتم به تسليم الإشعارات غير مضمون.

تم تحسين مراكز الإشعارات لنموذج تسليم الرسائل "مرة واحدة على الأكثر". نحاول إلغاء التكرار، بحيث لا يتم تسليم أي إشعارات أكثر من مرة إلى الجهاز. يتم التحقق من التسجيلات للتأكد من إرسال رسالة واحدة فقط لكل معرف جهاز قبل إرسالها إلى خدمة الإشعارات الفورية.

يتم إرسال كل دفعة إلى خدمة الإشعارات المباشرة ، والتي بدورها تقبل التسجيلات وتتحقق من صحتها. أثناء هذه العملية، من الممكن أن تكتشف خدمة الإعلامات المباشرة خطأ في تسجيل واحد أو أكثر في دفعة. ثم تقوم خدمة الإعلامات المباشرة بإرجاع خطأ إلى مراكز الإعلام، وتتوقف العملية. تقوم خدمة الإشعارات المباشرة بإسقاط هذه الدفعة تماما. هذا صحيح بشكل خاص مع APNs ، والتي تستخدم بروتوكول دفق TCP.

في هذه الحالة، تتم إزالة التسجيل المسبب للخطأ من قاعدة البيانات. بعد ذلك، نعيد محاولة تسليم الإشعارات لبقية الأجهزة في هذه الدفعة.

للحصول على مزيد من معلومات الخطأ حول محاولة التسليم الفاشلة ضد التسجيل، يمكنك استخدام واجهات برمجة تطبيقات REST لمراكز الإشعارات لكل رسالة القياس عن بعد: الحصول على القياس عن بعد لرسالة الإعلاموملاحظات PNS. للحصول على نموذج التعليمات البرمجية، راجع مثال إرسال REST.

مشاكل خدمة الإشعارات الفورية

بعد أن تتلقى خدمة الإشعارات المباشرة الإشعار ، فإنها تسلم الإشعار إلى الجهاز. في هذه المرحلة، لا تتحكم مراكز الإشعارات في تسليم الإشعار إلى الجهاز.

نظرا لأن خدمات إشعارات النظام الأساسي قوية ، تميل الإشعارات إلى الوصول إلى الأجهزة في بضع ثوان. إذا كانت خدمة الإشعارات المباشرة تختنق، تطبق مراكز الإشعارات استراتيجية التراجع الأسية. إذا ظلت خدمة الإشعارات المباشرة غير قابلة للوصول لمدة 30 دقيقة، فهناك سياسة معمول بها لانتهاء صلاحية الرسائل وإسقاطها نهائيا.

إذا حاولت خدمة إعلام الدفع تسليم إشعار ولكن الجهاز غير متصل بالإنترنت، تخزين الإشعار بواسطة خدمة الإعلامات الفورية. يتم تخزينه لفترة زمنية محدودة فقط. يتم تسليم الإشعار إلى الجهاز عندما يصبح الجهاز متاحا.

يخزن كل تطبيق إشعارا حديثا واحدا فقط. إذا تم إرسال إشعارات متعددة أثناء عدم اتصال أحد الأجهزة، يؤدي كل إشعار جديد إلى تجاهل الإشعار الأخير. يسمى الاحتفاظ بالإشعار الأحدث فقط التجميع في APNs والانهيار في FCM. (يستخدم FCM مفتاحا قابلا للطي.) عندما يظل الجهاز غير متصل بالإنترنت لفترة طويلة، يتم تجاهل الإشعارات التي تم تخزينها للجهاز. لمزيد من المعلومات، راجع نظرة عامة على APNsوحول رسائل FCM.

باستخدام "مراكز الإشعارات"، يمكنك تمرير مفتاح تجميع عبر رأس HTTP باستخدام واجهة برمجة تطبيقات SendNotification العامة. على سبيل المثال ، بالنسبة إلى .NET SDK ، يمكنك استخدام SendNotificationAsync. تأخذ واجهة برمجة تطبيقات SendNotification أيضا رؤوس HTTP التي يتم تمريرها كما هي إلى خدمة إعلام الدفع المعنية.

نصائح التشخيص الذاتي

فيما يلي مسارات لتشخيص السبب الجذري للإشعارات التي تم إسقاطها في مراكز الإشعارات.

التحقق من بيانات الاعتماد

بوابة مطور خدمة الإشعارات المباشرة

تحقق من بيانات الاعتماد في مدخل مطور خدمة إعلام الدفع المعني (APNs وFCM وخدمة الإشعارات Windows وما إلى ذلك). لمزيد من المعلومات، راجع البرنامج التعليمي: إرسال إعلامات إلى تطبيقات النظام الأساسي العام لـ Windows باستخدام مراكز إعلام Azure.

مدخل Azure

لمراجعة بيانات الاعتماد ومطابقتها مع تلك التي حصلت عليها من مدخل مطور خدمة إعلام الدفع، انتقل إلى علامة التبويب نهج الوصول في مدخل Azure.

التحقق من التسجيلات

Visual Studio

في Visual Studio، يمكنك الاتصال ب Azure من خلال مستكشف الخادم لعرض خدمات Azure المتعددة وإدارتها، بما في ذلك مراكز الإعلام. هذا الاختصار مفيد في المقام الأول لبيئة التطوير / الاختبار الخاصة بك.

يمكنك عرض وإدارة جميع التسجيلات في مركزك. يمكن تصنيف التسجيلات حسب النظام الأساسي أو التسجيل الأصلي أو القالب أو العلامة أو معرف خدمة الإشعارات المباشرة ومعرف التسجيل وتاريخ انتهاء الصلاحية. يمكنك أيضا تعديل تسجيل في هذه الصفحة. إنه مفيد بشكل خاص لتحرير العلامات.

انقر بزر الماوس الأيمن فوق مركز الإعلام في مستكشف الخادم، وحدد تشخيص.

تشاهد الصفحة التالية:

قم بالتبديل إلى صفحة تسجيلات الأجهزة :

يمكنك استخدام صفحة "إرسال اختبار" لإرسال رسالة إعلام اختبار:

ملاحظة

استخدم Visual Studio لتحرير التسجيلات فقط أثناء التطوير / الاختبار ، ومع عدد محدود من التسجيلات. إذا كنت بحاجة إلى تحرير تسجيلاتك بشكل مجمع، ففكر في استخدام وظيفة تسجيل التصدير والاستيراد الموضحة في كيفية: تصدير التسجيلات وتعديلها بشكل مجمع.

مستكشف Service Bus

يستخدم العديد من العملاء مستكشف ناقل الخدمة لعرض مراكز الإشعارات الخاصة بهم وإدارتها. مستكشف ناقل الخدمة هو مشروع مفتوح المصدر.

التحقق من إعلامات الرسائل

مدخل Azure

لإرسال إشعار اختبار إلى عملائك دون الحاجة إلى تشغيل خدمة مرة أخرى، ضمن الدعم + استكشاف الأخطاء وإصلاحها، حدد اختبار إرسال.

Visual Studio

يمكنك أيضا إرسال إشعارات الاختبار من Visual Studio.

لمزيد من المعلومات حول استخدام "مراكز الإعلامات" مع "مستكشف خادم Visual Studio"، راجع هذه المقالات:

• كيفية عرض تسجيلات الأجهزة لمراكز الإشعارات
• الغوص العميق: Visual Studio 2013 تحديث 2 RC و Azure SDK 2.3
• الإعلان عن إصدار التحديث 3 لعام 2013 Visual Studio و Azure SDK 2.4

تصحيح أخطاء الإشعارات الفاشلة ومراجعة نتائج الإشعارات

خاصية EnableTestSend

عند إرسال إشعار عبر مراكز الإشعارات، يتم وضع الإشعار في قائمة الانتظار في البداية. تحدد مراكز الإعلام الأهداف الصحيحة، ثم ترسل الإعلام إلى خدمة الإعلامات الفورية. إذا كنت تستخدم واجهة برمجة تطبيقات REST أو أي من مجموعات SDK الخاصة بالعميل، فإن إرجاع مكالمة الإرسال يعني فقط أن الرسالة في قائمة الانتظار مع مراكز الإشعارات. لا يوفر نظرة ثاقبة على ما حدث عندما أرسلت مراكز الإشعارات في النهاية الإشعار إلى خدمة الإشعارات الفورية.

إذا لم يصل الإشعار إلى الجهاز العميل، فقد يكون قد حدث خطأ عندما حاولت "مراكز الإشعارات" تسليمه إلى خدمة الإعلامات الفورية. على سبيل المثال، قد يتجاوز حجم الحمولة الصافية الحد الأقصى المسموح به من قبل خدمة الإعلامات الفورية، أو قد تكون بيانات الاعتماد التي تم تكوينها في مراكز الإشعارات غير صالحة.

للحصول على نظرة ثاقبة حول أخطاء خدمة الإعلامات الدفعية، يمكنك استخدام الخاصية EnableTestSend . يتم تمكين هذه الخاصية تلقائيا عند إرسال رسائل اختبار من البوابة الإلكترونية أو عميل Visual Studio. يمكنك استخدام هذه الخاصية للاطلاع على معلومات مفصلة عن تصحيح الأخطاء وأيضا عبر واجهات برمجة التطبيقات. حاليا ، يمكنك استخدامه في .NET SDK. سيتم إضافته إلى جميع مجموعات SDK الخاصة بالعميل في النهاية.

لاستخدام EnableTestSend الخاصية مع استدعاء REST، قم بإلحاق معلمة سلسلة استعلام تسمى Test بنهاية مكالمة الإرسال. على سبيل المثال:

https://mynamespace.servicebus.windows.net/mynotificationhub/messages?api-version=2013-10&test

مثال .NET SDK

فيما يلي مثال على استخدام .NET SDK لإرسال إعلام منبثق أصلي (منبثق):

NotificationHubClient hub = NotificationHubClient.CreateClientFromConnectionString(connString, hubName);
var result = await hub.SendWindowsNativeNotificationAsync(toast);
Console.WriteLine(result.State);

في نهاية التنفيذ ، result.State ببساطة الدول Enqueued. لا توفر النتائج أي نظرة ثاقبة حول ما حدث لإشعار الدفع.

بعد ذلك ، يمكنك استخدام الخاصية المنطقية EnableTestSend . استخدم الخاصية أثناء التهيئة EnableTestSendNotificationHubClient للحصول على حالة مفصلة حول أخطاء خدمة الإعلامات المباشرة التي تحدث عند إرسال الإعلام. تستغرق مكالمة الإرسال وقتا إضافيا للعودة لأنها تحتاج أولا إلى مراكز الإشعارات لتسليم الإشعار إلى خدمة الإشعارات الفورية.

    bool enableTestSend = true;
    NotificationHubClient hub = NotificationHubClient.CreateClientFromConnectionString(connString, hubName, enableTestSend);

    var outcome = await hub.SendWindowsNativeNotificationAsync(toast);
    Console.WriteLine(outcome.State);

    foreach (RegistrationResult result in outcome.Results)
    {
        Console.WriteLine(result.ApplicationPlatform + "\n" + result.RegistrationId + "\n" + result.Outcome);
    }

عينة الإخراج

DetailedStateAvailable
windows
7619785862101227384-7840974832647865618-3
The Token obtained from the Token Provider is wrong

تشير هذه الرسالة إما إلى أن بيانات الاعتماد التي تم تكوينها في مراكز الإشعارات غير صالحة أو أن هناك مشكلة في التسجيلات في الموزع. احذف هذا التسجيل واسمح للعميل بإعادة إنشاء التسجيل قبل إرسال الرسالة.

ملاحظة

EnableTestSend يتم خنق استخدام العقار بشدة. استخدم هذا الخيار فقط في بيئة التطوير / الاختبار ومع مجموعة محدودة من التسجيلات. يتم إرسال إشعارات تصحيح الأخطاء إلى 10 أجهزة فقط. هناك أيضا حد لمعالجة عمليات إرسال تصحيح الأخطاء ، بمعدل 10 في الدقيقة.

مراجعة القياس عن بعد

مدخل Azure

في البوابة الإلكترونية، يمكنك الحصول على نظرة عامة سريعة على جميع الأنشطة في مركز الإشعارات.

1. في علامة التبويب نظرة عامة ، يمكنك رؤية طريقة عرض مجمعة للتسجيلات والإشعارات والأخطاء حسب النظام الأساسي.

   

2. في علامة التبويب " جهاز العرض" ، يمكنك إضافة العديد من المقاييس الأخرى الخاصة بالنظام الأساسي للحصول على نظرة أعمق. يمكنك الاطلاع بشكل خاص على الأخطاء التي يتم إرجاعها عندما تحاول مراكز الإشعارات إرسال الإشعار إلى خدمة الإعلامات الفورية.

   

3. ابدأ بمراجعة الرسائل الواردةوعمليات التسجيلوالإشعارات الناجحة. بعد ذلك، انتقل إلى علامة التبويب لكل نظام أساسي لمراجعة الأخطاء الخاصة بخدمة الإعلامات الدفعية.

4. إذا كانت إعدادات المصادقة الخاصة بمركز الإعلام غير صحيحة، فستظهر الرسالة خطأ مصادقة PNS . إنه مؤشر جيد للتحقق من بيانات اعتماد خدمة الإشعارات الدفعية.

الوصول البرمجي

لمزيد من المعلومات حول الوصول البرمجي، راجع الوصول البرمجي.

ملاحظة

تتوفر العديد من الميزات المتعلقة بالقياس عن بعد، مثل تصدير واستيراد التسجيلات والوصول إلى القياس عن بعد عبر واجهات برمجة التطبيقات، فقط على مستوى الخدمة القياسية. إذا حاولت استخدام هذه الميزات من طبقة الخدمة المجانية أو الأساسية، فستتلقى رسالة استثناء إذا كنت تستخدم SDK. ستتلقى خطأ HTTP 403 (محظور) إذا كنت تستخدم الميزات مباشرة من واجهات برمجة تطبيقات REST.

لاستخدام الميزات المتعلقة بالقياس عن بعد، تأكد أولا في مدخل Azure من أنك تستخدم طبقة الخدمة القياسية.