رابط البيانات المجمّعة هو طلب استدعاء HTTPS ينشئه الشريك ويحدّد كيفية ردّ موظّف الدعم على الرسائل والأحداث. بعد ضبط الردّ التلقائي على الويب، يمكنك البدء في تلقّي الرسائل والأحداث.
الردود التلقائية على الويب للشركاء والردود التلقائية على الويب لموظّفي الدعم
يمكنك ضبط الردّ التلقائي على الويب إمّا على مستوى الشريك أو على مستوى العميل .
- ينطبق رمز شريك webhook على كل وكيل تحت إدارتك. إذا كان سلوك موظّفي الدعم مشابهًا، أو إذا كان لديك موظّف دعم واحد فقط، استخدِم مخطّط عمل شريك webhook.
- تنطبق وحدات الردّ التلقائي على الويب للوكلاء على الوكلاء الفرديين. إذا كنت تدير عدة وكلاء لديهم سلوك مختلف، يمكنك ضبط ردّ تلقائي مختلف على الويب لكل وكيل.
إذا أعددت ردًّا تلقائيًا على الويب للشريك وردًّا تلقائيًا على الويب لموظّف الدعم، سيُمنَح ردّ التلقائي على الويب الخاص بموظّف الدعم الأولوية على موظّف الدعم المحدّد، بينما ينطبق ردّ التلقائي على الويب الخاص بالشريك على أي موظّفي دعم ليس لديهم ردّ تلقائي على الويب خاص بهم.
ضبط رابط الردّ التلقائي على الويب المخصَّص للوكيل
ستتلقّى الرسائل المُرسَلة إلى موظّف الدعم في ردّ تلقائي على الويب الخاص بالشريك. إذا كنت تريد توجيه الرسائل إلى موظّف دعم معيّن إلى ميزة الردّ التلقائي على الويب مختلفة بدلاً من ذلك، يمكنك ضبط ميزة الردّ التلقائي على الويب لموظّف الدعم.
- افتح Business Communications Developer Console وسجِّل الدخول باستخدام حسابك على Google الخاص بشريكك في برنامج "الإعلانات على شبكة البحث".
- انقر على موظّف الدعم.
- انقر على عمليات الدمج.
- بالنسبة إلى رابط الردّ التلقائي على الويب، انقر على ضبط.
- بالنسبة إلى عنوان URL لنقطة نهاية الردّ التلقائي على الويب، أدخِل عنوان URL للردّ التلقائي على الويب الذي يبدأ بعبارة "https://".
- دوِّن قيمة
clientToken
. ستحتاج إلى ذلك من أجل التحقّق من أنّ الرسائل التي تتلقّاها واردة من Google. اضبط الرد التلقائي على الويب لقبول طلب
POST
مع معلَمةclientToken
المحددة وإرسال استجابة200 OK
مع قيمة النص العادي للمعلَمةsecret
كنص للاستجابة.على سبيل المثال، إذا تلقّى رابط الويب الذي يتلقّى إشاراتك طلب
POST
يتضمّن محتوى يليه:{ "clientToken":"SJENCPGJESMGUFPY", "secret":"1234567890" }
بعد ذلك، من المفترض أن يؤكّد رابط البيانات في خدمة ويب قيمة
clientToken
، وإذا كانتclientToken
صحيحة، أن يعرض الردّ200 OK
مع1234567890
كأحد عناصر الردّ:// clientToken from Configure const myClientToken = "SJENCPGJESMGUFPY"; // Example endpoint app.post("/rbm-webhook", (req, res) => { const msg = req.body; if (msg.clientToken === myClientToken) { res.status(200).send(msg.secret); return; } res.send(400); });
في Developer Console، انقر على إثبات الملكية. عندما يتحقّق "نظام إدارة الأداء من Google" من صحة مخطّط عمل الويب، يتم إغلاق مربّع الحوار.
التحقّق من الرسائل الواردة
بما أنّ وحدات الربط بالويب يمكنها تلقّي رسائل من أي مُرسِلين، عليك التأكّد من أنّ Google أرسلت الرسائل الواردة قبل معالجة محتوى الرسالة.
للتأكّد من أنّ Google أرسلت رسالة تلقّيتها، اتّبِع الخطوات التالية:
- استخرِج عنوان
X-Goog-Signature
للرسالة. هذه نسخة مجزّأة مجزّأة من حمولة نص الرسالة الأساسية - فك ترميز الحمولة في ميزة "الإعلانات المتجاوبة على شبكة البحث" باستخدام Base-64 في عنصر
message.body
من الطلب. - باستخدام رمز مميّز لعميل webhook (الذي حدّدته عند إعداد webhook) كمفتاح، أنشئ دالة SHA512 HMAC من البايتات لحمولة الرسالة التي تم فك ترميزها باستخدام ترميز base-64 وقم بترميز النتيجة باستخدام ترميز base64.
- قارِن بين تجزئة
X-Goog-Signature
والتجزئة التي أنشأتها.- إذا تطابقت التجزئات، يعني ذلك أنّك أكّدت أنّ Google أرسلت الرسالة.
إذا لم تتطابق التجزئات، تحقَّق من عملية التجزئة على رسائل معروفة بأنّها صالحة.
إذا كانت عملية التجزئة تعمل بشكل صحيح وتلقّيت رسالة تعتقد أنّها تم إرسالها عن طريق الاحتيال، يُرجى التواصل معنا.
Node.js
if ((requestBody.hasOwnProperty('message')) && (requestBody.message.hasOwnProperty('data'))) { // Validate the received hash to ensure the message came from Google RBM let userEventString = Buffer.from(requestBody.message.data, 'base64'); let hmac = crypto.createHmac('sha512', CLIENT_TOKEN); let data = hmac.update(userEventString); let genHash = data.digest('base64'); let headerHash = req.header('X-Goog-Signature'); if (headerHash === genHash) { let userEvent = JSON.parse(userEventString); console.log('userEventString: ' + userEventString); handleMessage(userEvent); } else { console.log('hash mismatch - ignoring message'); } } res.sendStatus(200);
معالجة الرسائل
يُعتبَر عرض أيّ قيمة غير 200 OK
من رابط ويب للطلبات خطأ في التسليم.
يجب أن يدرك المطوّرون أنّ إرسال الرسائل بمعدّلات عالية سيؤدي إلى إنشاء إشعارات للردّ التلقائي على الويب بمعدّلات عالية، ويجب تصميم الرموز البرمجية لضمان قدرتهم على استهلاك الإشعارات بالمعدّل المتوقّع. من المهم أن يأخذ المطوّرون في الاعتبار الحالات التي قد تؤدي إلى حدوث إخفاق، بما في ذلك استجابات 500
من حاويتهم على الويب أو انتهاء المهلة أو عمليات تعذُّر تحميل الصفحة. تشمل الأشياء التي
يجب مراعاتها ما يلي:
- تأكّد من ضبط إجراءات الحماية ضد هجمات حجب الخدمة الموزّعة (DDoS) للتعامل مع المعدل المتوقّع لإشعارات الردّ التلقائي على الويب.
- يمكنك التأكّد من عدم نفاد الموارد مثل مجموعات اتصال قاعدة البيانات، ومن حدوث مهلات أو ردود
500
.
السلوك عند تعذُّر التسليم
تستخدم ميزة RBM آلية التراجع وإعادة المحاولة عندما تتلقّى ردًّا غير 200 OK
من استدعاء ردّ تلقائي على الويب. ستزيد استراتيجية RBM من الوقت الذي تنتظره بين
عمليات إعادة المحاولة إلى 600 ثانية كحد أقصى. وستستمر عمليات إعادة المحاولة لمدة 7 أيام،
بعد ذلك سيتم تجاهل الرسالة.
تأثيرات الردود التلقائية على الويب على مستوى موظّف الدعم
تُضيف ميزة "إدارة الطلبات في الوقت الفعلي" الرسائل إلى قائمة انتظار واحدة للشريك. عندما يستخدم الشريك عناوين webhook على مستوى موظّف الدعم، من المهم أن يضع في اعتباره أنّ تعذُّر إرسال عناوين webhook سيؤثّر في إرسالها إلى عناوين webhook الأخرى. سيتمّ استدعاء وحدات الردّ التلقائي على الويب التي تنتمي إلى موظّفي دعم آخرين خلال فترة الانتظار لرسالة تعذّر إرسالها. ومع ذلك، عندما يتم وضع الرسائل التي تعذّر إرسالها في قائمة الانتظار لإعادة المحاولة، ستنخفض معدّلات التسليم الإجمالية وسيتأثّر موظّفو الدعم الآخرون.
من المهم أن يفهم المطوّرون هذا النموذج ويكتبوا الرمز البرمجي وفقًا لذلك، ما أمكن، من خلال قبول الرسائل ووضعها في قائمة الانتظار لمعالجتها بهدف minimize تقليل فرصة ظهور خطأ.
الخطوات التالية
بعد ضبط رابط البيانات في الخادم، يمكن لوكيل الدعم تلقّي الرسائل من أجهزتك الاختبارية. أرسِل رسالة للتحقّق من عملية الإعداد.