वेबहुक

वेबहुक, पार्टनर की ओर से तय किया गया यूआरएल होता है. इस यूआरएल पर RBM प्लैटफ़ॉर्म, मैसेज और इवेंट पोस्ट करता है. यह यूआरएल, एक ऐसे एंडपॉइंट के तौर पर काम करता है जिसे एचटीटीपीएस पोस्ट अनुरोध मिलते हैं. इन अनुरोधों में इवेंट के बारे में डेटा होता है. इसका मतलब है कि डेटा को आपके ऐप्लिकेशन पर सुरक्षित तरीके से HTTPS के ज़रिए भेजा जाता है.

वेबहुक यूआरएल कुछ ऐसा दिख सकता है: https://[your company name].com/api/rbm-events. वेबहुक को कॉन्फ़िगर करने के बाद, आपको मैसेज और इवेंट मिलने शुरू हो जाएंगे.

पार्टनर वेबहुक और एजेंट वेबहुक

वेबहुक को पार्टनर लेवल या एजेंट लेवल पर कॉन्फ़िगर किया जा सकता है.

  • आपका पार्टनर वेबहुक, आपके मैनेज किए जा रहे हर एजेंट पर लागू होता है. अगर आपके एजेंट एक जैसा व्यवहार करते हैं या आपके पास सिर्फ़ एक एजेंट है, तो पार्टनर वेबहुक का इस्तेमाल करें.
  • एजेंट वेबहुक, हर एजेंट पर अलग-अलग लागू होते हैं. अगर आपको अलग-अलग काम करने वाले कई एजेंट चलाने हैं, तो हर एजेंट के लिए अलग वेबहुक सेट किया जा सकता है.

अगर आपने पार्टनर वेबहुक और एजेंट वेबहुक, दोनों को कॉन्फ़िगर किया है, तो एजेंट वेबहुक को उसके एजेंट के लिए प्राथमिकता दी जाएगी. वहीं, पार्टनर वेबहुक उन एजेंटों पर लागू होगा जिनके पास अपना वेबहुक नहीं है.

एजेंट के वेबहुक को कॉन्फ़िगर करना

आपको अपने पार्टनर वेबहुक पर, एजेंट को भेजे गए मैसेज मिलते हैं. अगर आपको किसी एजेंट के मैसेज किसी दूसरे वेबहुक पर पाने हैं, तो एजेंट वेबहुक सेट करें.

  1. Business Communications डेवलपर कंसोल खोलें और RBM पार्टनर के Google खाते से साइन इन करें.
  2. अपने एजेंट पर क्लिक करें.
  3. इंटिग्रेशन पर क्लिक करें.
  4. वेबहुक के लिए, कॉन्फ़िगर करें पर क्लिक करें.
  5. वेबहुक एंडपॉइंट यूआरएल के लिए, "https://" से शुरू होने वाला वेबहुक यूआरएल डालें.
  6. अपनी clientToken वैल्यू नोट करें. इसकी ज़रूरत इसलिए होती है, ताकि यह पुष्टि की जा सके कि आपको मिले मैसेज Google से ही मिले हैं.

  7. अपने वेबहुक को कॉन्फ़िगर करें, ताकि वह बताए गए clientToken पैरामीटर के साथ POST अनुरोध स्वीकार कर सके. साथ ही, secret पैरामीटर की सादे टेक्स्ट वाली वैल्यू के साथ 200 OK जवाब भेज सके.

    उदाहरण के लिए, अगर आपके वेबुक को यह बॉडी कॉन्टेंट वाला 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. Developer Console में, पुष्टि करें पर क्लिक करें. जब RBM आपके वेबुक की पुष्टि कर लेता है, तो डायलॉग बंद हो जाता है.

आने वाले मैसेज की पुष्टि करना

वेबबुक किसी भी व्यक्ति से मैसेज पा सकते हैं. इसलिए, आपको यह पुष्टि करनी चाहिए कि Google ने मैसेज का कॉन्टेंट प्रोसेस करने से पहले, आने वाले मैसेज भेजे हैं.

इस बात की पुष्टि करने के लिए कि आपको मिला मैसेज Google ने भेजा है, यह तरीका अपनाएं:

  1. मैसेज के X-Goog-Signature हेडर को एक्सट्रैक्ट करें. यह मैसेज बॉडी पेलोड की हैश की गई, base64 कोड में बदली गई कॉपी है.
  2. अनुरोध के message.body एलिमेंट में मौजूद RBM पेलोड को Base-64-डिकोड करें.
  3. अपने वेबहुक के क्लाइंट टोकन (जिसे आपने वेबहुक सेट अप करते समय तय किया था) को कुंजी के तौर पर इस्तेमाल करके, base-64 डिकोड किए गए मैसेज पेलोड के बाइट का SHA512 HMAC बनाएं. इसके बाद, नतीजे को 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 से मिले जवाब, टाइमआउट या अपस्ट्रीम की गड़बड़ियां शामिल हैं. इन बातों का ध्यान रखें:

  • पुष्टि करें कि डीडीओएस से सुरक्षा देने वाली सुविधाएं, वेबहुक सूचनाओं की अनुमानित दर को मैनेज करने के लिए कॉन्फ़िगर की गई हैं.
  • पुष्टि करें कि डेटाबेस कनेक्शन पूल जैसे संसाधन खत्म न हों और टाइमआउट या 500 जवाब न दें.

डेवलपर को अपने सिस्टम इस तरह से डिज़ाइन करने चाहिए कि RBM इवेंट की प्रोसेसिंग एसिंक्रोनस तरीके से हो. साथ ही, इससे वेबुक को 200 OK वापस भेजने में कोई रुकावट न आए.

एसिंक्रोनस वेबहुक प्रोसेसिंग

यह ज़रूरी है कि वेबहुक में ही RBM इवेंट को प्रोसेस न किया जाए. प्रोसेसिंग के दौरान किसी भी तरह की गड़बड़ी या देरी से, वेबुक के रिटर्न कोड पर असर पड़ सकता है:

सिंक्रोनस वेबहुक प्रोसेसिंग

डिलीवरी में गड़बड़ी होने पर होने वाली कार्रवाई

जब RBM को वेबुक कॉल से 200 OK के अलावा कोई और जवाब मिलता है, तो वह बैकऑफ़ और फिर से कोशिश करने के तरीके का इस्तेमाल करता है. RBM, फिर से कोशिश करने के बीच के समय को ज़्यादा से ज़्यादा 600 सेकंड तक बढ़ा देगा. रीट्राई करने की प्रोसेस सात दिनों तक जारी रहेगी. इसके बाद, मैसेज डिलीवर नहीं किया जाएगा.

एजेंट-लेवल के वेबहुक के असर

RBM, किसी पार्टनर के लिए मैसेज को एक ही क्यू में रखता है. अगर कोई पार्टनर एजेंट-लेवल के वेबहुक का इस्तेमाल कर रहा है, तो यह ध्यान रखना ज़रूरी है कि किसी एक वेबहुक के काम न करने से, अन्य वेबहुक को सूचनाएं नहीं मिलेंगी. किसी मैसेज के डिलीवर न होने पर, बैकऑफ़ अवधि के दौरान अन्य एजेंट के वेबहुक कॉल किए जाएंगे. हालांकि, डिलीवरी नहीं हो पाने वाले मैसेज को फिर से भेजने के लिए, उन्हें कतार में रखा जाता है. इससे, डिलीवरी की कुल दरें कम हो जाएंगी और अन्य एजेंट पर इसका असर पड़ेगा.

डेवलपर के लिए यह समझना ज़रूरी है कि यह मॉडल कैसे काम करता है. साथ ही, इसके हिसाब से कोड करना ज़रूरी है. जहां तक हो सके, मैसेज स्वीकार करें और उन्हें प्रोसेस करने के लिए लाइन में लगाएं, ताकि गड़बड़ी होने की संभावना कम हो.

अगले चरण

वेबहुक कॉन्फ़िगर करने के बाद, आपका एजेंट मैसेज पा सकता है. ये मैसेज, आपके टेस्ट डिवाइसों से भेजे जाते हैं. सेटअप की पुष्टि करने के लिए, एक मैसेज भेजें.

आगे बढ़ें
Dialogflow