new_releases التعديلات: يمكنك الاطّلاع على
ملاحظات الإصدار للتعرّف على الميزات الجديدة وتحديثات المنتجات.
العمليات المتزامنة وغير المتزامنة في نموذج RBM
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يوضّح هذا المستند كيفية تعامل منصة RBM مع إرسال الرسائل وغيرها من تفاعلات واجهة برمجة التطبيقات، مع التمييز بين العمليات المتزامنة وغير المتزامنة.
تتّبع التفاعلات مع واجهة برمجة التطبيقات لنموذج "الاستجابة الذكية للإعلانات" بشكل عام نمطًا متزامنًا للطلب والاستجابة على مستوى HTTP. ومع ذلك، يتم التعامل مع نتائج العديد من طلبات البيانات من واجهة برمجة التطبيقات، خاصةً تسليم الرسائل، بشكل غير متزامن من خلال وحدات الربط بالويب. يُرجى الرجوع إلى القسمين التاليين للحصول على التفاصيل.
إرسال الرسائل: طلب متزامن، إرسال غير متزامن
تتم معالجة طلب phones.agentMessages.create
واجهة برمجة التطبيقات بشكل متزامن من منظور واجهة برمجة التطبيقات. عند إرسال طلب HTTP إلى منصة RBM، يستجيب الخادم
على الفور تقريبًا باستخدام رمز حالة HTTP عادي
(مثل 200 OK أو خطأ) للإشارة إلى ما إذا كان الطلب
قد تم استلامه وهل هو صالح.
ومع ذلك، تتم معالجة عملية التسليم الفعلية للرسالة إلى المستخدم النهائيبشكل غير متزامن. يمكن أن تؤثّر العوامل التالية في هذه العملية:
- حالة المستلِم: قد يكون المستخدم غير متصل بالإنترنت أو قد تكون بطاريته فارغة أو قد لا يكون لديه
خدمة RCS مفعَّلة.
- ظروف الشبكة: يمكن أن تؤدّي مشاكل شبكة مشغّل شبكة الجوّال إلى تأخير تسليم الرسائل أو منعه.
توفّر منصة RBM تعديلات على حالة تسليم الرسائل (مثل إيصالات التسليم وإيصالات القراءة) بشكل غير متزامن من خلال
webhooks.
لذلك، على الرغم من أنّ طلب واجهة برمجة التطبيقات الأوّلي متزامن، عليك الاعتماد على
أحداث webhook غير المتزامنة
لتتبُّع تسليم الرسائل. لا تتوقّع تلقّي تأكيد فوري لحالة التسليم
من الردّ على
phones.agentMessages.create.
التفاعلات الأخرى مع واجهة برمجة التطبيقات في "إدارة الأداء من Google"
تعمل معظم واجهات برمجة التطبيقات الأخرى المستندة إلى HTTP لمعالجة الطلبات في الوقت الفعلي أيضًا باستخدام نموذج طلبات واستجابات
متزامن. توفّر واجهات برمجة التطبيقات هذه استجابة HTTP فورية تشير إلى حالة
الطلب (نجاح أو خطأ). ومع ذلك، على الرغم من أنّ الطلب متزامن،
قد تتضمن الإجراءات الناتجة عن الطلب عمليات غير متزامنة.
على سبيل المثال، لا يعني الاستجابة الناجحة لطلب بيانات واجهة برمجة التطبيقات لتعديل معلومات موظّف الدّعم
أنّ التعديل يظهر على الفور في كل مكان، فقد يكون هناك
تأخّر قصير في النشر.
نقطة نهاية الردّ التلقائي على الويب: الأحداث غير المتزامنة
يتم إرسال الأحداث التالية
بشكل غير متزامن إلى نقطة نهاية webhook:
- رسائل المستخدمين الواردة: تُرسِل منصة RBM رسائل المستخدمين الواردة إلى
نقطة نهاية تفاعلك مع واجهة برمجة التطبيقات. احرص على التحقّق من الرسائل الواردة.
- إيصالات التسليم والقراءة: يتم إرسال إشعارات بشأن حالة تسليم الرسائل وقراءة
الرسائل من خلال وحدات الربط بالويب.
- أحداث المحادثة: يتم إرسال بعض الأحداث ذات الصلة بالمحادثة، مثل مؤشرات typing
، من خلال وحدات الربط بالويب.
- أحداث انتهاء صلاحية الرسائل وإبطالها: تُرسِل منصة RBM أحداثًا لتأكيد ما إذا تم إبطال رسالة منتهي الصلاحية بنجاح.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-02-10 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-02-10 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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."]]
