Technical Overview
Last updated
Last updated
ARI (Availability, Rates, and Inventory) changes can be pushed to RG Bridge in real-time. In the push model, information is sent (pushed) by the system where the information originated. In contrast, in the pull model, the system needing the information periodically connects to access it. The push model's advantage for the PMS (Property Management System) is that it doesn't need to track all changes since the last pull.
The exchange of information between RG Bridge and PMS occurs through REST messages.
Availability and Rates Notification Service:
Operations:
Updating Inventory, Availability, and Restrictions:
OTA Messages:
Request: OTA_HotelAvailNotifRQ
Response: OTA_HotelAvailNotifRS
Updating Rates (Base by GuestAmount and AdditionalGuestAmount):
OTA Messages:
Request: OTA_HotelRateAmountNotifRQ
Response: OTA_HotelRateAmountNotifRS
Basic Authorization: All request messages exchanged between the PMS and RG Bridge must use basic authorization.
Credentials: Username and password need to be passed using basic authentication in HTTP headers.
Authorization Example:
Content-Type: text/xml
Differences in Categorization: There may be substantial differences in how RG Bridge categorizes hotel products compared to the PMS structure.
Understanding Differences: It's crucial to understand these differences to ensure successful integration.
RG Bridge defines hotel products as a combination of a room type and a rate type. A hotel can have many room types and rate types.
Rate Types Categorization: PMS systems typically classify rate types into different categories or segments.
Translation Requirement: The PMS must translate updates at the level of rate segments/rate categories into either room type level updates or product level updates before sending them to RG Bridge.
Example: If a PMS user updates the availability of the rate segment (Corporate Rate A) by changing the maximum available inventory count from 25 to 15, the PMS must:
Determine all room type-rate type combinations affected by this change.
Generate separate updates for each combination.
This design minimizes the effort required by the hotel to keep the inventory structure synchronized between the PMS and RG Bridge.
Single Hotel Specification:
Only one hotel can be specified in a request message.
Multiple Room Types Update:
Multiple room types for the same hotel can be updated in one message exchange.
Rate Type Handling:
If a rate type is not specified along with the room type in an update, the update is applied to all products defined for that room type.
Volume of Messages:
Due to the high volume of messages exchanged between RG and the PMS, it is essential to implement the reliability mechanisms and constraints described in Table B.
Type
Mechanism/Constraint
Description
Retry
Retry strategy for communication Failure and in case of specific errors returned in XML response
The Systems and PMS will have a retry mechanism in place for communication errors and business error.
Concurrency
Simultaneous connections per property <= 1
PMS RG Interface will establish a single connection per Property at any given time for updating the ARI events, and allows only one Connection per Property at a time for receiving the Booking Notifications.
Timeout
Time out after 60,000
milliseconds (1 minute)
Idle connections (no packets sent by either side) for
more than 1 minute are closed. These should be considered as incomplete and implement are try strategy to re-send data.
Character
Set
Support for UTF-8
All messages exchanged must have UTF-8 encoding
Hotels
Onlydatarelatedtoone hotel can be sent in a single request message
Room Types
Maximum number of
room types in a single request message must be less than 10
Rate Types
Maximum number of rate types in a single request message must be less than 10
Date Range
366 Days
Maximum number of days that a single request message could update must not exceed 366 days.
Message
Size
400 KB
Maximum size for a single message must not exceed 400 KB.
