Page Comparison

Audience

This document is intended for use by property management systems 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.

Overview

The Generic HTNG Product Distribution (GenHTNG) Interface is based on HTNG specifications – see Reference Documents – whose foundations are the OTA XML schemas. The interface has not yet been certified by HTNG.

The GenHTNG Interface enables the Windsurfer® CRS to communicate with PMS software using OTA-compliant XML message sets over a variety of transport protocols. The interface supports the exchange of:

• Reservations

• Rate

• Inventory

• Sell Limits

• Open / Close Availability Status

• Minimum and Maximum Length of Stay

• Non-room items (Add-ons or service items)

• Group Blocks

Document Overview

The GenHTNG 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.

The following are the endpoints for the SHR GenHTNG API:

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:

...

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

• Password – a secure password corresponding to the user name 

Communication Pattern and SOAP Actions and Headers

The GenHTNG Interface uses a communication pattern called the “HTNG Asynchronous Communication Process”. This process is described in detail in section 4 of the HTNG Property Web Services Specification Release 2009B.

...

All messages are generated as per the SOAP 1.2 specification using WS-Addressing 1.0 and HTNG 2.1 Headers. WS-Security headers are used. The sending system must provide the mandatory credentials necessary for consuming the Services being offered to the receiving system.

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<n1:Envelope xmlns:xsin1= "http://www.w3.org/20012003/05/XMLSchemasoap-instanceenvelope" xmlns:xsdn3="http://wwwdocs.w3oasis-open.org/wss/2001/XMLSchema";2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soapn2="http://schemaswww.xmlsoapw3.org/soap2005/envelope08/addressing";> <soap:Header>
<HTNGHeader xmlnsxmlns:n4="http://htng.org/1.1/Header/";PWSWG/2007/02/AsyncHeaders">
<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> <n1:Header>
		<n2:MessageID>{{MessageID}}</n2:MessageID>
		<n4:CorrelationID>2b36432943304e8d81ba5618d5df9e5a</n4:CorrelationID>
		<n2:Action>http://htng.org/PWSWG/2010/12/OTA_HotelResNotifRQ _SubmitRequest</n2:Action>
		<n2:To>https://uat.windsurfercrs.com/pms/genhtngservice.aspx</n2:To>
		<n2:ReplyTo>
			<n2:Address>http://www.w3.org/2005/08/addressing/role/anonymous</n2:Address>
		</n2:ReplyTo>
		<n3:Security mustUnderstand="1">
			<n3:UsernameToken>
				<n3:Username>{{UserName}}</n3:Username>
				<n3:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">{{Password}}</n3:Password>
			</n3:UsernameToken>
		</n3:Security>
		<n4:ReplyTo>
			<n2:Address>https://api-dev.protel.net/services/ProtelApiService.ProtelApiServiceHttpsSoap12Endpoint</n2:Address>
		</n4:ReplyTo>
	</n1:Header>

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>

HTNG Compliance

This interface will adhere to the HTNG Product Distribution Specifications Release 2013A, Issue 1 (April 23, 2010) and will support the HTNG 2.1 Framework in the following respects:

• Soap 1.2 envelope

• WS-Addressing 1.0

• WS Security (using Username/Password credentials) – WS Security requires use of https transport.

• Asynchronous Or Synchronous communication model

 There is currently no capability to produce a “wsdl” file. Schemas may be obtained from the Open Travel Alliance.

HTNG

...

Communication Process

The pattern is implemented using separate correlated asynchronous OR synchronous web service calls (call) for each HTNG message exchange. HTNG messages are always a request RQ and response (RS) message pair.

The exchange of a message pair starts a 5 stage (if successful) process.

Response to Inbound Requests:

Sync Response : Inbound request from PMS is processed and an immediate response is sent for that request.
Async Response : Inbound request from PMS and send the response to provided URL.
( In this case PMS provides the endpoint URL , on which response will be sent. This URL must be present in the CRS setup.)

Outbound Request from CRS to PMS (Reservations)

For response from PMS to the outbound request from CRS, Sync or Async response can be supported.

Sync Response: PMS needs to send an immediate response to the request.

Async Response: PMS needs to send response to the provided GenHTNG endpoint (which is also used to send inbound requests from PMS)

Reference Documents

...

Summary

...

...