shiyuyun/ARR-2.0-0918

0 Fork 0

Files

T

Wyndham ARR ad2c59256f feat: add date-based OHIP data reporting alongside XML

2026-09-18 15:29:27 +08:00

8.9 KiB

Raw Blame History

ARR 已接接口与实际传参确认单

核对日期：2026-09-18。依据当前调用代码及在本机生成的请求样例，不发起OHIP请求、不读取密钥、不改变任务。这是已实现行为的说明，供用户确认；不表示已经通过实际订单验收。

页面输入与参数来源

用户只选择报表日期D，例如2026-09-15。页面提交到ARR自身的请求为：

POST /api/arr-downloads

{
  "report_date": "2026-09-15",
  "request_id": "<系统生成并保存的32位任务编号>"
}

任务编号用于ARR内部防重复和恢复，不作为下面8个OHIP接口的业务参数。继续原任务时调用ARR自身的 POST /api/arr-downloads/{request_id}/retry，正文{}，沿用原日期；预选下一日期不改变已提交任务。

代号	含义	来源
D	报表日期/到店日期	页面当前选值；初始建议值为曼谷日历昨天，用户可以改选，后台不再次减一天
R	预订内部ID	列表返回的`reservationIdList`中`type=Reservation`的ID；不是显示给客人的确认号
P	档案内部ID	预订中关联的`profileIdList`、`type=Profile`；姓名查询使用唯一主客的档案ID
B	团队内部ID	预订到店日资料中`blockIdList`、`type=Block`；不是团队代码
C	套餐代码	预订详情的`reservationPackages[].packageCode`
E	离店日期	同一笔预订的离店日期，经检查不早于D

共同连接设置

平台地址：https://ohip.nianxx.cn。
当前应用：Wyndham-ARR2.0-Codex，应用IDcaller_zloxalzsQ9pYsztt；当前本机预期酒店OHIPSB02。
每个请求携带X-API-Key，值由私有凭据文件提供；本文不包含密钥。
同时携带Accept: application/json与Content-Type: application/json。
当前请求没有单独传hotelId或x-hotelid；酒店由平台路由确定，ARR核对返回酒店与配置一致。应用ID也不作为单独请求头传出。
用户已确认接受上述酒店路由与OHIPSB02核对方式，正式环境切换时再调整对应配置；本次发布不切换酒店。
下列8项均为查询，不修改Oracle订单。POST在此用于查询条件提交。

1. 到店预订列表 — searchHotelReservations

用途：找到D当天到店的预订，为后续逐笔查详情提供R。

POST /api/v1/reservations/searches，正文：

{
  "arrivalStartDate": "2026-09-15",
  "arrivalEndDate": "2026-09-15",
  "limit": 100,
  "offset": 0,
  "orderBy": ["ConfirmationNo"],
  "sortOrder": ["Asc"]
}

两个日期都等于D；按到店日期查询，不是D当天所有在住或离店客人。
每页100条，后续offset为100、200……；读取平台分页结果决定何时结束。
所有详情和补查结束后，重新查询同样的完整列表，检查采集中记录是否变化；这不是一个额外接口。
当前未显式传预订状态、分房状态、费率代码、市场代码或公司筛选条件。不传状态不等于已经确认平台默认包含全部状态。
ARR不在查询阶段应用后续费率白名单和业务去重。

2. 预订详情 — getReservation

用途：取得确认号、入住/离店日期、人数、房间数、房型、费率、备注、档案/团队/套餐关联资料，并优先从详情确定房号等字段。

GET /api/v1/reservations/{R}，无正文，查询参数fetchInstructions重复传7项：

Reservation
Comments
DailySummary
RateInfoDetails
Packages
InventoryItems
Shares

即?fetchInstructions=Reservation&fetchInstructions=Comments&...，不是逗号拼成一个值。每笔预订调用；不传日期参数，收到详情后在程序中选出D适用的日资料。Traces明确不请求。备注请求为Comments，当前没有额外传“GEN”或“包含内部备注”的开关；返回后由程序提取GEN备注，内部备注不被主动排除。

3. 指定日有效房价 — searchRateInfo

用途：取得这笔预订在D的有效价格。

POST /api/v1/reservations/rate-info/searches，正文：

{
  "id": "R123",
  "type": "Reservation",
  "summaryInfo": false,
  "detailDate": "2026-09-15"
}

id=R，detailDate=D；每笔预订调用，不是按确认号查询。当前自动数据入口使用POST的searchRateInfo，未使用GET的getRateInfo。不传币种或指定价格数值；从返回数据取有效价及币种并核对，隐藏/缺失价格不当成零。

4. 主客姓名摘要 — searchProfiles

用途：取得唯一主客的完整显示姓名，并与预订中的姓名组成核对。

POST /api/v1/profiles/searches，正文：

{
  "profileIds": ["P456"],
  "summaryInfo": true,
  "limit": 1,
  "offset": 0
}

profileIds=[P]，每次只查已关联主客的精确档案ID；不按姓名模糊搜索、不查询全部住客或陪同人。相同档案的同类查询可在本次采集中复用。

5. 档案详情补查 — getProfile

用途：预订内主客姓名结构不完整，或关联档案未嵌入公司名称时，补取已知档案。

GET /api/v1/profiles/{P}，无额外查询参数、无正文。

不是每笔必调；公司/旅行社/Source/Group关联按原角色保留，最终公司名称仅从Company/TravelAgent中取。存在多个不同公司/旅行社名称时保留多候选异常，当前不擅自规定优先级。

6. 团队代码补查 — getBlock

用途：预订已明确关联团队B，但没有可直接使用的团队代码时补查。

GET /api/v1/blocks/{B}?fetchInstructions=Block，无正文。

已有明确且一致的团队代码时不补查；没有团队关联不凭空查团队。明确代码冲突不会被补查静默覆盖。

7. 房间和换房历史补查 — getRoomCalendar

用途：详情仍无法确定房号时，取得D的房间资料，再在本地按R匹配需要补查的预订。

GET /api/v1/reservations/room-calendar，首个请求的查询参数：

startDate=D
endDate=D
includeRoomMoveHistory=true
showRoomMoveSegments=true

首个请求不传pageIndex和recordsPerPage。
若返回尚未完整，后续增加pageIndex=上一页返回的pageIndex+1、recordsPerPage=返回的每页条数，其余条件不变。
没有向该接口传预订ID或房号筛选，程序读取返回的房间集合后按R匹配；不是每一笔缺房号都重新查一遍全酒店。
已有明确房号或明确为空的记录不触发这项补查；历史有多个不同房号且无法唯一确定时保留异常。

8. 套餐详情补查 — getPackage

用途：预订已有套餐代码C，但未给出scheduleList时补齐套餐适用资料。

GET /api/v1/reservations/{R}/packages，查询参数：

productCode=C
reservationTimeSpanStartDate=D
reservationTimeSpanEndDate=E
fetchInstructions=Primary
fetchInstructions=Schedule

无正文；fetchInstructions重复传两项。起止日期覆盖该预订入住到离店，这一项的结束日期是E，不是D。有多个需补查的套餐时逐个代码查询；已有scheduleList（包括明确空列表）时不调用补查。

调用次数和无数据行为

8个指8种接口，不是每次下载只发8次请求。列表需要分页并在末尾复查；详情、房价、姓名按预订/档案查询；其余按条件补查。当前本机默认每页100条、最多100页/10000笔预订，单次采集最多25000次HTTP尝试；单请求超时25秒，符合条件的暂时失败最多尝试3次。这些是本地处理上限，只有各接口表中列出的分页值会作为查询参数传出。如果列表没有任何预订，当前程序以empty_source_requires_review结束采集，不自动生成零条日报。

本次请确认的业务范围

项目	当前实现
日期范围	所选日到店；详情日价/房间历史针对所选日，套餐针对完整入住期间
客人范围	姓名使用唯一主客档案，不逐一查陪同人姓名
取数与加工	先取数据，再使用原白名单、去重和定价规则；不请求XML，不获取Trace
状态覆盖	没有显式传全部预订/分房状态，需要核对平台默认范围，不能把这一点算作全状态验收通过
备注覆盖	请求Comments后提取GEN并保留内部备注；接口默认是否返回完整所需备注未实测
公司与房号冲突	保留异常，不自行选择公司优先级或随意选一个换房房号

本次仅核对现有参数，未改变查询范围和业务规则。参数样例中的R123/P456/B789/PKG1是虚构标识；通过实际请求构造函数在本机生成，无网络、密钥读取或真实业务调用。

实现依据：请求封装、调用与补查条件、预订查询及连接、房价请求、姓名摘要请求。

8.9 KiB Raw Blame History Unescape Escape