Technical Overview

Service

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.

Communication Protocols

The exchange of information between RG Bridge and PMS occurs through REST messages.

General Design

Availability and Rates Notification Service:

• Operations:

  1. Updating Inventory, Availability, and Restrictions:

     • OTA Messages:

       • Request: OTA_HotelAvailNotifRQ

       • Response: OTA_HotelAvailNotifRS

  2. Updating Rates (Base by GuestAmount and AdditionalGuestAmount):

     • OTA Messages:

       • Request: OTA_HotelRateAmountNotifRQ

       • Response: OTA_HotelRateAmountNotifRS

Authentication

• 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:

    Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

  • Content-Type: text/xml

Hotel Product Handling

• 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:

1. Determine all room type-rate type combinations affected by this change.

2. 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.

Reliability Mechanisms and Constraints

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.