Push API - ARI Message
Overview
Windsurfer CRS ARI changes are pushed in real-time to partners.
This interface has been developed to the HTNG Web Services Framework 2.1 specification as push model web services using the synchronous workflow. SOAP Versions 1.1 and 1.2 over HTTP are supported.
The exchange of information between Windsurfer and external channel happens through the exchange of SOAP messages. Each message is contained within a SOAP envelope. All messages must contain an HTNG specified Soap Header that complies with WS Security (authentication only) and WS- Addressing standards.
General Design
The Availability, Rates and Inventory Notification Service provides three primary operations; one for updating restrictions/availability, one for updating rates based on base by GuestAmount and AdditionalGuestAmount, another for the inventory at room type level.
Each operation involves the exchange of two OTA messages. Availability, Inventory and Restrictions are updated by sending an OTA_HotelAvailNotifRQ message and receiving an OTA_HotelAvailNotifRS message in response. Rates (BaseByGuestAmount / AdditionalGuestAmount) are updated by sending an OTA_HotelRateAmountNotifRQ and receiving an OTA_HotelRateAmountNotifRS in response.
Authentication
All request messages exchanged between the Windsurfer and partners must be authenticated using the WS-Security mechanism of the SOAP standards. This should conform to the specification of HTNG Web Services Framework 2.1.
SOAP Faults
SOAP Faults are provided as a mechanism for handling error conditions. A SOAP fault will be generated and returned if the message does not meet the web service specifications. It is also possible to receive this response occasionally, due to software malfunction on the Windsurfer side. The external channel system must be prepared to receive and process SOAP faults.
Hotel Product Handling
Windsurfer defines hotel products as a combination of a room type and a rate type. A hotel could have many room types and many rate types. Windsurfer CRS will classify rate types into different categories or segments. Windsurfer translates updates from OTA in real-time at the level of rate segments/rate categories to either a set of room type level updates or a set of product level updates before sending them to external channel.
For example, if a OTA user updates the availability of the rate segment (Promotion A) by changing the minimal length of stay (Min LOS) from 2 to 3. Windsurfer CRS will determine which all room type - rate type combinations are affected by the change and generate separate updates for each one of them. This design minimizes the effort required by the hotel to keep the inventory structure synchronized between the OTA and CRS.
Reliability Mechanisms and Constraints
Only one hotel can be specified in a request message. Multiple room types/rate codes for the same hotel can be updated in one message exchange. 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.
Since the volume of messages exchanged between the Windsurfer and external channel, the mechanisms and constraints described below must be implemented.
Type | Mechanism/Constraint | Description |
Retry | Retry strategy for communication failure and in case of specific errors returned in XML response | Windsurfer CRS and external channel will have a retry mechanism in place for communication errors and business error. |
Concurrency | Simultaneous connections per property <= 1 | Property at any given time for updating the ARI events, and allows only one connection per property at a time for receiving booking notifications. |
Timeout | Time out after 60,000 milliseconds (1 minute) | Idle connections (no packets sent by either side) for more than one minute are closed. These should be considered as incomplete and implement a retry strategy to re-send data. |
Character Set | Support for UTF-8 | All messages exchanged must have UTF-8 encoding |
Hotels | Only data related to one hotel can be sent in a single request message |
|
Date Range | 720 Days | Maximum number of days that a single request message could update must not exceed 720 days |