Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

Audience

This document is intended for use by distribution channels and their development teams that wish to connect to Windsurfer CRS properties.

The reader should be familiar with technologies supporting web services, XML and SOAP.

Product Overview

The Channel Manager Push Interface is based on HTNG specifications whose foundations are the OTA XML schemas. The interface has not yet been certified by HTNG.

The API enables web-based distribution systems – i.e., online booking channels – within the hospitality industry to receive ARI information directly from Windsurfer® CRS. This is a one-way push from CRS to the OTA or receiving system.

The technical feasibility of the integrations must be established prior to working on detailed development and testing work.

·        ARI – Windsurfer CRS is to PUSH the ARI to external channel. All data processing on Windsurfer CRS end would be real-time and the expectation is for the partner to handle information on real time basis.

·        Reservations – Similarly external channel would PUSH reservation out to the Windsurfer CRS.

Windsurfer CRS will return a response to each request in synchronous mode, which is simply defined as a request/response over the same channel.

 

Document Overview

The Booking Engine API document is separated into sections that define the SOAP header, reservation request/response, and real-time property-specific availability requests.

The document defines the business rules, supported message formats and corresponding supported data elements and the expected behavior of participating systems and should be used as a guide to developers for the implementation of message sets. 

Web Services

The participating partner site/channel will be provided with the web service that enables the partner to send messages to the CRS.

The partner will need to provide a web service with which the CRS can communicate responses to availability requests.

Authentication

Participating partner sites/channels will be obligated to provide appropriate credentials, as defined in the SOAP header, to utilize the CRS web services. Credentials include:

  • System ID – a unique identifier of the partner organization

  • User Name [ID] – a unique login name for authentication

  • Password – a secure password corresponding to the user name 

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

SOAP messages are contained within an envelope that, in turn, contains a header and a body. The header contains the communication information of the message whereas the body contains the primary content of the message.

SOAP faults will be provided as the mechanism for handling error conditions.

The payload, which is based on specific OTA 2006B XML schemas, is the business or application content of the message that corresponds to the specific transaction being invoked. One payload per envelope is assumed.

Sample SOAP envelope

The following is an example of a SOAP envelope containing the HTNG header used for authentication:

<?xml version="1.0" encoding="UTF-8" ?>
<soap:Envelope xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
<soap:Header>
<HTNGHeader xmlns="http://htng.org/1.1/Header/";>
<From>
<systemId="145124">
<Credential>
<userName="partner">
<password="a1b2c3"/>
</Credential>
</From>
<To>
<systemId="Windsurfer"/>
</To>
<timestamp>date</timestamp>
<echoToken />
<transactionId />
<action />
</HTNGHeader>
</soap:Header>
<soap:Body>
</soap:Body>
</soap:Envelope>

 

SOAP Fault Handling [Errors]

If a SOAP error occurs during processing, the SOAP body must contain a SOAP Fault element. Note that the Fault element can only appear once in a SOAP message. Therefore, only the first error encountered is reported. An accompanying fault string attribute shall contain a detailed description of the specific error.

The following is an example of an “Invalid username” fault:

<soap:Body>
<soap:Fault>
<faultcode>soap-env:Client.2008</faultcode>
<faultstring>Authentication error – Invalid username</faultstring>
</soap-env:Fault>
</soap:Body>

 

  • No labels