Google ใช้เทคโนโลยี AI เพื่อแปลเนื้อหาเป็นภาษาที่คุณต้องการ การแปลโดย AI อาจมีข้อผิดพลาด

เว็บฮุค

เว็บฮุคคือ URL ที่พาร์ทเนอร์ระบุ ซึ่งแพลตฟอร์ม RCS for Business จะโพสต์ ข้อความ และ เหตุการณ์ โดย URL นี้จะทำหน้าที่เป็นปลายทางที่รับคำขอ HTTPS POST ซึ่งมีข้อมูลเกี่ยวกับเหตุการณ์ ซึ่งหมายความว่าระบบจะส่งข้อมูลไปยังแอปพลิเคชันของคุณอย่างปลอดภัยผ่าน HTTPS

URL ของเว็บฮุคอาจมีลักษณะดังนี้ https://[your company name].com/api/rbm-events เมื่อกำหนดค่าเว็บฮุคแล้ว คุณจะเริ่มรับข้อความและเหตุการณ์ได้

เว็บฮุคของพาร์ทเนอร์และเว็บฮุคของตัวแทน

คุณสามารถกำหนดค่าเว็บฮุคในระดับพาร์ทเนอร์หรือระดับตัวแทนก็ได้

เว็บฮุคของพาร์ทเนอร์จะมีผลกับตัวแทนทุกรายที่คุณดูแล หากตัวแทน มีลักษณะการทำงานที่คล้ายกันหรือมีตัวแทนเพียงรายเดียว ให้ใช้เว็บฮุคของพาร์ทเนอร์
เว็บฮุคของตัวแทนจะมีผลกับตัวแทนแต่ละราย หากคุณใช้งานตัวแทนหลายราย ที่มีลักษณะการทำงานแตกต่างกัน คุณสามารถ ตั้งค่าเว็บฮุคที่แตกต่างกันสำหรับตัวแทนแต่ละรายได้

หากคุณกำหนดค่าทั้งเว็บฮุคของพาร์ทเนอร์และเว็บฮุคของตัวแทน เว็บฮุคของตัวแทนจะมีลำดับความสำคัญเหนือกว่าสำหรับตัวแทนที่เฉพาะเจาะจง ส่วนเว็บฮุคของพาร์ทเนอร์จะมีผลกับตัวแทนที่ไม่มีเว็บฮุคของตนเอง

กำหนดค่าเว็บฮุคของตัวแทน

คุณจะได้รับข้อความที่ส่งไปยังตัวแทนที่เว็บฮุคของพาร์ทเนอร์ หากต้องการให้ข้อความสำหรับตัวแทนที่เฉพาะเจาะจงไปถึงเว็บฮุคอื่นแทน ให้ตั้งค่าเว็บฮุคของตัวแทน

เปิด RCS for Business Developer Console แล้วลงชื่อเข้าใช้ด้วยบัญชี Google ของพาร์ทเนอร์ RCS for Business
คลิกตัวแทน
คลิกการผสานรวม
ในส่วนเว็บฮุค ให้คลิกกำหนดค่า
1. ในปลายทางของเว็บฮุค ให้ป้อน URL ของเว็บฮุคที่ขึ้นต้นด้วย "https://"
2. ในโทเค็นของไคลเอ็นต์ ให้ระบุค่า clientToken คุณต้องใช้ค่านี้เพื่อยืนยัน ว่าข้อความที่ได้รับมาจาก Google
หมายเหตุ: ระบบไม่สามารถแสดงโทเค็นของไคลเอ็นต์ล่าสุดได้ด้วยเหตุผลด้านความปลอดภัย หากต้องการ สร้างโทเค็นของไคลเอ็นต์ใหม่ ให้ป้อนค่าในช่องที่เกี่ยวข้องหรือคลิก รีเฟรช เพื่อสร้างค่าแบบสุ่ม ค่า
ตั้งค่าเว็บฮุคให้ยอมรับคำขอ POST ที่มีเพย์โหลด JSON ซึ่งมีพารามิเตอร์ clientToken และ secret
```
{
  "clientToken":"YOURCLIENTTOKEN",
  "secret":"YOURSECRET"
}
```
ปลายทางต้องแสดงรหัสสถานะ HTTP 200 OK พร้อมค่าสตริงดิบของพารามิเตอร์ secret ในเนื้อหาการตอบกลับเพื่อตรวจสอบคำขอ
ตัวอย่างการกำหนดค่าเว็บฮุค

ตัวอย่างเช่น หากเว็บฮุคได้รับคำขอ POST ที่มีเนื้อหาต่อไปนี้
```
  {
  "clientToken":"YOURCLIENTTOKEN",
  "secret":"YOURSECRET"
  }
  
```
เว็บฮุคควรยืนยันค่า clientToken และหาก clientToken ถูกต้อง ให้แสดงการตอบกลับ 200 OK ที่มี YOURSECRET เป็นเนื้อหาการตอบกลับ
```
  // 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
  });
  
```
ใน Developer Console ให้ คลิก ยืนยัน หลังจากคลิกยืนยัน Google จะส่งคำขอ POST ไปยัง เว็บฮุคของคุณพร้อม clientToken และ secret ในรูปแบบพารามิเตอร์โดยจะอยู่ในข้อความ ของคำขอ เมื่อ RCS for Business ยืนยันเว็บฮุคแล้ว กล่องโต้ตอบจะปิดลง

ระบุประเภทคำขอ

หากต้องการระบุประเภทคำขอสำหรับคำขอทั้งหมดที่ส่งไปยังเว็บฮุค ให้ใช้ส่วนหัว X-Goog-Webhook-Type

ส่วนหัวสามารถมีค่าต่อไปนี้

verification: ใช้สำหรับกระบวนการยืนยันปลายทางเริ่มต้น
message_callback: ใช้สำหรับเหตุการณ์ที่เกี่ยวข้องกับข้อความ เช่น การพิมพ์หรือการแจ้งเตือนการส่ง และข้อความขาเข้าจากผู้ใช้
agent_callback: ใช้สำหรับเหตุการณ์การดูแลระบบที่เฉพาะเจาะจงของตัวแทน เช่น การเปลี่ยนแปลงสถานะการเปิดตัวของตัวแทน

ยืนยันข้อความขาเข้า

เนื่องจากเว็บฮุคสามารถรับข้อความจากผู้ส่งรายใดก็ได้ คุณจึงควรยืนยันว่า Google ส่งข้อความขาเข้าก่อนที่จะประมวลผลเนื้อหาข้อความ

หากต้องการยืนยันว่า Google ส่งข้อความที่คุณได้รับ ให้ทำตามขั้นตอนต่อไปนี้

แยกส่วนหัว X-Goog-Signature ของข้อความ ซึ่งเป็นสำเนาเพย์โหลดเนื้อหาข้อความที่เข้ารหัส Base64 แบบแฮช
ถอดรหัส Base64 เพย์โหลด RCS for Business ในองค์ประกอบ message.body ของคำขอ
ใช้โทเค็นของไคลเอ็นต์ของเว็บฮุค (ซึ่งคุณระบุไว้เมื่อตั้งค่าเว็บฮุค) เป็นคีย์ แล้วสร้าง SHA512 HMAC ของไบต์ของเพย์โหลดข้อความที่ถอดรหัส Base64 และเข้ารหัส 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
    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 จากคอนเทนเนอร์เว็บ การหมดเวลา หรือความล้มเหลวของต้นทาง สิ่งที่ควรพิจารณามีดังนี้

ตรวจสอบว่าได้กำหนดค่าการป้องกัน DDoS เพื่อจัดการอัตราการแจ้งเตือนเว็บฮุคที่คาดไว้
ยืนยันว่าทรัพยากร เช่น กลุ่มการเชื่อมต่อฐานข้อมูล ไม่หมดและทำให้เกิดการหมดเวลาหรือการตอบกลับ 500

นักพัฒนาแอปควรออกแบบระบบเพื่อให้การประมวลผลเหตุการณ์ RBM เกิดขึ้นแบบไม่พร้อมกันและไม่ขัดขวางไม่ให้เว็บฮุคแสดงผล 200 OK

การประมวลผล Webhook แบบอะซิงโครนัส

สิ่งสำคัญคือไม่ ให้ประมวลผลเหตุการณ์ RBM ภายในเว็บฮุคเอง ข้อผิดพลาดหรือความล่าช้าระหว่างการประมวลผลอาจส่งผลต่อรหัสการแสดงผลของเว็บฮุค

การประมวลผลเว็บฮุคแบบซิงโครนัส

ลักษณะการทำงานเมื่อการส่งไม่สำเร็จ

หากเว็บฮุคแสดงผลสถานะอื่นที่ไม่ใช่ 200 OK แพลตฟอร์ม RCS for Business จะใช้กลไกการหน่วงเวลาและลองอีกครั้งเพื่อส่งข้อมูลอีกครั้ง ซึ่งหมายความว่าระบบจะเพิ่มความล่าช้าระหว่างความพยายามในการส่งแต่ละครั้งอย่างต่อเนื่อง จนกระทั่งมีความถี่สูงสุดในการลองอีกครั้งทุกๆ 10 นาทีสำหรับข้อความที่รอดำเนินการแต่ละรายการ รอบการลองอีกครั้งจะดำเนินต่อไปเป็นเวลา 7 วัน หลังจากนั้นระบบจะลบข้อความออกอย่างถาวร

ผลกระทบของเว็บฮุคระดับตัวแทน

RCS for Business จะจัดคิวข้อความสำหรับพาร์ทเนอร์ในคิวเดียว ตัวแทนทั้งหมดในบัญชีพาร์ทเนอร์บัญชีเดียวจะใช้คิวเดียวร่วมกัน ด้วยเหตุนี้ ความล้มเหลวในเว็บฮุครายการหนึ่งจึงอาจบล็อกคิวทั้งหมด ทำให้เหตุการณ์ของผู้ใช้สำหรับตัวแทนทั้งหมดไม่ไปถึงพาร์ทเนอร์

ข้อความหลายรายการที่ไม่ได้รับการรับทราบอาจทำให้เกิดเหตุการณ์การลองอีกครั้งจำนวนมาก ตัวอย่างเช่น หากตัวแทนไม่รับทราบใบเสร็จการส่ง 1,600 รายการ และความถี่ในการลองอีกครั้งถึงขีดจำกัด 10 นาที ก็อาจทำให้เกิดข้อผิดพลาดที่อาจเกิดขึ้นประมาณ 230,000 รายการต่อวัน

ข้อความ 1,600 รายการ × การลองอีกครั้ง 6 ครั้งต่อชั่วโมง × 24 ชั่วโมงต่อวัน = ข้อผิดพลาดประมาณ 230,000 รายการต่อวัน

การลองอีกครั้งจำนวนมากเช่นนี้อาจบล็อกคิว Pub/Sub ที่แชร์และทำให้เกิดความล่าช้าอย่างมากในการรับเหตุการณ์ของผู้ใช้สำหรับแคมเปญทั้งหมดของพาร์ทเนอร์

แนวทางปฏิบัติแนะนำ

โปรดปฏิบัติตามแนวทางปฏิบัติแนะนำต่อไปนี้เพื่อรักษาความน่าเชื่อถือของการรับส่งข้อมูลที่ใช้งานจริงและหลีกเลี่ยงการบล็อกคิว

แสดงผล 200 OK ทันที: เว็บฮุคควรได้รับข้อความ จัดเก็บข้อความไว้ในคิวภายใน และแสดงการตอบกลับ 200 OK ภายในห้า วินาที
แยกการประมวลผล: ใช้ Worker พื้นหลังแยกกันเพื่อประมวลผล ตรรกะข้อความจากคิวภายใน
ตรวจสอบตัวแทนทดสอบ: ปฏิบัติต่อตัวแทนการพัฒนาเสมือนตัวแทนที่ใช้งานจริง เนื่องจากตัวแทนการพัฒนาอาจบล็อกคิวพาร์ทเนอร์ที่แชร์ได้หากทำงานไม่สำเร็จ
บัญชีเฉพาะสำหรับการทดสอบ: ควรใช้บัญชีนักพัฒนาแอปบัญชีหนึ่ง สำหรับตัวแทนที่ใช้งานจริง และบัญชีนักพัฒนาแอปเฉพาะสำหรับตัวแทนทดสอบ
ยืนยันการรับส่งข้อมูลของ Google: ใช้ DNS แบบย้อนกลับหรือส่วนหัว X-Goog-Signature แทนการอนุญาต IP แบบคงที่ เนื่องจาก Google ใช้ IP แบบ Anycast แบบไดนามิก ดูข้อมูลเพิ่มเติมเกี่ยวกับการยืนยันด้วยตนเองและการระบุช่วง IP ของ Google ได้ที่ เอกสารประกอบเรื่องยืนยันคำขอของ Google และโดยเฉพาะอย่างยิ่งไฟล์ JSON สำหรับ ตัวดึงข้อมูลที่ทริกเกอร์โดยผู้ใช้ และ ตัวดึงข้อมูลที่ทริกเกอร์โดยผู้ใช้ของ Google

ขั้นตอนถัดไป

เมื่อกำหนดค่าเว็บฮุคแล้ว ตัวแทนจะ รับข้อความ จาก อุปกรณ์ทดสอบได้ ส่งข้อความ เพื่อตรวจสอบการตั้งค่า

Dialogflow