参与预订等位名单计划的合作伙伴必须在开始前完成帐号设置。但是,一般指南中的某些步骤对于使用候位名单功能而言并不是必需的。本页中的指南介绍了有意使用“通过 Google 预订”上的等位名单功能的合作伙伴需要执行哪些步骤。我们建议您先阅读本概览,然后再完成集成步骤。
发布流程
图 1 概述了在 Actions Center 中发布已启用候位名单的商家的流程。
![图 1:高级集成步骤](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/waitlists/reserve_with_google_waitlist_integration.png?authuser=19&hl=zh-cn)
总体而言,您(合作伙伴)与 Google 之间的主要数据流如图 2 所示:
![图 2:集成数据流示意图](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/waitlists/waitlist_integration_data_flow_diagram.png?authuser=19&hl=zh-cn)
适用于所有预订等位名单合作伙伴的准则
在实现预订等位名单功能时,请注意以下几点:
- 必须为每个预订等位名单商家的服务填充
waitlist_rules
。- 您在候补名单和预订中必须使用相同的服务。换句话说,如果您的餐厅还允许预订,只需将与候位名单相关的元数据添加到服务进行预订即可。
- 在以下情况下,必须发送短信更新才能实现候位名单:
- 确认用户已成功加入等候名单。
- 通知用户其表已准备就绪。
- 通知用户其候补名单条目已被取消。
- 短信必须包含指向可供用户查看其候补名单状态的页面的链接。
- 仅支持候位名单的商家无需向 Actions Center 提供库存状况 Feed。
- 您的预订服务器必须实现实现预订服务器中列出的所有特定于候位名单的步骤。同时支持预订和等位名单的合作伙伴可以将新方法添加到其现有的预订服务器。
- Actions Center 会为预订服务器中的候位名单方法运行一组测试用例。
状态流程图
下表描述了在响应
GetWaitlistEntry
调用时必须在
WaitlistEntry.waitlist_entry_state
中报告的状态。该图表还指明了何时记录和填充
WaitlistEntry.waitlist_entry_state_times.*_time_seconds
字段,以及何时向用户发送短信以通知用户已进入新状态。
![图 3:等位名单状态流程图](https://developers-dot-devsite-v2-prod.appspot.com/static/actions-center/images/waitlists/waitlist_status_flowchart.png?authuser=19&hl=zh-cn)
常见的极端情况
以下是预订候位名单集成中常见的极端情况,以及相应的首选解决方案。
-
如果部分(但不是所有)人数不接受增加新的候位名单人数(因为无需等待这些人数),则在
BatchGetWaitEstimates
响应中返回所有人数的WaitEstimates
,并允许用户无需等待即可加入这些人数的等位名单。对于无需等待的party_size
,返回parties_ahead_count
为 0 的WaitLength
和/或start_seconds
为 0 且end_seconds
为 0 的estimated_seat_time_range
-
如果因等待时间过长而不接受添加新的等候名单人数,则首选在
BatchGetWaitEstimates
响应中省略这些人数的WaitEstimates
。
建议采用这些方法,因为即使商家的等候名单可能未完全开放,但也能为用户提供选项。
仅适用于预订等位名单的合作伙伴指南
如果预订服务器仅用于候位名单,请注意以下几点:
- 仅支持预订等位名单的合作伙伴不会向“通过 Google 预订”提供可用性 Feed。
- 仅支持预订等位名单的合作伙伴不会在预订服务器中实现预订方法。而是应该按照候位名单实现的说明实现预订服务器。
- 仅支持预订等位名单的合作伙伴不会向 Google 发出 API 调用。这意味着,仅支持预订等位名单的合作伙伴无需设置云项目或提供开发者电子邮件地址。您无需完成实时 API 更新。不过,仍需向 Actions Center 提供商家和服务 Feed。
适用于商家必须手动接受/拒绝添加候位名单成员的合作伙伴的指南
如果您的商家要求能够手动接受或拒绝 Google 添加新的等位名单,则需采取额外的步骤:
- 对于需要手动确认的人数,请在
wait_estimate
中将waitlist_confirmation_mode
设置为WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS
。必须在BatchGetWaitEstimateResponse
和GetWaitlistEntryResponse
中设置此字段。 - 用户已请求但尚未被商家接受的等位名单条目应处于
PENDING_MERCHANT_CONFIRMATION
状态。
预订等位名单测试用例
Google 会测试以下用例,以确保预订服务器实现中的候位名单方法能够正常运行。Google 还会测试和监控延迟情况。通过这些测试后才能发布。
检索 WaitEstimate
- 系统会针对
BatchGetWaitEstimatesRequest
中请求的每种人数返回估算的等待时间。 - 对于商家能够选择接受或拒绝添加新的候位名单成员的人数,请将 waitlist_confirmation_mode 设置为
WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS
。
创建候位名单条目
- 您可以通过
CreateWaitlistEntry
请求创建候位名单条目。 - 如果候位名单条目创建失败,响应中会显示业务逻辑错误。
- 如果
CreateWaitlistEntry
尝试成功,系统会在再次收到同一CreateWaitlistEntry
时返回相同的响应。 - 如果
CreateWaitlistEntry
尝试失败,服务器会在再次收到相同的CreateWaitlistEntry
时重试。 - 候位名单条目在商家的界面中显示。
- 成功调用
GetWaitlistEntry
会返回已创建的候位名单条目。
候位名单条目状态和时间戳
- 验证是否在
GetWaitlistEntry
响应的候位名单条目中正确返回了每个候位名单条目状态。 - 验证是否在
GetWaitlistEntry
响应中的候位名单条目的相应时间戳字段中设置了每个状态时间戳。
删除候位名单条目
- 可删除现有候位名单条目。对成功删除的响应必须为空 proto
{}
。
选择停用
- 验证系统是否按照商家停用中所述的方式对待停用的商家。
候位名单服务 Feed 示例 (JSON)
等位名单服务 Feed由商家停用
Google 希望之前已启用等位名单功能但现已决定停用的商家能够做出特定回应。
立即停用
- 对于
BatchGetWaitEstimates
请求,返回CLOSED_OTHER
。 - 对
CreateWaitlistEntry
请求返回WAITLIST_CLOSED
。 - 针对已加入等候名单的用户正确返回
GetWaitlistEntry
请求。
延长停用
- 如果商家未选择停用预留,请从商家的服务 Feed 中移除
waitlist_rules
。 - 如果商家选择停用所有 Google 集成,则从商家 Feed 中移除商家。