التحديثات في الوقت الفعلي من البنية

حالات الاستخدام للتحديثات في الوقت الفعلي

يجب إصدار التحديثات في الوقت الفعلي دائمًا في السيناريوهات التالية:

  • عندما يلغي المستخدم حجزًا على نظامك، وتصبح الخانة المتوفرة.
  • عندما يُجري أحد المستخدمين حجزًا من خلال "مركز الإجراءات" لم تعُد خانة مدى التوفّر متاحة.
  • عند إلغاء حجز تم إجراؤه من خلال "مركز الإجراءات" على الصفحة الرئيسية، على سبيل المثال، من قِبل التاجر مباشرةً. ستحتاج إلى تحديث للحجز ومدى التوفّر لأنّ الخانة الأصلية أصبحت الآن متاحًا مرة أخرى.

بالإضافة إلى ذلك، إذا قمتَ بتنفيذ حلّ مدى التوفّر بدلاً من RTU يجب إصدار التحديثات في الوقت الفعلي في السيناريوهات التالية:

  • عندما يغيّر التاجر جدوله الزمني (مدى التوفّر) في نظامك.
  • عندما يحجز أحد المستخدمين في نظامك وفترة مدى التوفّر. لم يعد متاحًا.
  • إذا كنت تستخدم عملية دمج قديمة مع CheckAvailability، عندما يقوم خادم حجز CheckAvailability مخزون مرتجعات المكالمات الذي لا يتطابق مع المخزون الفعلي.

لا يجب طلب جميع طلبات البيانات من واجهة برمجة التطبيقات Maps Booking API. المتطلبات التالية إلزامية:

واستنادًا إلى نوع عملية الدمج، قد يكون ما يلي متاحًا أو مطلوبًا أيضًا:

تعديل RTU للحجز

في حال إجراء تعديل على حجز في "مركز الإجراءات" (مثل الإلغاء أو عدّلته) على نظامك، notification.partners.bookings.patch (BookingNotification.UpdateBooking) .

الحقول القابلة للتعديل

  • status
  • startTime
  • duration
  • partySize
  • paymentInformation.prepaymentStatus

مثال على الإلغاء

Request:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/<PARTNER_ID>/bookings/<BOOKING_ID>?updateMask=status

Body:
{
  "name": "partners/<PARTNER_ID>/bookings/<BOOKING_ID>",
  "merchantId": "10001",
  "serviceId": "1001",
  "startTime": "2014-10-02T15:01:23.045123456Z",
  "duration": "3000s",
  "status": "CANCELED"
}

مدى التوفّر بدلاً من RTU

يتوفر نوعان من طرق الاستبدال لتحديث مدى التوفّر:

  • الاستبدال المجمَّع (InventoryUpdate.BatchServiceAvailability): تستبدل بيانات مدى التوفّر بالكامل للتاجر
    • ملاحظة: لا تضمن هذه المكالمة المجمّعة حدّة البيانات. فقط ستظهر خانات مدى التوفّر التي تم تعديلها بنجاح.
  • استبدال أحادي (InventoryUpdate.ReplaceServiceAvailability): تحلّ هذه السمة محلّ مدى التوفّر لتاجر واحد وخدمة واحدة بالكامل.

يُرجى استخدام ما يلي: المرجع لمزيد من التفاصيل.

يجب استخدام بنية مدى التوفّر نفسها في البيانات عند إجراء التعديلات في الوقت الفعلي التي يتم إرسالها من خلال الخلاصات. ويجب أن يستخدم أي مما يلي:

  • spotsOpen
  • recurrence

اختيار طريقة استبدال للاتصال

استخدِم الدليل التالي لمساعدتك في تحديد طريقة الاستبدال الأكثر فعالية. مناسبة:

  • هل تتأثر عدة خدمات بحجز واحد؟ على سبيل المثال، قصّة شعر والتلوين (كل منها خدمة مميزة) يتم حجزها مع مصفف، لذلك يجب إزالة الخدمات المرتبطة بالمصفّف خلال هذه الفترة الزمنية.
  • وسيتزامن نظامك مع نظام Google من وقت لآخر من خلال إرسال جميع التغييرات التي طرأت على مدى التوفّر منذ آخر تعديل (لا ننصح بهذا الخيار)
    • الاستبدال المجمَّع
    • ملاحظة: نتوقّع أن يتم إرسال قيمة RTU للمستودع في غضون 5 دقائق من إجراء أي تعديل. بجانبك. وبالتالي، يجب الاطّلاع على أي تعديلات وإرسالها كل 5 دقائق على الأقل.
  • ألا ينطبق أي مما سبق؟
    • استبدال فردي
    • ملاحظة: يمكنك استخدام استدعاءات استبدال واحدة متعددة لمحاكاة للاستبدال المجمّع، ولكن سيكون من الأكثر فعالية استخدام عنوان URL واحد مكالمة استبدال مُجمَّع

إشعارات في الوقت الفعلي: تنسيق فتح الإعلانات

ومن المهم استخدام التنسيق نفسه في الخلاصات وخادم الحجز تحديثات في الوقت الفعلي.

يبدو مقتطف خلاصة spots_open على النحو التالي:

مقتطف الخلاصة

   "availability": [
          {
            "merchant_id": "1001",
            "service_id": "12310",
            "spots_open": 2,
            "spots_total": 2,
            "start_sec": 1412263800, # October 02, 2014 15:30:00
            "duration_sec": 1800,
            "availabilityTag": "1000001"
          }
    ]

بالنسبة إلى واجهة برمجة التطبيقات Inventory Update API، يتم استخدام تنسيق نص طلب الاستبدال عندما يتم حجز خانة في الساعة 3:30 بعد الظهر:

استبدال مقتطف التعديلات في الوقت الفعلي

  {
    "extendedServiceAvailability": [
      {
        "merchantId": "1001",
        "serviceId": "12310",
        "startTimeRestrict": "2014-10-02T15:01:23.045123456Z",
        "endTimeRestrict": "2014-10-02T19:01:23.045123456Z",
        "availability": [
          {
            "startTime": "2014-10-02T15:30:00.00Z",
            "duration": "3600s",
            "spotsOpen": "1",
            "spotsTotal": "2",
            "availabilityTag": "1000001"
          }
        ]
      }
    ]
  }

إليك مثال على ما نتوقعه في الخلاصة اليومية التالية، إذا كانت خانة جديدة تم الحجز في الساعة 3:30 بعد الظهر:

مقتطف الخلاصة

"availability": [
        {
          "merchant_id": "1001",
          "service_id": "12310",
          "spots_open": 1,
          "spots_total": 2,
          "start_sec": 1412263800, # October 02, 2014 15:30:00
          "duration_sec": 1800,
          "availabilityTag": "1000001"
        }
      ]

إشعارات في الوقت الفعلي: تنسيق التكرار

ومن المهم استخدام التنسيق نفسه في الخلاصات وخادم الحجز تحديثات في الوقت الفعلي.

تبدو الخلاصة التي تستخدم التكرار كما يلي:

مقتطف الخلاصة

  "availability": [
        {
          "merchant_id": "1001",
          "service_id": "12310",
          "spots_open": 1,
          "spots_total": 1,
          "start_sec": 1540890000, # October 30, 2018 9:00:00 AM
          "duration_sec": 1800,
          "recurrence": {
            "repeat_every_sec": 1800,
            "repeat_until_sec": 1540918800 # October 30, 2018 5:00:00 PM
          },
          "schedule_exception": [
            {
              "time_range": {
                "begin_sec": 1540902600, # October 30, 2018 12:30:00 PM
                "end_sec": 1540904400 # October 30, 2018 1:00:00 PM
              }
            }
          ],
        }
      ]

بالنسبة إلى واجهة برمجة التطبيقات Inventory Update API، يتم استخدام تنسيق نص طلب الاستبدال عندما يتم حجز خانة في الساعة 3:30 بعد الظهر، على النحو التالي:

  {
    "extendedServiceAvailability": [
      {
        "merchantId": "1001",
        "serviceId": "12310",
        "startTimeRestrict": "2018-10-30T15:01:23.045123456Z",
        "endTimeRestrict": "2018-10-30T19:01:23.045123456Z",
        "availability": [
          {
            "startTime": "2018-10-30T15:30:00.00Z",
            "duration": "3600s",
            "spotsOpen": "1",
            "scheduleException": [
             {
                "timeRange": {
                  "startTime": "2018-10-30T12:30:00.00Z",
                  "endTime": "2018-10-30T13:00:00.00Z"
                }
              },
              {
                "timeRange": {
                  "startTime": "2018-10-30T15:30:00.00Z",
                  "endTime": "2018-10-30T16:00:00.00Z"
                }
              }
            ]
          }
        ]
      }
    ]
  }

في ما يلي مثال على ما هو متوقَّع في الخلاصة اليومية التالية. لاحظ أنه مدى توفر الخدمة بالكامل لهذا التاجر، وجميع schedule_exceptions السابقة والجديدة:

مقتطف الخلاصة

   "availability": [
        {
          "merchant_id": "1001",
          "service_id": "12310",
          "spots_open": 1,
          "spots_total": 1,
          "start_sec": 1540890000, # October 30, 2018 9:00:00 AM
          "duration_sec": 1800,
          "recurrence": {
            "repeat_every_sec": 1800,
            "repeat_until_sec": 1540918800 # October 30, 2018 5:00:00 PM
          },
          "schedule_exception": [
            {
              "time_range": {
                "begin_sec": 1540902600, # October 30, 2018 12:30:00 PM
                "end_sec": 1540904400 # October 30, 2018 1:00:00 PM
              }
            },
            {
              "time_range": {
                "begin_sec": 1540913400, # October 30, 2018 3:30:00 PM
                "end_sec": 1540915200 # October 30, 2018 4:00:00 PM
              }
            }
          ],
        }
      ]

وقت إرسال التحديثات في الوقت الفعلي

يجب إرسال تحديثات في الوقت الفعلي بشكل مستمر كلما تغير مدى التوفر. هذا بالإضافة إلى خلاصة توفّر شاملة يجب مرة واحدة يوميًا، لضمان مزامنة مدى التوفّر بين جهازك وأنظمة Google.