این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

ساختار به روز رسانی های زمان واقعی

از موارد برای به‌روزرسانی‌های هم‌زمان استفاده کنید

به‌روزرسانی‌های بلادرنگ باید همیشه در سناریوهای زیر صادر شوند:

زمانی که کاربر رزرو سیستم شما را لغو می کند و اسلات در دسترس می شود.
وقتی کاربر از طریق مرکز اقدامات رزرو رزرو می کند و شکاف دسترسی دیگر در دسترس نیست.
هنگامی که رزرو انجام شده از طریق مرکز اقدامات از طرف شما، به عنوان مثال، توسط تاجر مستقیماً لغو می شود. شما باید رزرو و همچنین در دسترس بودن را به روز کنید زیرا اسلات اصلی اکنون دوباره در دسترس است.

علاوه بر این، اگر Availability Replace RTU را پیاده‌سازی کنید، به‌روزرسانی‌های بلادرنگ باید در سناریوهای زیر صادر شوند:

هنگامی که یک تاجر برنامه زمانی (در دسترس بودن) خود را در سیستم شما تغییر می دهد.
وقتی کاربر رزروی را در سیستم شما رزرو می کند و شکاف دسترسی دیگر در دسترس نیست.
اگر از یک ادغام قدیمی با CheckAvailability استفاده می کنید، هنگامی که یک سرور رزرو تماس CheckAvailability موجودی را برمی گرداند که با موجودی واقعی مطابقت ندارد.

همه تماس‌های Maps Booking API لازم نیست. موارد زیر الزامی است:

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

بسته به نوع ادغام موارد زیر نیز ممکن است در دسترس یا مورد نیاز باشد:

inventory.partners.availability.replace ( InventoryUpdate.BatchServiceAvailability ) OR 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

دو نوع روش جایگزینی برای به روز رسانی در دسترس بودن شما وجود دارد:

جایگزینی دسته ای ( InventoryUpdate.BatchServiceAvailability ): به طور کامل جایگزین داده های در دسترس بودن یک تاجر و چندین سرویس می شود.
- توجه: این فراخوان دسته ای اتمی بودن را تضمین نمی کند. فقط اسلات های در دسترس که با موفقیت به روز شده اند بازگردانده می شوند.
Single Replace ( InventoryUpdate.ReplaceServiceAvailability ): به طور کامل جایگزین در دسترس بودن برای یک تاجر و خدمات می شود.

لطفا برای جزئیات بیشتر از مرجع زیر استفاده کنید.

به‌روزرسانی‌های بی‌درنگ باید از همان ساختار در دسترس بودن داده‌هایی استفاده کنند که از طریق فیدها ارسال می‌شوند. آنها باید از یکی از موارد زیر استفاده کنند:

spotsOpen
recurrence

انتخاب روش جایگزینی برای تماس

از راهنمای زیر برای کمک به تعیین اینکه کدام روش جایگزین مناسب تر است استفاده کنید:

آیا خدمات متعدد با یک رزرو تحت تأثیر قرار می گیرند؟ برای مثال، مدل مو و رنگ‌آمیزی (هر کدام یک سرویس متمایز است) با یک آرایشگر رزرو می‌شود، بنابراین تمام خدمات مرتبط با آرایشگر برای آن بازه زمانی باید حذف شوند.
- تعویض دسته ای
سیستم شما هر از چند گاهی با ارسال همه تغییرات در دسترس بودن از زمان آخرین به روز رسانی (توصیه نمی شود) با Google همگام می شود.
- تعویض دسته ای
- توجه: ما انتظار داریم که Inventory RTU ظرف 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"
        }
      ]

توجه: در صورتی که دیگر دسترسی باقی نمانده باشد ( spots_open 0 است)، 2 فرمت ممکن برای ارسال درخواست جایگزینی برای 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 برای اسلات‌هایی باشد که رزرو شده‌اند. دلیل این امر این است که روش API جایگزین در دسترس بودن برای آن سرویس و تاجر خاص است. اگر آن را با چیز دیگری جایگزین می‌کنید، باید اطلاعات کاملی در مورد در دسترس بودن آن سرویس باشد و شامل تمام جایگاه‌های رزرو شده آن باشد.

در اینجا نمونه ای از آنچه در فید روزانه بعدی انتظار می رود آورده شده است. توجه داشته باشید که کل سرویس برای آن تاجر در دسترس است و همه 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 همگام است.