ميزة "النتائج في الوقت الفعلي" في "البنية"

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

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

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

بالإضافة إلى ذلك، في حال تنفيذ توفّر بيانات الاستبدال 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 من حين لآخر من خلال إرسال كل التغييرات في مدى التوفّر منذ آخر تعديل (لا يُنصح بذلك).
    • الاستبدال المجمّع
    • ملاحظة: نتوقع إرسال طلب إعادة النظر في المستودع في غضون 5 دقائق من إجراء تعديل من جانبك. لذا، عليك التحقّق من أي تعديلات وإرسالها كل 5 دقائق على الأقل.
  • هل لا ينطبق أي مما سبق؟
    • استبدال عنصر واحد
    • ملاحظة: يمكنك استخدام عدّة طلبات استبدال فردية لمحاكاة طلبات استبدال مجمّعة، ولكن سيكون من الأفضل استخدام طلب واحد للاستبدال المجمّع.

آخر الأخبار في الوقت الفعلي: إعلانات المساحات الإعلانية بتنسيق مفتوح

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

يظهر مقتطف خلاصة 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.