वेबहुक

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

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

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

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

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

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

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

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

  1. Business Communications डेवलपर कंसोल खोलें और RCS for Business के अपने पार्टनर 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 में, पुष्टि करें पर क्लिक करें. जब RCS for Business आपके वेबुक की पुष्टि कर लेता है, तब यह डायलॉग बंद हो जाता है.

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

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

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

  1. मैसेज के X-Goog-Signature हेडर को एक्सट्रैक्ट करें. यह मैसेज बॉडी पेलोड की हैश की गई, base64-एनकोडेड कॉपी है.
  2. अनुरोध के message.body एलिमेंट में मौजूद, RCS for Business के पेलोड को Base-64-decode करें.
  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 इवेंट को प्रोसेस न किया जाए. प्रोसेसिंग के दौरान किसी भी तरह की गड़बड़ी या देरी से, वेबुक के रिटर्न कोड पर असर पड़ सकता है:

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

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

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

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

RCS for Business, पार्टनर के लिए एक ही कतार में मैसेज रखता है. एक पार्टनर खाते के तहत काम करने वाले सभी एजेंट, एक ही कतार शेयर करते हैं. इस वजह से, एक वेबहुक के काम न करने पर पूरी कतार ब्लॉक हो सकती है. इससे सभी एजेंट के उपयोगकर्ता इवेंट, पार्टनर तक नहीं पहुंच पाते.

पुष्टि न किए गए कई मैसेज की वजह से, फिर से कोशिश करने वाले इवेंट में काफ़ी ज़्यादा बढ़ोतरी हो सकती है. उदाहरण के लिए, अगर कोई एजेंट 1,600 डिलीवरी रसीदों की पुष्टि नहीं करता है और फिर से कोशिश करने की फ़्रीक्वेंसी 10 मिनट की सीमा तक पहुंच जाती है, तो हर दिन करीब 2, 30,000 संभावित गड़बड़ियां जनरेट हो सकती हैं:

1,600 मैसेज × हर घंटे छह बार फिर से कोशिश करना × हर दिन 24 घंटे = हर दिन करीब 2,30,000 गड़बड़ियां

बार-बार किए जाने वाले अनुरोधों की वजह से, शेयर की गई Pub/Sub कतार ब्लॉक हो सकती है. साथ ही, पार्टनर के सभी कैंपेन के लिए उपयोगकर्ता इवेंट मिलने में काफ़ी देरी हो सकती है.

सबसे सही तरीके

अपने प्रोडक्शन ट्रैफ़िक को भरोसेमंद बनाने और कतार में लगने वाली समस्याओं से बचने के लिए, यहां दिए गए सबसे सही तरीके अपनाएं:

  • तुरंत 200 OK रिस्पॉन्स देना: वेबुक को मैसेज मिलना चाहिए, उसे लोकल क्यू में सेव करना चाहिए, और पांच सेकंड से कम समय में 200 OK रिस्पॉन्स देना चाहिए.
  • प्रोसेसिंग को अलग करना: लोकल क्यू से मैसेज लॉजिक को प्रोसेस करने के लिए, अलग-अलग बैकग्राउंड वर्कर का इस्तेमाल करें.
  • टेस्ट एजेंटों को मॉनिटर करें: डेवलपमेंट एजेंटों को प्रोडक्शन एजेंटों की तरह ही ट्रीट करें, क्योंकि अगर वे टेस्ट में पास नहीं होते हैं, तो वे शेयर की गई पार्टनर कतार को भी ब्लॉक कर सकते हैं.
  • जांच के लिए अलग खाते: हमारा सुझाव है कि प्रोडक्शन एजेंट के लिए एक डेवलपर खाते का इस्तेमाल करें. साथ ही, टेस्ट एजेंट के लिए अलग डेवलपर खाते का इस्तेमाल करें.
  • Google से मिले ट्रैफ़िक की पुष्टि करें: रिवर्स डीएनएस या X-Goog-Signature हेडर का इस्तेमाल करें. इसके बजाय, आईपी पते की अनुमति वाली सूची का इस्तेमाल न करें, क्योंकि Google डाइनैमिक एनीकास्ट आईपी पतों का इस्तेमाल करता है. मैन्युअल तरीके से पुष्टि करने और Google की आईपी रेंज की पहचान करने के बारे में ज़्यादा जानने के लिए, Google के अनुरोधों की पुष्टि करना दस्तावेज़ पढ़ें. साथ ही, उपयोगकर्ता से ट्रिगर होने वाले फ़ेचर और Google के उपयोगकर्ता से ट्रिगर होने वाले फ़ेचर के लिए, खास तौर पर JSON फ़ाइलें देखें.

अगले चरण

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

आगे बढ़ें
Dialogflow