التعديلات: يمكنك الاطّلاع على ملاحظات الإصدار للتعرّف على الميزات الجديدة وتحديثات المنتجات.

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

رابط البيانات المجمّعة هو عنوان URL يحدّده الشريك تنشر عليه منصة RBM الرسائل والأحداث. يعمل عنوان URL هذا كنقطة نهاية تتلقّى طلبات HTTPS POST التي تحتوي على بيانات عن الأحداث. ويعني ذلك أنّه يتم إرسال البيانات إلى تطبيقك بأمان عبر بروتوكول بروتوكول HTTPS.

قد يبدو عنوان URL للردّ التلقائي على الويب على النحو التالي: https://[your company name].com/api/rbm-events. بعد ضبط رابط webhook، يمكنك البدء في تلقّي الرسائل والأحداث.

الردود التلقائية على الويب للشركاء والردود التلقائية على الويب لموظّفي الدعم

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

ينطبق رمز شريك webhook على كل وكيل تحت إدارتك. إذا كان سلوك موظّفي الدعم مشابهًا، أو إذا كان لديك موظّف دعم واحد فقط، استخدِم مخطّط عمل شريك webhook.
تنطبق وحدات الردّ التلقائي على الويب للوكلاء على الوكلاء الفرديين. إذا كنت تدير موظّفي دعم متعدّدين بسلوك مختلف، يمكنك ضبط رابط ويب مختلف لكل موظّف دعم.

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

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

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

افتح Business Communications Developer Console وسجِّل الدخول باستخدام حسابك على Google الخاص بشريكك في ميزة "الرسائل التجارية".
انقر على موظّف الدعم.
انقر على عمليات الدمج.
بالنسبة إلى الردّ التلقائي على الويب، انقر على ضبط.
بالنسبة إلى عنوان URL لنقطة نهاية الردّ التلقائي على الويب، أدخِل عنوان URL للردّ التلقائي على الويب الذي يبدأ بعبارة "https://".
دوِّن قيمة clientToken. ستحتاج إلى ذلك من أجل التحقّق من أنّ الرسائل التي تتلقّاها واردة من Google.
عليك ضبط معلومات الردّ التلقائي على الويب لقبول طلب POST باستخدام المَعلمة clientToken المحدّدة وإرسال استجابة 200 OK تتضمّن قيمة النص العادي للمَعلمة secret كنص الاستجابة.

على سبيل المثال، إذا تلقّى رابط الويب الذي يستند إلى وحدات البرامج النصية طلب POST يتضمّن محتوى يليه:
```
{
  "clientToken":"SJENCPGJESMGUFPY",
  "secret":"1234567890"
}
```
بعد ذلك، من المفترض أن يؤكّد رابط البيانات في خدمة Webhook قيمة 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 للرسالة. هذه نسخة مجزّأة ومشفّرة بترميز base64 من الحمولة في نص الرسالة.
فك ترميز الحمولة في ميزة "الإعلانات المتجاوبة على شبكة البحث" باستخدام 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 من رابط ويب للطلبات ناتجًا عن تعذُّر تسليمه.

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

تأكَّد من ضبط وسائل الحماية من هجمات حجب الخدمة الموزّعة (DDoS) للتعامل مع المعدل المتوقّع للإشعارات الواردة من وحدات الردّ التلقائي على الويب.
تأكَّد من عدم نفاد الموارد، مثل مجموعات اتصالات قاعدة البيانات، وعدم حدوث مهلات أو ظهور استجابات 500.

على المطوّرين التأكّد من أنّ معالجة أحداث RBM تتم بشكل غير متزامن ولا تمنع webhook من عرض 200 OK.

معالجة وحدات ربط البيانات غير المتزامنة

من المهم عدم معالجة حدث RBM ضمن رابط البيانات في التطبيق نفسه. قد يؤثر أي خطأ أو تأخير أثناء المعالجة في رمز الإرجاع الخاص بخدمة ربط البيانات:

معالجة وحدات الربط المتزامنة

السلوك في حال تعذّر التسليم

يستخدم RBM آلية الانتظار وإعادة المحاولة عندما يتلقّى ردًا غير 200 OK من طلب webhook. ستزيد استراتيجية RBM من الوقت الذي تنتظره بين عمليات إعادة المحاولة إلى 600 ثانية كحد أقصى. وستستمر عمليات إعادة المحاولة لمدة 7 أيام، بعد ذلك سيتم تجاهل الرسالة.

تأثيرات الردود التلقائية على الويب على مستوى موظّف الدعم

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

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

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

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

Dialogflow