The EST transaction allows specific types of rates to be requested, such as negotiated, corporate or standard rate plans. The rates associated with a requested rate plan will be identified in the response using the same rate plan code that was sent in the request, together with the status of the requested rate plan.
The following is an example of requesting two standard rate plans: “SNR” (Senior) and “PRO” (Promotional). It also includes a corporate rate plan code “CR1” and associated corporate customer number 12345678, which is only applicable to properties in the XY chain (as defined by the BrandCode attribute of the RateSearch element). The corporate rate plan code and customer number will only be included in transactions to the XY chain’s CRS (i.e. for property XY;54321 in this example).
The MatchingQualifier attribute also specifies that the response should include these and any other public rates. The request only includes one hotel for brevity.
For the property UI;12345 the response below shows:
The “SNR” rate plan is unavailable
Rate plan code “T78B” matches the requested “PRO” rate plan and is available. Note that several different rate plans codes in the response may match the requested rate plan, although this example just shows one.
Rate plan code “013A” does not have a RequestedRatePlan attribute and so is a ‘public’ rate that was not specifically requested.
For the property XY;54321 the response below shows:
The “SNR” and “PRO” rate plans are unavailable
The corporate rate plan code CR1 is available. The same rate plan code is used in the request and the response (i.e. there is no mapping for this rate plan code in the CRS).
The above messages include an example of corporate rates. There are two ways in which corporate rates can be requested, which are described below:
Option 1: Use the exact code as required by the hotel
Once the special rate has been negotiated with a chain, the hotel will tell the affiiliate which RatePlanCode to use within the request to invoke the negotiated rate. For example, for negotiated rates with Marriott (MC) the RatePlanCode may be ‘MMM”; while for negotiated rates for Best Western (BW), they may advise to use
the RatePlanCode “BWB” as well as pass the CorpInfo/@Code of “12345”. So if the request is for Marriott, the affiliate would have to pass “MMM”; if the request is for Best Western they would have to use “BWB” and “12345”. The RatePlanType is also required. This would typically be “Standard” or “Corporate” (depending on what the CRS requires) but not “Negotiated” because that is only used for Option 2, below.
RateGain will set up a 3 character negotiated rate plan code, such a “NG1”, for the affiliate to use regardless of hotel chain. The affiliate would advise the hotel chains of their negotiated rate code so that the chains can correctly configure that rates usng the RateGain Account Author tool. The chains would then load and enable access to your negotiated rates in their CRS, as well as set up access to the rates in Account Author. Account Author setup includes authorization for the affiliate to access the NG1 rate code for their brand(s) and translation of that code to their chain-specific rate plan code which will be passed in the transactions sent to them.
Using the above example for Marriott and Best Western, the RatePlanCode will be set to “NG1” and RatePlanType to “Negotiated” regardless of the chain, as shown below:
If a requested property is not available then a Property element is returned with an AvailabilityStatus set to “Closed”. It will also include the ClosedReason attribute to indicate why it is closed. An Error element will also be returned, which often provides addition information. The ResponseDataPath attribute of the Error error will include a reference to the specific property ID.
The following is an (edited) example response for a request for three properties where one is unavailable:
The UltraDirect Availability Cache functionality may be used to obtain the rate and availability information for properties in the EST response. Cached single property availability responses may be used by UltraDirect to generate multi-property availability responses and vice versa.
The RequestedAccuracy attribute of the Route element in the message header can be used to specify whether or not the cache should be used. In the following example, the affiliate indicates that responses can either be from the cache or the source (i.e. the hotel’s CRS).
The response message then indicates for each property whether the information was returned from the cache or source. It also indicates the ‘age’ of the response by providing a timestamp of when the response was created. If it was returned from the cache then the age would be the timestamp for when the response was originally added to the cache. An example is shown below:
If the requested accuracy is not available for a requested property then the Property element is returned with AvailabilityStatus set to “Unknown”. For example, if the previous request message was changed so that RequestedAccuracy=”CacheOnly” and there is no matching transaction in the cache for property UI;54321 then the response would be as follows:
Affiliates can specify their own timeout value in the MultiAvailability request, which will ensure that they do not have to wait for slow CRSs before receiving a response. The Timeout attribute of the Process element in the message is used for this purpose.
UltraDirect also has a standard timeout value that specifies the maximum time it will wait for a response from the CRS, which is currently set to 15 (fifteen) seconds. The timeout value specified by the affiliate must be less than the UltraDirect value (if it is longer, the UltraDirect value will be used instead).
The affiliate can also specify whether they accept multipart responses from UltraDirect by setting HotelML/Head/Process/AcceptMultipartResponse=”true”. If this is set, UltraDirect may return the response in two parts – the first contains properties for which results have been obtained when the affiliate-specified timeout expires and the second part contains results for the remaining properties. These two responses are implemented using the ‘chunked’ transfer encoding mechanism in HTTP/1.1.
The timeout and multipart response functionality is only available when enhanced MultiAvailability is requested (i.e. by setting RateCriteria/@VersionCompliance=” Enhanced_V1”).
The following flowchart specifies the logic that is used to decide whether one or two responses are returned:
The following example request message specifies that the affiliate requires a response within 2 seconds and it will accept multiple responses (i.e. chunked HTTP transfer encoding).
In this scenario, assume that only the first 3 properties have responded within 2 seconds. The HTTP/1.1 response will include the following header to denote that this is a multi-part response:
Transfer-Encoding: chunked
The first part (chunk) will contain the following complete HotelML message:
Now assume that results are subsequently obtained for YY;4444 but there was no response from the CRS of brand ZZ by the time the standard UltraDirect timeout expired (13 seconds after the first response; 15 seconds in total). Therefore the second chunk would contain the following:
Note that the StartTime attribute of Operation for the two responses are the same (i.e. the start time of the transaction) but the TotalProcessTime for the second response is the time to process the second response, not the total processing time for the whole transaction.
Finally, a zero content-length third chunk will be returned to denote the end of the HTTP response. Another example is shown below. In this scenario, the affiliate has specified a timeout of 5 seconds but they only want a single response (AcceptMultipartResponse="false").
Notice that this is different from the first response in the example of a chunked response given previously i.e. it contains a Property element for every property in the request message, whereas the first chunked response only had Property elements for properties that had returned results.
Language Processing
It is possible to specify the preferred language to be used for room/rate/policy descriptive text fields in the response by using the Locale element.
An example message that requests responses in French is shown below:
If the hotel’s CRS supports the requested language (as defined in the RateGain configuration details for the hotel chain) then RateGain will pass the requested language code to the CRS, which should then return the information in the requested language if available for the property; otherwise it will return it in English or the hotel’s native language.
However, if the hotel’s CRS does not support the requested language, RateGain will change the requested language code to English when sending the transaction to the hotel’s CRS.
Since a hotel’s CRS may return the response in an ‘alternate’ language which is neither the requested language nor English (e.g. the hotel’s native language), RateGain can also configure for each UltraDirect affiliate whether or not they can accept responses in an alternate language. In the following example response, the affiliate is configured to only accept responses in the requested language or English – so for property UA;98765 (which returned the response in, say, German), it returns an error and an AvailabilityStatus of “Unknown”. For property XX;1234 the response is returned in the requested language (French) and property UI;12345 is returned in English because French is not available.
<HotelML xmlns="
http://www.xpegs.com/v2001Q3/HotelML
" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-
instance">
<Head>
<Route Destination="01" Source="00">
<Operation Action="Create" App="TIDispatcher" AppVer="1.12.40.2.8.1" DataPath="/HotelML" StartTime="2010- 06-07T08:13:36.688+00:00" Success="true" TotalProcessTime="228"/>
</Route>
<Error Code="RLC10" Description="The returned language code does not match the language that was originally requested for property UA;98765" Type="Process"/>
</Head>
<Property xml:lang="fr" Code="XX;1234" Token="1016730128803" AvailabilityStatus="Open">
<Rate>
<RatePlan Code="RA1" CommissionableStatus="Commissionable" Description=" Le meilleur taux sans restriction" InDate="2010-07-01" OutDate="2010-07-05">
<RoomType BookableRate="89.00" Code="ROH" NativeCurrency="EUR" RateFrequency="Daily" RoomDescription=" Pièce pour la pièce de 1 à 2 personnes seulement, Pers-NT de déjeuner : 8.00 EUR " TotalRate="89.00" TotalRateInclusive="89.00">
<CommissionPolicy Amount="8.90"/>
<DepositPolicy Required="true" Amount="596.00" IntervalUnits="Days" TimeInterval="7" IntervalOffsetType="BeforeArrival">
<!-- Credit card -->
<GuaranteeMethod Code="5"/>
<!-- Travel Agency ID -->
<GuaranteeMethod Code="19"/>
</DepositPolicy>
<CancelPolicy Time="16:00:00.000"/>
</RoomType>
</RatePlan>
</Rate>
</Property>
<Property xml:lang="en" Code="UI;12345" Token="1275898416589" DataAge="2010-06-30-08T14:28:01.268-00:00" DataOrigin="Cache"
AvailabilityStatus="Open">
<Rate>
<RatePlan Code="013A" CommissionableStatus="Commissionable" Description="BEST FLEXIBLE RATE " InDate="2010-07-01" OutDate="2010-07-05" RequestedRatePlanCode="RAC" Status="Open" TaxInformation="INCLUDED" CredentialsRequired="true">
<Amenity xml:lang="en" Code="BRKFST" Room="true"/>
<RoomType BookableRate="165.00" TaxQualifier="Unknown" Code="1DN" NativeCurrency="GBP" RateChange="true" RateFrequency="Daily" RoomDescription="1 DOUBLE BED ENSUITE NONSMOKING " TotalRateInclusive="570.00" TotalRateInclusiveCharges="600.00" TotalTaxes="100.00" TotalSurcharges="30.00" NumberOfPayingGuestsPerRoom="1" NumberOfChildren="2" NumberOfBeds="1" BedType="Double" RoomCategory="Superior" RateCategoryMatchType="Alternative" RoomCountMatchType="Available" AdultCountMatchType="Allowed" ChildCountMatchType="Allowed" BedMatchType="Requested" CribMatchType="Available">
<CommissionPolicy Description="Commissionable rate" Percentage="7.00"/>
<GuaranteePolicy LateArrivalTime="16:00:00.000" Required="true">
<!-- Credit card -->
<GuaranteeMethod Code="5"/>
</GuaranteePolicy>
<CancelPolicy Date="2010-06-30" Time="16:00:00.000" PenaltyPercentage="50.00" PercentageQualifier="FullStay"/>
</RoomType>
</RatePlan>
<RatePlan Code="T78B" CommissionableStatus="Commissionable" Description="ADVANCE PURCHASE NO REFUNDS " InDate="2010-07-01" OutDate="2010-07-05" RequestedRatePlanCode="PRO" Status="Open" TaxInformation="INCLUDED" NonRefundableStay="true">
<Amenity xml:lang="en" Code="BRKFST" Room="true"/>
<RoomType BookableRate="149.00" Code="1DN" NativeCurrency="GBP" RateChange="true" RateFrequency="Daily" RoomDescription="1 DOUBLE BED ENSUITE NONSMOKING " TotalRateInclusive="515.00">
<CommissionPolicy Description="Commissionable rate" Amount="105.75"/>
<DepositPolicy Required="true" Amount="596.00" IntervalUnits="Days" TimeInterval="7" IntervalOffsetType="BeforeArrival">
<!-- Credit card -->
<GuaranteeMethod Code="5"/>
<!-- Travel Agency ID -->
<GuaranteeMethod Code="19"/>
</DepositPolicy>
<CancelPolicy Time="16:00:00.000"/>
</RoomType>
</RatePlan>
</Rate>
</Property>
<Property xml:lang="en" Code="UA;98765" Token="1275898416589" AvailabilityStatus="Unknown" >
</HotelML>
