115 lines
8.6 KiB
Markdown
115 lines
8.6 KiB
Markdown
# ARR 下一阶段平台支持清单
|
||
|
||
2026-09-17责任澄清：当前可直接转交的平台技术需求见[资料补充说明](arr-platform-evidence-request.md)，
|
||
已列出现有请求编号、应返回的证据及完成条件；用户已自行转交平台技术，等待回复。用户不负责逐字段确认，
|
||
字段转换/独立验证由ARR负责。下方早期未发布/404及“建议封装”段落为历史记录，不能当作当前待办重复提交。
|
||
|
||
**沙箱边界纠正（用户2026-09-17再次强调）：**当前OHIPSB02是测试环境。下述房号缺失属于待核查的数据覆盖，
|
||
不是已确认的平台故障或必须新增接口的证据；不要求它与酒店57106样本有相同业务数据。
|
||
核查时先区分沙箱样本、查询条件及接口返回处理。503是另一项实际调用失败。
|
||
ARR其余开发与明确标为测试的链路验证继续推进，不把房号修复当作全部工作的前置条件。
|
||
|
||
2026-09-17后续：已完成单页房号证据解析，原3份响应离线重核仍无room集合；新增13项/71项范围测试通过。
|
||
当前不是“接口还没发布”，而是缺少能关联原目标预订的房间数据。官方固定Postman示例日期倒置且没有响应，
|
||
不能据其推断assignedRooms等默认值或直接照抄调用。[当前证据](../../.project-docs/50-evidence/topics/2026-09-17-arr-room-calendar-evidence.md)。
|
||
姓名已有[独立补充路径](profile-supplement.md)，其失败不再影响完整v2主体；下文v3停批是历史实现行为。
|
||
|
||
2026-09-17最新实测：目录0.9.0/158项，getRoomCalendar已发布，**不再待发布**；现有reservations.read适用。
|
||
但原失败姓名对象仍503；房间日历3次200只含recordsPerPage，原2笔零晚退房在新摘要中仍无roomId。
|
||
现在需要按[6次已审计请求](platform-recovery-check-20260917.md)核验实际上游结果与数据语义，不能将发布/200当作完成。
|
||
下面较早404记录保留作历史，不能代表最新目录。
|
||
|
||
2026-09-17更新：用户已将503排查交平台；本轮未重新调用酒店接口。公开目录仍115项，
|
||
getRoomCalendar精确查询仍404。ARR已完成逐笔候选准备和后台v3支持，详见
|
||
[独立工作结果](../../.project-docs/50-evidence/topics/2026-09-17-arr-offline-preparation-and-v3-executor.md)。
|
||
|
||
2026-09-16。应用`Wyndham-ARR2.0-Codex`，测试酒店`OHIPSB02`，本次到店/有效价日期均`2026-09-15`。
|
||
此文件可直接提供给平台开发者，无密钥、客人姓名、预订ID或房号。未代用户发送。
|
||
|
||
## 1. 全日采集遇到间歇性503，需核对当前失败编号
|
||
|
||
`searchProfiles`/`getProfiles`已经发布，本应用`profiles.read`已按用户批准开通。
|
||
3位主客的POST及同一人GET对照均为平台审计503/ohip_unavailable；不是空姓名或需要再次授权。
|
||
21:55复验仍失败；用户再次要求复验后，22:21原3位主客POST全部200，身份匹配且均取得非空fullName，
|
||
姓名组成与预订主客一致。平台审计确认成功，见[恢复回执](profile-summary-recovery-second-20260916.json)。
|
||
|
||
随后23:34–23:36获准全日只读实测：6个主客档案中5个成功（含1个503后恢复），第6个连续3次503，整批按界限停止。
|
||
23次业务请求全部有对应平台审计，错误`ohip_unavailable`约25秒；当前编号见[故障说明](profile-summary-platform-check.md)，
|
||
最新一次为`56bc4b67-f0d8-4920-9c2f-c204c27ae967`。请比较同一ID失败/成功及最终连续失败的上游日志。
|
||
批量姓名采集/重放已在本地实现，但全日实测失败；未复验GET或认定根因。摘要nameType未返回，不伪造。
|
||
|
||
## 2. 核验已退房预订的房号读取，建议提供getRoomCalendar只读封装
|
||
|
||
### 已有的具体问题
|
||
|
||
固定OHIPSB02采集里2笔`CheckedOut`预订均为零晚，搜索及到店日段都明确`pseudoRoom=false`。
|
||
它们的搜索摘要和完整已取详情没有返回roomId/roomNo/roomNumber/lastRoom/lastStayRoom/fromRoom/toRoom这些已知房号字段的值。
|
||
请通过以下**Oracle请求追踪编号**定位当时的详情调用（不是Edge控制面请求编号，也不是预订ID）：
|
||
|
||
- `e87d73d0-1484-4589-922d-5690f4151a80`
|
||
- `201e70a0-f5c8-4253-addf-6bbc89cecc60`
|
||
|
||
用户已确认的真实酒店57106 XML包含10笔已退房行，全部有`DISP_ROOM_NO`且与`LAST_ROOM`相同。
|
||
两组资料来自不同酒店，不能声称上述2笔应返回那10笔的房号；它们说明已退房/零晚房号是需要验证的实际场景。
|
||
先排查现有getReservation是否有受支持的按预订历史房号来源；若已有等价读取，请提供准确字段/参数和原始响应证据。
|
||
|
||
### 建议封装的Oracle操作
|
||
|
||
```http
|
||
GET /rsv/v1/hotels/{hotelId}/roomCalendar
|
||
```
|
||
|
||
Operation ID：`getRoomCalendar`。截至本轮已有公开目录核验：0.7.0精确查询为404/not_found，
|
||
request ID`2a48a091-c2a5-4101-9d51-52284ea5c887`。ARR没有猜测Edge地址或绕过平台直连Oracle。
|
||
本轮再次精确查询仍404/not_found，request ID`257f634a-48dc-4e7b-89e5-8cf0a655aa66`；尚未调用房号业务接口。
|
||
|
||
最小需要透传/明确的参数：
|
||
|
||
| 参数 | 用途 |
|
||
|---|---|
|
||
| startDate/endDate | 先以系统提供的2026-09-15查询；请明确同日起止是否包含零晚已退房记录及端点语义 |
|
||
| includeRoomMoveHistory | true，保留真实换房历史 |
|
||
| showRoomMoveSegments | true，保留房间住宿分段；说明相关OPERA Control前置条件 |
|
||
| pageIndex/recordsPerPage | 明确首页编号、上限及结束判断；不要把房间总数当作预订总数 |
|
||
| roomId[] | 可选，按Oracle集合参数形式；不要强制要求已知房号，当前待核验对象恰缺房号 |
|
||
|
||
Oracle接口没有已确认的reservationId查询过滤，ARR不会发明该参数。查询所得日历须按内部Reservation ID关联，
|
||
不能按姓名、房号或数组位置匹配；同一预订可能跨房间/分段出现，保留全部关联后再验证，不擅自取首项。
|
||
|
||
需保留的Oracle响应结构（Edge外层/路径/能力组以正式目录为准）：
|
||
|
||
```text
|
||
roomCalendar.hotelId / totalRooms / pageIndex / recordsPerPage
|
||
roomCalendar.room[].roomId
|
||
roomCalendar.room[].roomSchedule[].start / end
|
||
roomCalendar.room[].roomSchedule[].roomCalendarResList[].reservationIdList
|
||
roomCalendar.room[].roomSchedule[].roomCalendarResList[].dateTimeSpan
|
||
roomCalendar.room[].roomSchedule[].roomCalendarResList[].reservationStatus
|
||
roomCalendar.room[].roomSchedule[].roomCalendarResList[].roomMoveHistory[]
|
||
```
|
||
|
||
roomMoveHistory含hotelId、reservationId、date、fromRoom/toRoom。历史date使用数据库时区，
|
||
roomSchedule.start/end及dateTimeSpan使用酒店时区；请保持原值及语义，不能转换成本机日期后删掉时区。
|
||
可选segmentStartDateTime/segmentEndDateTime受Advance Daily Detail控制影响，缺失时不能伪造分段。
|
||
请在目录发布方法/Edge路径/读取能力组、参数、引用schema、分页和错误语义；权限变化另行复核，不先扩大应用权限。
|
||
|
||
### 验证目标与交付边界
|
||
|
||
先核验上述2笔已退房/零晚对象是否能按内部预订ID取回房间，再检查已有换房记录的全部分段。
|
||
建议覆盖房号前导零、普通住宿、退房、零晚、换房和分页；不要求创建或修改酒店预订。
|
||
返回200或查到历史房号不等于已证明ARR应选哪一段；最终还需同源报表对照确认显示房号规则。
|
||
`GuestLastStay.lastStayRoom`和档案`lastStayInfo.lastRoom`没有当前预订身份绑定，不能直接替代本预订房号。
|
||
|
||
依据：[Oracle固定RSV规范](https://github.com/oracle/hospitality-api-docs/blob/dd631fbd5d0fce74a7dbdf96b43f07ce587211f2/rest-api-specs/property/v1/rsv.json)，
|
||
[Room Diary支持历史已退房及换房记录](https://docs.oracle.com/en/industries/hospitality/opera-cloud/25.5/ocsuh/t_booking_reservations_creating_a_room_diary.htm)。
|
||
|
||
## 3. 公司列目前无需盲目新增接口
|
||
|
||
现有getReservation已经定义Company/TravelAgent/Source/Group角色、内部Profile ID及名称。
|
||
本日测试数据只观察到Group；真实XML则只有单一T-/C-显示值，没有多角色组合案例。
|
||
当前缺口是同源数据和报表显示规则，额外查询这些Group档案不会生成不存在的公司/旅行社关联。
|
||
先保留现有按角色与内部身份取值实现；后续有同源样本时验证多角色并存、前缀/分隔符及日期层级，不擅定Company优先。
|
||
|
||
当前平台支持重点是本轮姓名POST间歇性503，以及历史房号来源；这不代表其他ARR规则已自动验收。
|
||
完整姓名、公司显示、记录范围/顺序、共享房与多备注等验收继续由ARR负责；完整输出可联调时会另行通知用户。
|