new_releases อัปเดต: ดู
บันทึกประจํารุ่นสําหรับฟีเจอร์ใหม่ๆ และการอัปเดตผลิตภัณฑ์
การดำเนินการแบบซิงโครนัสและแบบอะซิงโครนัสใน RBM
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
เอกสารนี้ชี้แจงวิธีที่แพลตฟอร์ม RBM จัดการการส่งข้อความและการโต้ตอบกับ API อื่นๆ โดยแยกความแตกต่างระหว่างการดำเนินการแบบซิงค์และแบบไม่ซิงค์
โดยทั่วไปแล้ว การโต้ตอบกับ RBM API จะเป็นไปตามรูปแบบคำขอ-การตอบกลับแบบซิงค์ที่ระดับ HTTP อย่างไรก็ตาม ผลลัพธ์ของการเรียก API หลายรายการ โดยเฉพาะการนำส่งข้อความจะจัดการแบบไม่พร้อมกันผ่าน Webhook ดูรายละเอียดได้ที่ส่วนต่อไปนี้
การส่งข้อความ: คำขอแบบซิงโครนัส การแสดงผลแบบอะซิงโครนัส
ระบบจะประมวลผลคําขอ phones.agentMessages.create API แบบซิงโครนัสจากมุมมอง API เมื่อคุณส่งคําขอ HTTP ไปยังแพลตฟอร์ม RBM เซิร์ฟเวอร์จะตอบกลับเกือบจะทันทีด้วยรหัสสถานะ HTTP มาตรฐาน (เช่น 200 OK หรือข้อผิดพลาด) เพื่อระบุว่าได้รับคําขอและถูกต้องหรือไม่
อย่างไรก็ตาม การส่งข้อความไปยังผู้ใช้ปลายทางจริงจะประมวลผลแบบอะซิงโครนัส ปัจจัยต่อไปนี้อาจส่งผลต่อกระบวนการนี้
- สถานะผู้รับ: ผู้ใช้อาจออฟไลน์อยู่ แบตเตอรี่หมด หรือไม่ได้เปิดใช้ RCS
- สภาพเครือข่าย: ปัญหาเกี่ยวกับเครือข่ายของผู้ให้บริการอาจทำให้การส่งข้อความล่าช้าหรือไม่สามารถส่งได้
แพลตฟอร์ม RBM จะอัปเดตสถานะการนำส่งข้อความ (เช่น ใบตอบรับการนำส่งและใบตอบรับการอ่าน) แบบไม่พร้อมกันผ่าน webhooks
ดังนั้น แม้ว่าคำขอ API เริ่มต้นจะเป็นแบบซิงค์ แต่คุณควรใช้เหตุการณ์ Webhook แบบไม่ซิงค์เพื่อติดตามการนำส่งข้อความ โปรดอย่าคาดหวังการยืนยันสถานะการนำส่งทันทีจากคําตอบของ phones.agentMessages.create
การโต้ตอบอื่นๆ ของ RBM API
RBM API อื่นๆ ส่วนใหญ่ที่ใช้ HTTP ทำงานด้วยรูปแบบคำขอ-การตอบกลับแบบซิงค์ด้วย API เหล่านี้จะแสดงการตอบกลับ HTTP ทันทีซึ่งระบุสถานะคำขอ (สำเร็จหรือข้อผิดพลาด) อย่างไรก็ตาม แม้ว่าคำขอจะเป็นแบบซิงโครนัส แต่การดำเนินการที่เกิดจากคำขออาจเกี่ยวข้องกับกระบวนการแบบอะซิงโครนัส
ตัวอย่างเช่น การตอบกลับการเรียก API เพื่ออัปเดตข้อมูลตัวแทนที่สำเร็จไม่ได้หมายความว่าการอัปเดตจะแสดงในทุกที่ทันที อาจมีความล่าช้าในการนำไปใช้งาน
ปลายทางของเว็บฮุค: เหตุการณ์ที่เกิดขึ้นไม่พร้อมกัน
เหตุการณ์ต่อไปนี้จะส่งไปยังปลายทาง webhook แบบไม่พร้อมกัน
- ข้อความขาเข้าของผู้ใช้: แพลตฟอร์ม RBM จะส่งข้อความขาเข้าของผู้ใช้ไปยังปลายทางเว็บฮุค อย่าลืมยืนยันข้อความขาเข้า
- ใบตอบรับการนำส่งและการอ่าน: ระบบจะส่งการแจ้งเตือนสถานะการนำส่งและสถานะการอ่านข้อความผ่าน Webhook
- เหตุการณ์การสนทนา: ระบบจะส่งเหตุการณ์บางอย่างที่เกี่ยวข้องกับการสนทนา เช่น ตัวบ่งชี้การพิมพ์ ผ่าน Webhook
- เหตุการณ์การหมดอายุและการเพิกถอนข้อความ: แพลตฟอร์ม RBM จะส่งเหตุการณ์เพื่อยืนยันว่าเพิกถอนข้อความที่หมดอายุแล้วสําเร็จหรือไม่
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-02-10 UTC
[null,null,["อัปเดตล่าสุด 2025-02-10 UTC"],[[["\u003cp\u003eRBM API interactions use a synchronous request-response model at the HTTP level, providing immediate feedback on request validity.\u003c/p\u003e\n"],["\u003cp\u003eMessage delivery in the RBM platform is processed asynchronously, relying on webhooks for updates due to factors like recipient status and network conditions.\u003c/p\u003e\n"],["\u003cp\u003eWhile the initial API request for sending messages is synchronous, delivery and read receipts are provided asynchronously through webhook events.\u003c/p\u003e\n"],["\u003cp\u003eOther RBM API interactions follow a synchronous pattern for request handling, but resulting actions may involve asynchronous processes with potential delays.\u003c/p\u003e\n"],["\u003cp\u003eThe RBM platform delivers various asynchronous events, such as incoming user messages, delivery receipts, and conversation updates, through a designated webhook endpoint.\u003c/p\u003e\n"]]],[],null,["# Synchronous and asynchronous operations in RBM\n\nThis document clarifies how the RBM platform handles message sending and other\nAPI interactions, distinguishing between synchronous and asynchronous\noperations.\n\nRBM API interactions generally follow a synchronous request-response pattern at\nthe HTTP level. However, the results of many API calls, especially message\ndelivery, are handled asynchronously through webhooks. Refer to the following\nsections for details.\n\nMessage sending: Synchronous request, asynchronous delivery\n-----------------------------------------------------------\n\nThe [`phones.agentMessages.create`](/business-communications/rcs-business-messaging/reference/rest/v1/phones.agentMessages/create)\nAPI request is processed **synchronously** from the API\nperspective. When you make an HTTP request to the RBM platform, the server\nresponds almost immediately with a standard HTTP status code\n(like `200 OK` or an error) to indicate whether the request was\nreceived and is valid.\n\nHowever, the actual delivery of the message to the end user is\nprocessed **asynchronously**. The following factors can affect this process:\n\n- **Recipient status**: The user might be offline, have an empty battery, or not have RCS enabled.\n- **Network conditions**: Carrier network issues can delay or prevent message delivery.\n\nThe RBM platform provides message delivery status updates (like delivery\nreceipts and read receipts) asynchronously through\n[webhooks](/business-communications/rcs-business-messaging/guides/integrate/webhooks).\nTherefore, while the initial API request is synchronous, you should rely on\nasynchronous webhook [events](/business-communications/rcs-business-messaging/guides/build/events#agent-generated_events)\nto track message delivery. Don't expect immediate confirmation of delivery\nstatus from the\n[`phones.agentMessages.create`](/business-communications/rcs-business-messaging/reference/rest/v1/phones.agentMessages/create)\nresponse.\n\n### Other RBM API interactions\n\nMost other HTTP-based RBM APIs also operate with a synchronous request-response\nmodel. These APIs provide an immediate HTTP response that indicates the status\nof the request (success or error). However, while the request is synchronous,\nthe actions resulting from the request might involve asynchronous processes.\nFor example, a successful response to an API call to update agent information\ndoesn't mean the update is instantly reflected everywhere; there might be a\nshort propagation delay.\n\nWebhook endpoint: Asynchronous events\n-------------------------------------\n\nThe following [events](/business-communications/rcs-business-messaging/guides/build/events#agent-generated_events)\nare delivered asynchronously to your [webhook](/business-communications/rcs-business-messaging/guides/integrate/webhooks)\nendpoint:\n\n- **Incoming user messages** : The RBM platform pushes incoming user messages to your webhook endpoint. Be sure to [verify incoming messages](/business-communications/rcs-business-messaging/guides/integrate/webhooks#verify_incoming_messages).\n- **Delivery and read receipts**: Notifications of message delivery and read status are sent through webhooks.\n- **Conversation events**: Some conversation-related events, such as typing indicators, are sent through webhooks.\n- **Message expiration and revocation events**: The RBM platform sends events to confirm whether an expired message was successfully revoked."]]
