Technical overview
Last updated
Last updated
Connected Model:
This interface is designed to be used in a connected model where partner systems should always be available to receive reservations.
Push-Model Web Service:
As part of the integration, CRS/PMS partners should develop a push-model web service that meets the described standards and make it available to RG Bridge.
In the push model, information is sent (pushed) by the system on which the information originated.
Pull Model:
In contrast, the pull model involves the system that needs the information accessing it by periodically connecting to it.
Advantages of the Push Model:
The push model eliminates the need for partners to periodically access RG Bridge to check for new reservations, ensuring seamless and real-time updates.
Primary Operation:
Reservation Notifications: RG Bridge will send reservations downloaded from OTAs to PMS using reservation notification request messages.
Each reservation notification request will hold a single reservation record.
PMS will respond with either:
A success response with a PMS confirmation code.
An error response with reasons for failure.
Message Exchange:
New, Modified, and Canceled Reservations: All are pushed by sending OTA_HotelResNotifRQ messages and receiving OTA_HotelResNotifRS messages in response.
This streamlined process minimizes the effort required by the PMS to implement the services, ensuring efficient and accurate handling of reservation notifications.
Connectivity:
The connectivity supports REST communication mode for exchanging messages between the RG Bridge interface and partner system.
REST Connectivity:
Clients have the option of implementing HTTP Basic Authentication for message exchange.
Service Credential: Username and password need to be passed using basic authorization in HTTP headers.
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
The Content-Type used as text/xml.
It's crucial to grasp how RG Bridge processes reservations to ensure a successful integration with your PMS.
Split Mode:
Partners opting for split mode configuration will receive split/leg reservation messages per room count booked in a reservation.
Example: If a reservation is booked for 2 rooms, the partner will receive:
ResvID#1(1/2)
ResvID#1(2/2)
Each with different confirmation numbers returned from the partner in response.
Full Mode:
In full mode configuration, only 1 reservation is delivered containing all room information in a single message.
This reservation will be saved using the same confirmation number in the partner system.
OTA Handling:
OTAs handle reservation modifications in various ways. Many use the “Cancellation against Modification” (CAM) process, where modifications are delivered as a pair of Cancel and New reservations.
Some OTAs might deliver modifications directly without the CAM process.
PMS Handling:
The PMS should be capable of handling both methods of modification (CAM and direct modifications).
This flexibility ensures that the reservation delivery system can accommodate different scenarios, providing accurate and efficient reservation management
Given the high volume of messages exchanged between the RG Bridge and the PMS, it is essential to implement the mechanisms and constraints described in Table B to ensure efficient and reliable communication.
Reliability mechanisms and constraints
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
Reservation
Information
Support reservations accept reservations with minimum information
There is great variation in the structure and amount of information available in reservations retrieved from OTAs. The PMS should be able to process reservations with the minimum amount of information.
Reservation
Information
Support reservations delivered to DEFAULTROOM
and DEFAULTRATE
Occasionally, reservations would be retrieved from OTAs which cannot be mapped to any existing room/rate types on RG Bridge. RG Bridge will deliver these reservations with Room type code set to “DEFAULTROOM” and Rate Type code set to “DEFAULTRATE”. PMS should be able to accept such reservations.
Payment
Information
Support one-time delivery of
credit card information
To comply with PCI standards, many OTAs and consequently RG Bridge, deliver credit card information only once. PMS should be able to accept modifications and cancellations of reservations without credit card information.
