Interface requirements
Connectivity options
The following are options available to the BSP for connecting to the RateGain Online Distribution Network.
Connection Type
Hardware Requirements
Encryption
Other Requirements
Customer Responsibilities
Client SSL (Internet based)
None
Software Based
SSL toolkit, RSA cipher license, connection to the Internet
All
VPN (Internet based)
VPN router Preferred router: Cisco Also supported: Checkpoint, Netscreen, Nortel, Watchguard
Hardware Based
Connection to the Internet
Configuration, installation and ongoing support of VPN equipment on their end
Frame Relay (Dedicated line)
Cisco 1604-R router with serial port, ISDN BRI port, and one Ethernet port
Not Required
Telco connection
Dependent on level of connectivity service selected
Transport layer
The UD services are accessed using standard HTTP 1.1 requests sent to a web server on the RateGain Online Distribution Network.
A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.
Request = Request-Line CRLF *( request-header CRLF) CRLF [ message-body ]
HTTP request line
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. Request-Line = Method SP Request-URI SP HTTP-Version CRLF
UD can support either the “GET” or “POST” request method. However, it is recommended to use the POST” method.
Post request method
For a POST request, the URI should be as follows.
Request-URI = “/apps/TransactionInterfaceV1_1/DispatcherServlet”
Here is an example Request-Line using the POST method.
POST /apps/TransactionInterfaceV1_1/DispatcherServlet HTTP/1.1
GET request method
For a GET request, the URI needs to include a request parameter containing the XML message. This parameter should be named “xml”.
For a GET request, the URI should be as follows.
Request-URI = “/apps/TransactionInterfaceV1_1/DispatcherServlet?xml=” XML-Request
Here is an example Request-Line using the GET method.
GET /apps/TransactionInterfaceV1_1/DispatcherServlet?xml=<?xml version=”1.0”?><HotelML>...</HotelML> HTTP/1.1
Warning: Control characters, spaces, “reserved” and “unsafe” characters must be escaped replaced by their ""%" HEX HEX" encoding when sent within a URI. Characters other than those in the "reserved" and "unsafe" sets.
HTTP request header fields
Following the request line are the request header fields. The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server. request-header = Host | Referer | User-Agent | Content-Length | Content-Type | Connection
The following table lays out the required fields and explains their use.
Field Name
Format
Example
Description
Host
Host: URI host server
Host: twbtest.thisco.com:4321
The destination host name, including the port number.
Referrer
Referrer: (absolute URI | relative URI)
Contains the identifier of the page on the BSP side where the request originated. Optional field
User-Agent
User-Agent: 1*(product | comment)
User-Agent: BSP_X/2.0
An identifier of the application used to make the request ( The name and version of the application making the request.) Optional field.
Content-Type
Content-Type: media-type
Content-Type: text/xml
Contains the type of the data being sent. Not required for “GET” requests.
Content-Length
Content-Length: 1*Digit
Content-Length: 250
Contains the length of the data block being posted. Not required for “GET” requests.
Example
POST /apps/TransactionInterfaceV1_1/DispatcherServlet
HTTP/1.1 Referrer: http://www.somebsp.com/search_page.html
User-Agent: BSP_name_here
Host: twbtest.thisco.com:4321
Content-type: text/xml; charset=UTF-8
Content-length: 40
<?xml version=”1.0”?>
<HotelML>
</HotelML>
HTTP response header fields
Following the response line are the response header fields. The following table lays out the required fields and explains their use.
Field Name
Format
Example
Description
Server
Server: 1*( product | comment)
Server: Netscape-Enterprise/4.1
Date
Date : HTTP-date
Date: Tue, 15 Nov 1998 08:12:31 GMT
Content-Type
Content-Type: media-type
Content-Type: text/xml
Contains the type of the data being returned.
Content-Length
Content-Length: 1*Digit
Content-Length: 250
Contains the length of the message returned (in bytes).
Example HTTP/1.1 200 OK Server: Netscape-Enterprise/4.1 Date: Mon, 20 Sep 1999 15:58:22 GMT Content-Length: 4259 Content-Type: text/xml <?xml version=”1.0”?> <HotelML> …</HotelML>
HTTP error codes
If the Transaction Interface service is unavailable, an error code of “504 Could not connect to requested service” will be returned to the client.
BSP reservation database
Warning: The BSP must host a database to store reservations; both booked and cancelled, so that their customer support and/or customers can retrieve the reservations after booking for review and/or cancellation!
The data housed in this database should include all information required to perform a cancellation, as well as any information that might be of importance to the customer such as cancellation policy and rate changes during stay. It is also recommended that confirmation and cancellation emails be generated to the customer at transaction time from this database.
Transaction logging
It is recommended that all booking request and response messages are logged and maintained by the BSP for at least 6 months for customer support purposes.
Copyright requirements
Each page of the BSPs web site where the data displayed is being obtained from RateGain must contain the text “Powered by RateGain”, or display the "Powered by RateGain" logo.
Fraud prevention
UltraDirect does not impose any limits on the number of bookings that can be made per user, per hotel, or per chain. However, we highly recommend that the BSP impose some level of booking limitation to help prevent abuse of the system. For example, limit the number of bookings made to a single credit card number for each chain code for a given period of time. Steps should also be taken to prevent inadvertent duplicate bookings by a user.
Timeouts
The Affiliate can request a particular timeout value for every transaction by utilizing the Timeout attribute of the Process element. This relative value is expressed in milliseconds and is selectively used to provide RateGain applications the detail needed to efficiently process transactions and control transaction flow. If a transaction is not successfully processed by a transaction processor that supports variable timeouts by the timeout value supplied, a timeout response will be generated by the RateGain environment and returned to the Affiliate.
Setting the Timeout attribute in the Process element of a UltraDirect request is strongly encouraged, but a timeout response is not guaranteed to occur before the timer has elapsed. However, responses are generally returned prior to the expiration of the countdown timer. A common timeout value for an availability transaction is 15,000 ms. Please note that the countdown timer does not take into account network latency, parse, or format delays.
When the expected response time communicated in the Timeout attribute is not successfully processed by a transaction processor, it is important to note that there are several cascading timeout values from the UltraDirect system to the Hotel Reservation System. RateGain recommends a 150 second internal timeout value in order to avoid the unique situations where an Affiliate discontinues a transaction that the Hotel Reservation System considers "active". The most prevalent concern for this unique scenario would be a booking transaction that the Affiliate has abandoned while the Hotel Reservation System decrements inventory. This will result in a reservation that the Affiliate has no record of existing.
Last updated