এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

ওয়েবহুক

ওয়েবহুক হলো পার্টনার-নির্দিষ্ট একটি ইউআরএল, যেখানে RCS for Business প্ল্যাটফর্ম মেসেজ এবং ইভেন্ট পোস্ট করে। এই ইউআরএলটি একটি এন্ডপয়েন্ট হিসেবে কাজ করে, যা ইভেন্ট সম্পর্কিত ডেটা সম্বলিত HTTPS POST রিকোয়েস্ট গ্রহণ করে। এর মানে হলো, ডেটা HTTPS-এর মাধ্যমে নিরাপদে আপনার অ্যাপ্লিকেশনে পাঠানো হয়।

একটি ওয়েবহুক ইউআরএল দেখতে এইরকম হতে পারে: https://[your company name].com/api/rbm-events । আপনার ওয়েবহুক কনফিগার করার পর, আপনি মেসেজ এবং ইভেন্ট গ্রহণ করা শুরু করতে পারেন।

পার্টনার ওয়েবহুক এবং এজেন্ট ওয়েবহুক

আপনি আপনার ওয়েবহুকটি পার্টনার লেভেলে অথবা এজেন্ট লেভেলে কনফিগার করতে পারেন।

আপনার পার্টনার ওয়েবহুক আপনার রক্ষণাবেক্ষণ করা প্রতিটি এজেন্টের জন্য প্রযোজ্য। যদি আপনার এজেন্টগুলোর আচরণ একই রকম হয়, অথবা যদি আপনার কেবল একটি এজেন্ট থাকে, তাহলে পার্টনার ওয়েবহুকটি ব্যবহার করুন।
এজেন্ট ওয়েবহুকগুলো প্রতিটি এজেন্টের জন্য আলাদাভাবে প্রযোজ্য। যদি আপনি ভিন্ন ভিন্ন আচরণবিশিষ্ট একাধিক এজেন্ট পরিচালনা করেন, তবে প্রতিটি এজেন্টের জন্য আলাদা ওয়েবহুক সেট করতে পারেন।

যদি আপনি একটি পার্টনার ওয়েবহুক এবং একটি এজেন্ট ওয়েবহুক উভয়ই কনফিগার করে থাকেন, তাহলে এজেন্ট ওয়েবহুকটি তার নির্দিষ্ট এজেন্টের ক্ষেত্রে অগ্রাধিকার পাবে, অন্যদিকে পার্টনার ওয়েবহুকটি সেইসব এজেন্টের ক্ষেত্রে প্রযোজ্য হবে যাদের নিজস্ব ওয়েবহুক নেই।

একটি এজেন্ট ওয়েবহুক কনফিগার করুন

আপনার এজেন্টের কাছে পাঠানো বার্তাগুলো আপনি আপনার পার্টনার ওয়েবহুকে গ্রহণ করেন। যদি আপনি চান যে কোনো নির্দিষ্ট এজেন্টের জন্য বার্তাগুলো এর পরিবর্তে একটি ভিন্ন ওয়েবহুকে আসুক, তাহলে একটি এজেন্ট ওয়েবহুক সেট করুন।

RCS for Business ডেভেলপার কনসোলটি খুলুন এবং আপনার RCS for Business পার্টনার গুগল অ্যাকাউন্ট দিয়ে সাইন ইন করুন।
আপনার এজেন্টকে ক্লিক করুন।
ইন্টিগ্রেশন-এ ক্লিক করুন।
ওয়েবহুক বিভাগে, কনফিগার- এ ক্লিক করুন।
1. Webhook endpoint- এ, "https://" দিয়ে শুরু করে আপনার ওয়েবহুক URL লিখুন।
2. ক্লায়েন্ট টোকেন- এ আপনার clientToken ভ্যালুটি উল্লেখ করুন। আপনি যে মেসেজগুলো পাচ্ছেন, সেগুলো গুগল থেকেই আসছে কিনা তা যাচাই করার জন্য এটি প্রয়োজন।
দ্রষ্টব্য: নিরাপত্তাজনিত কারণে আপনার বর্তমান ক্লায়েন্ট টোকেন প্রদর্শন করা সম্ভব নয়। একটি নতুন ক্লায়েন্ট টোকেন তৈরি করতে, সংশ্লিষ্ট ফিল্ডে একটি মান লিখুন অথবা একটি র‍্যান্ডম মান তৈরি করার জন্য -এ ক্লিক করুন।
আপনার ওয়েবহুকটি এমনভাবে সেট আপ করুন যাতে এটি clientToken এবং secret প্যারামিটারসহ একটি JSON পেলোডযুক্ত POST রিকোয়েস্ট গ্রহণ করতে পারে।
```
{
  "clientToken":"YOURCLIENTTOKEN",
  "secret":"YOURSECRET"
}
```
অনুরোধটি যাচাই করার জন্য, আপনার এন্ডপয়েন্টকে অবশ্যই একটি HTTP 200 OK স্ট্যাটাস কোড এবং রেসপন্স বডিতে secret প্যারামিটারের র স্ট্রিং ভ্যালু ফেরত দিতে হবে।
নমুনা ওয়েবহুক কনফিগারেশন
উদাহরণস্বরূপ, যদি আপনার ওয়েবহুক নিম্নলিখিত বডি কন্টেন্ট সহ একটি 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
  });
  
```
ডেভেলপার কনসোলে , 'ভেরিফাই' বোতামে ক্লিক করুন। 'ভেরিফাই' বোতামে ক্লিক করার পর, গুগল আপনার ওয়েবহুকে একটি POST রিকোয়েস্ট পাঠায়, যার বডিতে প্যারামিটার হিসেবে clientToken এবং secret অন্তর্ভুক্ত থাকে। যখন RCS for Business আপনার ওয়েবহুকটি যাচাই করে, তখন ডায়ালগ বক্সটি বন্ধ হয়ে যায়।

অনুরোধের ধরণ শনাক্ত করুন

আপনার ওয়েবহুকে আসা সমস্ত অনুরোধের ধরন শনাক্ত করতে, X-Goog-Webhook-Type হেডারটি ব্যবহার করুন।

হেডারে নিম্নলিখিত মানগুলি থাকতে পারে:

verification : প্রাথমিক এন্ডপয়েন্ট যাচাইকরণ প্রক্রিয়ার জন্য ব্যবহৃত হয়।
message_callback : বার্তা-সম্পর্কিত ইভেন্টগুলির জন্য ব্যবহৃত হয়, যেমন টাইপিং বা ডেলিভারি নোটিফিকেশন এবং ব্যবহারকারীদের কাছ থেকে আগত বার্তা।
agent_callback : এজেন্ট-নির্দিষ্ট প্রশাসনিক ইভেন্টের জন্য ব্যবহৃত হয়, যেমন এজেন্টের লঞ্চ অবস্থার পরিবর্তন।

আগত বার্তা যাচাই করুন

যেহেতু ওয়েবহুক যেকোনো প্রেরকের কাছ থেকে বার্তা গ্রহণ করতে পারে, তাই বার্তার বিষয়বস্তু প্রক্রিয়াকরণ করার আগে আপনার যাচাই করে নেওয়া উচিত যে আগত বার্তাটি গুগলই পাঠিয়েছে।

আপনি যে বার্তাটি পেয়েছেন তা গুগল পাঠিয়েছে কিনা তা যাচাই করতে, এই ধাপগুলো অনুসরণ করুন:

মেসেজটির X-Goog-Signature হেডারটি বের করুন। এটি হলো মেসেজ বডি পেলোডের একটি হ্যাশ করা ও বেস৬৪-এনকোডেড কপি।
অনুরোধের message.body এলিমেন্টে থাকা RCS for Business পেলোডটিকে Base-64 ডিকোড করুন।
আপনার ওয়েবহুকের ক্লায়েন্ট টোকেনকে (যা আপনি ওয়েবহুক সেট আপ করার সময় নির্দিষ্ট করেছিলেন) কী (key) হিসাবে ব্যবহার করে, বেস-৬৪ ডিকোড করা মেসেজ পেলোডের বাইটগুলোর একটি SHA512 HMAC তৈরি করুন এবং ফলাফলটিকে বেস-৬৪ এনকোড করুন।
X-Goog-Signature হ্যাশটির সাথে আপনার তৈরি করা হ্যাশটি তুলনা করুন।
- হ্যাশগুলো মিলে গেলে, আপনি নিশ্চিত হয়েছেন যে বার্তাটি গুগলই পাঠিয়েছে।
- যদি হ্যাশগুলো না মেলে, তাহলে একটি নিশ্চিত ও সঠিক মেসেজের উপর আপনার হ্যাশিং প্রক্রিয়াটি পরীক্ষা করে দেখুন।
  যদি আপনার হ্যাশিং প্রক্রিয়া সঠিকভাবে কাজ করে এবং আপনি এমন কোনো বার্তা পান যা আপনার মতে প্রতারণামূলকভাবে পাঠানো হয়েছে, তাহলে আমাদের সাথে যোগাযোগ করুন ।

নোড.জেএস

  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 প্ল্যাটফর্মটি ডেটা পুনরায় ডেলিভারি করার জন্য একটি ব্যাকঅফ এবং রিট্রাই প্রক্রিয়া ব্যবহার করে। এর মানে হলো, সিস্টেমটি প্রতিটি ডেলিভারি চেষ্টার মধ্যেকার বিলম্ব ক্রমান্বয়ে বাড়াতে থাকে এবং অবশেষে প্রতিটি অপেক্ষমান বার্তার জন্য প্রতি ১০ মিনিটে একবার রিট্রাই করার সর্বোচ্চ পর্যায়ে পৌঁছায়। এই রিট্রাই চক্রটি সাত দিন ধরে চলতে থাকে, যার পরে বার্তাটি স্থায়ীভাবে মুছে ফেলা হয়।

এজেন্ট-স্তরের ওয়েবহুকের প্রভাব

RCS for Business একজন পার্টনারের জন্য মেসেজগুলোকে একটিমাত্র কিউতে সাজিয়ে রাখে। একটিমাত্র পার্টনার অ্যাকাউন্টের অধীনে থাকা সমস্ত এজেন্ট একটিমাত্র কিউ ব্যবহার করে। এই কারণে, একটি ওয়েবহুকে কোনো ত্রুটি দেখা দিলে তা পুরো কিউটিকে ব্লক করে দিতে পারে, ফলে সমস্ত এজেন্টের ইউজার ইভেন্ট পার্টনারের কাছে পৌঁছাতে পারে না।

একাধিক স্বীকৃতিহীন বার্তা পুনরায় চেষ্টার সংখ্যায় ব্যাপক বৃদ্ধি ঘটাতে পারে। উদাহরণস্বরূপ, যদি একজন এজেন্ট ১,৬০০টি ডেলিভারি প্রাপ্তি স্বীকার না করেন এবং পুনরায় চেষ্টার হার ১০-মিনিটের সীমায় পৌঁছে যায়, তবে এর ফলে প্রতিদিন আনুমানিক ২,৩০,০০০ সম্ভাব্য ত্রুটি তৈরি হতে পারে:

১,৬০০টি বার্তা × প্রতি ঘণ্টায় ৬ বার পুনঃপ্রচেষ্টা × দিনে ২৪ ঘণ্টা = প্রতিদিন আনুমানিক ২,৩০,০০০টি ত্রুটি

এই বিপুল সংখ্যক পুনঃপ্রচেষ্টার কারণে শেয়ার করা পাব/সাব কিউ ব্লক হয়ে যেতে পারে এবং এর ফলে কোনো পার্টনারের সমস্ত ক্যাম্পেইনের জন্য ব্যবহারকারীর ইভেন্ট পেতে উল্লেখযোগ্য বিলম্ব হতে পারে।

সর্বোত্তম অনুশীলন

আপনার প্রোডাকশন ট্র্যাফিকের নির্ভরযোগ্যতা নিশ্চিত করতে এবং কিউ ব্লকার এড়াতে, এই সর্বোত্তম অনুশীলনগুলি অনুসরণ করুন:

অবিলম্বে 200 OK ফেরত দিন : ওয়েবহুকটি বার্তাটি গ্রহণ করে, সেটিকে একটি স্থানীয় কিউ-তে সংরক্ষণ করবে এবং পাঁচ সেকেন্ডের মধ্যে একটি 200 OK প্রতিক্রিয়া ফেরত দেবে।
প্রসেসিং বিচ্ছিন্ন করুন : লোকাল কিউ থেকে মেসেজ লজিক প্রসেস করার জন্য আলাদা ব্যাকগ্রাউন্ড ওয়ার্কার ব্যবহার করুন।
টেস্ট এজেন্ট নিরীক্ষণ করুন : ডেভেলপমেন্ট এজেন্টদের প্রোডাকশন এজেন্ট হিসেবে বিবেচনা করুন, কারণ ব্যর্থ হলে তারাও শেয়ার্ড পার্টনার কিউ ব্লক করতে পারে।
পরীক্ষার জন্য নির্দিষ্ট অ্যাকাউন্ট : প্রোডাকশন এজেন্টদের জন্য একটি ডেভেলপার অ্যাকাউন্ট এবং টেস্ট এজেন্টদের জন্য একটি নির্দিষ্ট ডেভেলপার অ্যাকাউন্ট ব্যবহার করা শ্রেয়।
গুগল ট্র্যাফিক যাচাই করুন : ফিক্সড আইপি অ্যালাওলিস্টিং-এর পরিবর্তে রিভার্স ডিএনএস বা X-Goog-Signature হেডার ব্যবহার করুন, কারণ গুগল ডাইনামিক অ্যানিকাস্ট আইপি ব্যবহার করে। ম্যানুয়াল যাচাইকরণ এবং গুগল আইপি রেঞ্জ শনাক্তকরণ সম্পর্কে আরও তথ্যের জন্য, ' ভেরিফাই গুগল রিকোয়েস্টস' ডকুমেন্টেশন এবং বিশেষত ইউজার-ট্রিগারড ফেচার ও গুগল ইউজার-ট্রিগারড ফেচার-এর জন্য JSON ফাইলগুলি দেখুন।

পরবর্তী পদক্ষেপ

একবার আপনার ওয়েবহুক কনফিগার করা হয়ে গেলে, আপনার এজেন্ট আপনার টেস্ট ডিভাইসগুলো থেকে মেসেজ গ্রহণ করতে পারবে। আপনার সেটআপ যাচাই করতে একটি মেসেজ পাঠান ।

পরবর্তী

Dialogflow