वेबहुक

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

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

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

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

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

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

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

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

  1. RCS for Business डेवलपर कंसोल खोलें और RCS for Business पार्टनर के Google खाते से साइन इन करें.
  2. अपने एजेंट पर क्लिक करें.
  3. इंटिग्रेशन पर क्लिक करें.
  4. वेबहुक सेक्शन में, कॉन्फ़िगर करें पर क्लिक करें.

    1. वेबहुक एंडपॉइंट में, "https://" से शुरू होने वाला अपना वेबहुक यूआरएल डालें.
    2. क्लाइंट टोकन में, अपनी clientToken वैल्यू डालें. इसकी मदद से, यह पुष्टि की जाती है कि आपको मिलने वाले मैसेज, Google से आ रहे हैं.
  5. अपने वेबहुक को इस तरह सेट अप करें कि वह clientToken और secret पैरामीटर वाले JSON पेलोड के साथ POST अनुरोध स्वीकार करे.

    {
      "clientToken":"YOURCLIENTTOKEN",
      "secret":"YOURSECRET"
    }
    

    अनुरोध की पुष्टि करने के लिए, आपके एंडपॉइंट को जवाब के मुख्य हिस्से में, secret पैरामीटर की रॉ स्ट्रिंग वैल्यू के साथ एचटीटीपी 200 OK स्टेटस कोड दिखाना होगा.

    वेबहुक कॉन्फ़िगरेशन का सैंपल

    उदाहरण के लिए, अगर आपके वेबहुक को, मुख्य हिस्से में मौजूद इस कॉन्टेंट के साथ POST अनुरोध मिलता है:

      {
      "clientToken":"YOURCLIENTTOKEN",
      "secret":"YOURSECRET"
      }
      

    इसके बाद, आपके वेबहुक को clientToken वैल्यू की पुष्टि करनी चाहिए. साथ ही, अगर clientToken सही है, तो जवाब के मुख्य हिस्से में YOURSECRET के साथ 200 OK जवाब दिखाना चाहिए:

      // clientToken from Configure
      const myClientToken = "YOURCLIENTTOKEN";
    
      // Example endpoint
      app.post("/rbm-webhook", (req, res) => {
        // Use the X-Goog-Webhook-Type header to route requests
        const webhookType = req.header('X-Goog-Webhook-Type');
    
        if (webhookType === 'verification') {
          const msg = req.body;
          if (msg.clientToken === myClientToken) {
              res.status(200).send(msg.secret);
              return;
          }
        }
        res.send(400);
        // Handle other webhook types
      });
      
  6. डेवलपर कंसोल में, **पुष्टि करें** पर क्लिक करें. पुष्टि करें पर क्लिक करने के बाद, Google आपके वेबहुक को POST का अनुरोध भेजता है. इसमें clientToken और secret, पैरामीटर के तौर पर शामिल होते हैं. जब RCS for Business, आपके वेबहुक की पुष्टि कर लेता है, तो डायलॉग बंद हो जाता है.

अनुरोध के टाइप की पहचान करना

अपने वेबहुक पर आने वाले सभी अनुरोधों के टाइप की पहचान करने के लिए, X-Goog-Webhook-Type हेडर का इस्तेमाल करें.

हेडर में ये वैल्यू हो सकती हैं:

  • verification: इसका इस्तेमाल, शुरुआती एंडपॉइंट की पुष्टि की प्रोसेस के लिए किया जाता है.
  • message_callback: इसका इस्तेमाल, मैसेज से जुड़े इवेंट के लिए किया जाता है. जैसे, टाइपिंग या डिलीवरी की सूचनाएं और उपयोगकर्ताओं से आने वाले मैसेज.
  • agent_callback: इसका इस्तेमाल, एजेंट से जुड़े एडमिन इवेंट के लिए किया जाता है. जैसे, एजेंट के लॉन्च की स्थिति में बदलाव.

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

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

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

  1. मैसेज का X-Goog-Signature हेडर एक्सट्रैक्ट करें. यह, मैसेज के मुख्य हिस्से के पेलोड की हैश की गई, base64 कोड में बदली गई कॉपी होती है.
  2. अनुरोध के message.body एलिमेंट में, RCS for Business के पेलोड को 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
    const headerHash = req.header('X-Goog-Signature');
    const userEventString = Buffer.from(requestBody.message.data, 'base64');
    const hmac = crypto.createHmac('sha512', myClientToken);
    const genHash = hmac.update(userEventString).digest('base64');

    if (headerHash === genHash) {
      const userEvent = JSON.parse(userEventString);
      const webhookType = req.header('X-Goog-Webhook-Type');

      // Route based on the header type
      if (webhookType === 'message_callback') {
        handleMessage(userEvent);
      } else if (webhookType === 'agent_callback') {
        handleAgentEvent(userEvent);
      }
    } else {
      console.log('Hash mismatch - ignoring message');
      res.sendStatus(401);
      return;
    }
  }

  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 मैसेज × हर घंटे में 6 बार फिर से कोशिश करना × हर दिन 24 घंटे = हर दिन करीब 2,30,000 गड़बड़ियां

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

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

अपने प्रोडक्शन ट्रैफ़िक की विश्वसनीयता को सुरक्षित रखने और क्यू ब्लॉक करने से बचने के लिए, इन सबसे सही तरीकों को अपनाएं:

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

अगले चरण

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