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

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

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

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

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

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

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

• notification.partners.bookings.patch (BookingNotification.UpdateBooking)

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

• inventory.partners.availability.replace (InventoryUpdate.BatchServiceAvailability) أو inventory.partners.merchants.services.availability.replace (InventoryUpdate.ReplaceServiceAvailability)

تعديل RTU للحجز

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

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

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

ملاحظة: name وmerchant_id وservice_id و يجب تحديد الحقل المحدد الذي يتم تغييره. وجميع الحقول الأخرى اختيارية. في بعض الظروف، يمكن أن تتغير عدة حقول في نفس الوقت، في هذه الحالة، بفاصلة لفصل الحقول في updateMask (مثلاً updateMask=partySize,startTime).

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

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

ملاحظة: إنّ خيار "استبدال RTU" متوفّر فقط أو مطلوبًا لبعض أنواع التكامل. إذا لم تكن متأكّدًا، يُرجى التواصل مع جهة التواصل في Google التي تتعامل معها.

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

• الاستبدال المجمَّع (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"
        }
      ]

ملاحظة: في حال عدم توفُّر المزيد من مدى التوفّر (تساوي القيمة spots_open 0)، سيتم هناك تنسيقان محتملان لإرسال طلب الاستبدال في Inventory API.

• المواصفات الصريحة: هذه هي الطريقة التي يُنصح بها إذا تحتوي على spots_total > 1

    {
      "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": "0",
              "spotsTotal": "2",
              "availabilityTag": "1000001"
            }
          ]
        }
      ]
    }
  

• المواصفات الفارغة: لا يُنصح باستخدام هذا الخيار إلا إذا كانت السمة spots_total = 1. لمعظم التجّار والخدمات

    {
    "extendedServiceAvailability": [
      {
        "merchantId": "1001",
        "serviceId": "12310",
        "startTimeRestrict": "2014-10-02T15:01:23.045123456Z",
        "endTimeRestrict": "2014-10-02T19:01:23.045123456Z",
        "availability": [
          {}
        ]
      }
    ]
  }
  

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

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

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

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

  "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 لعمليات الخانات التي تم حجزها. السبب في ذلك هو طريقة واجهة برمجة التطبيقات تحل محل مدى التوفّر لهذا النوع من البيانات والتاجر. إذا كنت تستبدله بشيء آخر، فيجب أن المعلومات الكاملة حول مدى توفّر هذه الخدمة، تتضمن جميع خاناته المحجوزة

في ما يلي مثال على ما هو متوقَّع في الخلاصة اليومية التالية. لاحظ أنه مدى توفر الخدمة بالكامل لهذا التاجر، وجميع 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.