الردّ التلقائي على الويب

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

الردود التلقائية على الويب الخاصة بالشركاء والردّات التلقائية على الويب للوكلاء

يمكنك ضبط الردّ التلقائي على الويب إما على مستوى الشريك أو على مستوى الوكيل.

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

ضبط ردّ تلقائي على الويب للوكيل

ستتلقّى الرسائل المُرسَلة إلى وكيلك في الردّ التلقائي على الويب الخاص بالشريك. إذا كنت تريد أن تصل الرسائل الخاصة بوكيل معيّن إلى ردّ تلقائي مختلف على الويب بدلاً من ذلك، يمكنك ضبط ردّ تلقائي على الويب للوكيل.

  1. افتح وحدة تحكُّم مطوّري برامج Business Communications وسجِّل الدخول باستخدام حساب Google لشريك RBM.
  2. انقر على وكيلك.
  3. انقر على عمليات الدمج.
  4. بالنسبة إلى الردّ التلقائي على الويب، انقر على ضبط.
  5. بالنسبة إلى عنوان URL لنقطة نهاية الردّ التلقائي على الويب، أدخِل عنوان URL للردّ التلقائي على الويب يبدأ بـ "https://".
  6. سجِّل قيمة clientToken. وستحتاج إليه للتحقّق من أنّ الرسائل التي تتلقّاها واردة من Google.

  7. اضبط الرد التلقائي على الويب لقبول طلب 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);
});

  8. في Play Console، انقر على إثبات الملكية. عندما تتحقّق ميزة RBM من الردّ التلقائي على الويب، يتم إغلاق مربّع الحوار.

التحقّق من الرسائل الواردة

بما أنّ الردود التلقائية على الويب يمكن أن تتلقّى رسائل من أي مُرسِلين، عليك التأكّد من أنّ Google أرسلت الرسائل الواردة قبل معالجة محتوى الرسالة.

لإثبات أنّ Google أرسلت رسالة تلقّيتها، اتّبِع الخطوات التالية:

  1. استخرِج عنوان X-Goog-Signature للرسالة. هذه نسخة مجزأة مجزّأة من حمولة نص الرسالة الأساسية
  2. يعمل Base-64 على فك ترميز حمولة RBM في العنصر message.body للطلب.
  3. باستخدام الرمز المميّز لعميل الردّ التلقائي على الويب (الذي حدّدته عند إعداد الردّ التلقائي على الويب) كمفتاح، عليك إنشاء SHA512 HMAC من وحدات البايت الخاصة بحمولة الرسالة base-64 التي تم فك ترميزها وترميز base64 للنتيجة.
  4. قارِن بين تجزئة 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 أيام، وسيتم تجاهل الرسالة بعد ذلك.

الآثار المترتبة على الردود التلقائية على الويب على مستوى الوكيل

يضع RBM الرسائل في قائمة انتظار لأحد الشركاء. عندما يستخدم الشريك الردود التلقائية على الويب على مستوى الوكيل، من المهم مراعاة أنّ تعذُّر الردّ التلقائي على الويب سيؤثر في التسليم إلى الردود التلقائية الأخرى على الويب. سيتم استدعاء الردود التلقائية على الويب التي تخصّ الوكلاء الآخرين أثناء فترة الركود لرسالة فاشلة، ولكن مع إدراج الرسائل التي أخفقت في قائمة انتظار لإعادة المحاولة، ستنخفض معدلات التسليم الإجمالية وسيتأثر الوكلاء الآخرون.

من المهم أن يفهم المطوّرون هذا النموذج والرمز البرمجي وفقًا لذلك، وأن يقبلوا الرسائل ويوضعوها في قائمة انتظار لمعالجتها لتقليل فرصة حدوث عطل.

الخطوات التالية

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