Push API - ARI Message

Note: this page is a work in progress

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.

Operations - Availability and Inventory

This web service operation allows the Windsurfer CRS to request external channel to update the availability status, inventory count and restrictions of a hotels inventory. Two messages are used in this operation:

OTA_HotelAvailNotifRQ: It is the message sent by the OTA to the external channel to notify of any change in availability.

OTA_HotelAvailNotifRS: In response the external channel sends an OTA_HotelAvailNotifRS message (unless a SOAP level error occurs, in which case a SOAP fault message is sent).

Change Inventory Count

The inventory count update has to be sent separately on room type basis. It means there is only room type and no RatePlan information passed in the RQ message.

Sample Message:

<OTA_HotelAvailNotifRQ xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" EchoToken="2906892291" 
 TimeStamp="2020-04-28T13:58:02.6508395-06:00" Target="Production" 
 Version="1" xmlns="http://www.opentravel.org/OTA/2003/05">
      <AvailStatusMessages HotelCode="PSSN">
           <AvailStatusMessage BookingLimitMessageType="SetLimit" BookingLimit="17">
                <StatusApplicationControl Start="2020-04-28" End="2020-04-28" InvCode="RoomA" />
                  <UniqueID Type="16" ID="2906892291" />
           </AvailStatusMessage>
          <AvailStatusMessage BookingLimitMessageType="SetLimit" BookingLimit="18">
             <StatusApplicationControl Start="2020-04-29" End="2020-05-08" InvCode="RoomA" />
             <UniqueID Type="16" ID="2906892291" />
         </AvailStatusMessage>
   </AvailStatusMessages>
</OTA_HotelAvailNotifRQ>

Change in Availability Status and Restrictions

Any change in availability status or restrictions update should include both RoomType and RatePlan information.

Windsurfer CRS sends availability status and restrictions update at Product level (i.e. a RoomType + RatePlan). It is possible that multiple products are associated with a single room type.

Sample Message:

<OTA_HotelAvailNotifRQ xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
EchoToken="2901727514" TimeStamp="2020-01-31T17:00:39.344971-06:00" 
Target="Production" Version="1" xmlns="http://www.opentravel.org/OTA/2003/05">
  <AvailStatusMessages HotelCode="HTBEN">
    <AvailStatusMessage>
      <StatusApplicationControl Start="2020-03-31" End="2020-04-30" RatePlanCode="CHK" InvCode="KRO" />
          <LengthsOfStay>
                <LengthOfStay Time="1" TimeUnit="Day" MinMaxMessageType="SetMinLOS" />
                <LengthOfStay Time="1" TimeUnit="Day" MinMaxMessageType="SetForwardMinStay" />
           </LengthsOfStay>
       <RestrictionStatus Status="Open" />
    </AvailStatusMessage>
   </AvailStatusMessages>
</OTA_HotelAvailNotifRQ>

XML Usage Specification