Page Comparison

...

• Availability and Restrictions

• Inventory

• Rate Amounts

Integration Process Overview

In order to facilitate the integrations process both for the Integrations team at SHR and our partners, we have a standardized process for all integration projects. This process can be adapted to the needs of a specific integration, but vendors should expect the following guidelines to be true for their integration process.

Vendors will be working with the Integrations team throughout the integration process. Our team is available at integ@shr.global for support and inquiries.

Unless otherwise stated by a member of the Integrations team, every vendor will have a unique test property created for them in the Windsurfer® UAT environment for the purposes of testing and certification. As such, vendors should generally not use the example hotel codes provided in the code samples, but rather use the hotel code provided to them by the Integrations team.

Typically, integrations will begin with a kickoff call to ascertain the technical details relevant to the integration and reach mutual understandings about development timelines and any other information relevant to the integration process.

After the kickoff call, we encourage our integration partners to join a group chat (RingCentral, Microsoft Teams, Skype, or similar) to facilitate communication and prevent email clutter. We have found that this enables both parties to have more direct and focused communication.

Upon completion of the development process, SHR will provide a list of test cases for certification in our UAT environment. If a vendor receives a satisfactory result in the relevant test cases, they will be certified and available to SHR clients.

Document Overview

The GenRMS API document is separated into sections that define the various message types and use cases supported by the interface.

...

The following is the endpoint for our GenRMS test environment, to be used during testing and : https://uat.windsurfercrs.com/rmsweb/GenRMSInteg?HotelCode={HotelCode}.

...

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'?>
<n1:Envelope xmlns:n1="http://www.w3.org/2003/05/soap-envelope" xmlns:n3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:n2="http://www.w3.org/2005/08/addressing" xmlns:n4="http://htng.org/PWSWG/2007/02/AsyncHeaders">
    <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.

...