Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

protel uses protel I/O to route incoming and outbound data messages. Messages can be delivered to protel I/O from an HTTPS endpoint or via a Websocket. protel I/O provides different endpoints for synchronous and asynchronous SOAP 1.2 messages to accommodate WSDL requirements.
Systems send messages to protel I/O using HTTP endpoints.
In addition, protel I/O requires some information in the message headeris using the Version 'OTA 2011A' for the OTA messages.




Security, Access,

+

and Authentication

Security is important to you and protel. All messages must be authenticated using protel IO’s secure authentication processes. To ensure the source of messages are valid, all messages flowing to and from protel are checked. Messages are verified by protel I/O

  1. Who can send messages

  2. What messages they can send

  3. Where they can send to and receive from

Access to the API is only permitted through SSL (secure sockets layer). For HTNG messaging, all messages will utilize the HTNG 1.2 .1 SOAP header.



Authentication of Inbound messages

Direction Vendor to protel. All messages require a protel provided Bearer Token (whether RQ or RS!). 

The Authentication token can must be submitted in HTTP headers and SOAP headers. If the token can be found in more than one of these places, the SOAP header has the higher priority than the HTTP header. The place with the highest priority that has the token set determines which is used and which is ignored. 

Protel will provide you with your bearer token at the time we commence testing. When requesting a test environment protel will provide you with a token at that time.

protel Access Token

For API access, each service connecting to a hotel will have it’s own access token.

Codeblock
languagexml
titleBearer Token
Authorization: Bearer <HOTEL_TOKEN>

Authentication is specific in each case and requires partner applications to provide this access token with each API request message. This access token is provided by protel. protel authenticates this access token before allowing any actions to be taken

.

Format of Headers

You must send HTTP headers. There are 2 mandatory HTTP header parameters



Format of HTTP Headers

In order to process your incoming requests, all of your messages must contain headers inside the HTTP headers

HTTP HeaderDescriptionOccurrence
Content-TypeFixed to "application/soap+xml"Mandatory
SOAPActionPlease check the table below for the correct valueMandatory
AuthorizationThe access token e.g. "Bearer C6MmpEFjRRSy288V1-DEMO-hGETMBImNJhFzv5"Mandatory
CorrelationIDThe CorrelationID of the message you are sending to identify the transactionOptional


Codeblock
languagexml
titleHeader Format
Content-Type: application/soap+xml; charset=utf-8 +
SOAPAction: OTA_HotelResNotifRQ

The Authorization (Bearer) token is generated for your service when installed and sent to you using a secure method. It can be either in the HTTP header or in the SOAP Header

 Authorization is not mandatory in the HTTP header. However it is preferred. It should be like this in the HTTP header

Codeblock
languagexml
titleBearer token
Authorization
Authorization: Bearer C6MmpEFjRRSy288V1hGETMBImNJhFzv5

Or it can be in the SOAP header, like this

...

languagexml
titleToken In the SOAP header
C6MmpEFjRRSy288V1-DEMO-hGETMBImNJhFzv5
CorrelationID: RES#047616#UPDATE#000025#1594029290242#546D

SOAPAction

Messages sent to Protel IO (ESB)

...


OTAHTNGIO
RequestSOAPAction

...

htng.org/PWSWG/2010/12/OTA_HotelResNotifRQ_SubmitRequest"SOAPAction : "http://htng.org/PWSWG/2010/12/HTNG_HotelCheckInNotifRQ_SubmitRequest"SOAPAction : "IO_StatsNotifRQ
ResponseSOAPAction : "OTA_HotelResNotifRS"SOAPAction : "HTNG_HotelCheckInNotifRS"SOAPAction : "IO_StatsNotifRS"

Format of SOAP Environment

In order to process your incoming requests, all of your messages must contain headers inside the SOAP environment

Info
titleNote!

We do not support the Action parameter in the HTTP header but we rely upon the official message name OTA/HTNG*RQ/RS sent in the HTTP Header as the SOAPAction parmeter.

Codeblock
languagexml
titleSOAPAction
SOAPAction: <MethodName>
Info
titleNote!

You should send a Correlation ID in the HTTP header

Codeblock
languagexml
titleCorrelation ID
CorrelationID: <ID_for_the_message_exchange>

We use the HTTP Headers as a location for these parameters, to keep it easy and have the important information at hand before even reading the xml document.

Info
titleNote!

There is no mandatory SOAPHeader for ASYNC communication - if you dont provide a CorrelationID - then protel I/O will generate it for you.

If header information is sent using the SOAP header, the elements have to use the XML namespace

...

languagexml
titleXML Namespace

...

ElementNamespaceDescriptionOccurrence
Envelopehttp://www.w3.org/2003/05/soap-envelope-Mandatory
Envelope / Headerhttp://www.w3.org/2003/05/soap-envelopeContains the SOAP headers of the messageMandatory
Envelope / Header / Actionhttp://protel.io/soapThe required action (Message name) e.g. "OTA_HotelResNotifRQ"Optional
Envelope / Header / CorrelationIDhttp://protel.io/soapThe CorrelationID of the message you are sending to identify the transaction (protel namespace)Mandatory
Envelope / Header / Source

...

The Source of the message (Only outbound from protel to vendor)Optional
Envelope / Header / CorrelationIDhttp://htng.org/PWSWG/2007/02/AsyncHeadersThe CorrelationID of the message you are sending to identify the transaction (HTNG namespace)Mandatory
Envelope / Header / Targethttp://protel.io/soap

The desired target service name of the message

For message/s to protel PMS the correct values are:

  • io.protel.air - for protel Cloud PMS
  • io.protel.onpremise - for protel onPremise PMS
  • io.protel.pms - for either of the two above. The value is an alias that is valid for either of the PMSes
Mandatory
Envelope / Bodyhttp://www.w3.org/2003/05/soap-envelopeThe HTNG/OTA/IO messageMandatory

There is only 1 mandatory SOAPHeader for SYNC communication. Protel prefers to not use sync message patterns, due to scalability concerns. 

Codeblock
languagexml
titleTarget
`p:Target`

Example: Mandatory HTTP headers parameters for Inbound messages

Codeblock
languagexml
titleMandatory HTTP Header parameters
HTTP Header: Accept: application/soap+xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
HTTP Header: Content-Type: application/soap+xml
HTTP Header: SOAPAction: OTA_HotelAvailNotifRS
HTTP Header: Authorization: Bearer C6MmpEFjRRSy288V1hGETMBImNJhFzv5

...


Codeblock
languagexml
titleOptional Soap HeadersSOAP Env
<?xml version='1.0' encoding='utf-8'?>
<env<soapenv:Envelope xmlns:soapenvenv="http://www.w3.org/2003/05/soap-envelope">
    <soapenv	<env:Header>
        		<p:Action xmlns:p="http://protel.io/soap">$1 OTA>OTA_HotelAvailNotifRS<HotelResNotifRQ</p:Action>
		<p:CorrelationID xmlns:p="http://protel.io/soap">RES#047616#UPDATE#000025#1594029290242#546D</p:CorrelationID>
		<p:Source xmlns:p="http://protel.io/soap" Module="backline" ModuleVersion="2020-07-02T10:28:55 (PROD)" Product="protelAir" ProductVersion="2027.1.56845-RELEASE" Service="io.protel.air"/>
		<htnga:CorrelationID xmlns:htnga="http://htng.org/PWSWG/2007/02/AsyncHeaders">RES#047616#UPDATE#000025#1594029290242#546D</htnga:CorrelationID>
		<p:TokenTarget xmlns:p="http://protel.io/soap">$2 C6MmpEFjRRSy288V1hGETMBImNJhFzv5<p:Token>
    </soapenv:Header>
        ...
</soapenv:Envelope>
  1. Official message name sent as webservice (SOAPAction)
  2. Token generated for this service installation in for particular hotel/customer by protel
Info
titleNote:

Username and Password are not used for incoming messages to protel. The protel supplied Bearer Token is used for authentication. The Callback URL of receiving system’s endpoint is known from the service installation 

Authentication for Outbound messages

  • Vendor Systems can receive messages using HTTP endpoints that are configured in protel’s Module manifests or they can receive them via Websockets

  • Messages must be sent via HTTPS

For messages outgoing to the vendor we send the official message name in the HTTP Header as  e.g. SOAPAction:<OTA_HotelResNotifRQ>

Codeblock
languagexml
titleSOAPAction
SOAPAction:<MethodName>

protel IO always sends out the CorrelationID, which identifies (uniqueID) the message pair (RQ/RS)

Codeblock
languagexml
titleCorrelation ID
CorrelationID: <ID_for_the_message_pair>
>io.protel.air</p:Target>
	</env:Header>
	<env:Body>
		--OTA/IO/HTNG Message--
	</env:Body>
</env:Envelope>

Format of the Acknowledgment (ASYNC communication)

To communicate with an ASYNC pattern, the receiver of the message needs to send an ACK with the HTTP status code 200 and the following payload back to the sender before the receiver starts the processing of the message. 

The Content-Type needs to be added in the HTTP Header with the value "application/soap+xml". 

Please note that depending on the message group used, the ACK has some differences between the standard OTA/HTNG and the protel extension IO message types:

Example of SOAPHeader sent from protel I/O

Additionally protel IO sends out a SOAPHeader with Outbound messages

Codeblock
languagexml
titleExample Soap HeaderACK for HTNG/OTA message type
<?xml version='1.0' encoding='UTF-8'?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
	<env:Header>
		<htnga:CorrelationID xmlns:htnga="http://htng.org/PWSWG/2007/02/AsyncHeaders">%1$s</htnga:CorrelationID>
		<htnga:RelatesToCorrelationID xmlns:htnga="http://htng.org/PWSWG/2007/02/AsyncHeaders">%1$s</htnga:RelatesToCorrelationID>
	</env:Header>
	<env:Body>
		<ns:HTNG_AcknowledgeReceipt xmlns:ns="http://htng.org/2014B"/>
	</env:Body>
</env:Envelope>


Codeblock
languagexml
titleExample ACK for IO message type
<?xml version='1.0' encoding='UTF-8'?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
	<env:Header>
		<htnga:CorrelationID xmlns:htnga="http://htng.org/PWSWG/2007/02/AsyncHeaders">%1$s</htnga:CorrelationID>
		<htnga:RelatesToCorrelationID xmlns:htnga="http://htng.org/PWSWG/2007/02/AsyncHeaders">%1$s</htnga:RelatesToCorrelationID>
	</env:Header>
	<env:Body>
		<io:IOAcknowledgeRS CorrelationID="%1$s" xmlns:io="http://protel.io/soap"><soapenv:Header>
    <wsa:MessageID>$1</wsa:MessageID>
    <htng:CorrelationID>$2</htng:CorrelationID>
    <wsa:Action>$3</wsa:Action>
    <wsa:To>$4</wsa:To>
    <wsa:ReplyTo>
        <wsa:Address>http://www.w3.org/2005/08/addressing/role/anonymous</wsa:Address>
    </wsa:ReplyTo>
    <wsse:Security mustUnderstand="1">
        <wsse:UsernameToken>
            <wsse:Username>$5</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">$6</wsse:Password>
        </wsse:UsernameToken>
    </wsse:Security>
    <htng:ReplyTo>
        <wsa	<io:Address>$7<Success>true</wsaio:Address>Success>
        </htngio:ReplyTo>IOAcknowledgeRS>
	</soapenv:Header>

$1 - ID generated for this particular message

$2 - ID generated for this particular message exchange (at least for RQ, ACK and RS)

$3 - Official message name sent as webservice Action

$4 - URL of receiving system’s endpoint

$5 - Username if authentication is done using this schema

$6 - Password if authentication is done using this schema

$7 - URL of receiving system’s endpoint

Testing Connectivity with a Dummy API

To test the SOAP Function, systems can call
https://api-dev.protel.net/services/SoapDummyService.SoapDummyServiceHttpsSoap11Endpoint,
which returns a static OTA_HTNG Body.

Websocket Support

...

env:Body>
</env:Envelope>

Image Added


protel I/O Connection Endpoints

Connecting

...

to TEST

SystemEndpointVariantURLComments
ESBAsynchronous APISOAP 1.2https://
api
service-
dev
test.protel.
net
io/services/ProtelApiService.ProtelApiServiceHttpsSoap12EndpointDefault Endpoint
Websocketws://172.31.191.140:9090not in useJSON
Synchronous APISOAP 1.2https://
api
service-
dev
test.protel.
net
io/services/
ProtelApiService
ProtelApiSyncService.
ProtelApiServiceHttpsJsonEndpointnot in useSynchronous API
ProtelApiSyncServiceHttpsSoap12Endpoint
Asynchronous API (CD-Proxy)SOAP 1.2https://
api
qa-
dev
pci.protel.net
/services/ProtelApiSyncService.ProtelApiSyncServiceHttpsSoap12EndpointJSON
/cd-proxy-io/pci/1/io/reservationsEndpoint for all inbound OTA_HotelResNotifRQ messages
WSDLSOAP 1.2https://
api
wsdl-
dev
test.protel.
net
io/services/
ProtelApiSyncService.ProtelApiSyncServiceHttpsJsonEndpointnot in use

...


Connecting to PROD

SystemEndpointVariantURLComments
ESBAsynchronous APISOAP 1.2

https://service

-test

.protel.io/services/ProtelApiService.ProtelApiServiceHttpsSoap12Endpoint

Websocketwss://wsesb-test.protel.io:443not in useJSON

Default Endpoint

Synchronous APISOAP 1.2

https://

wsdl-test

service.protel.io/services/

ProtelApiService

ProtelApiSyncService.

ProtelApiServiceHttpsJsonEndpointnot in useSynchronous API

ProtelApiSyncServiceHttpsSoap12Endpoint


Asynchronous API (CD-Proxy-Ireland)SOAP 1.2https://
service-test
pci.protel.net/cd-proxy-io/
services/ProtelApiSyncService.ProtelApiSyncServiceHttpsSoap12EndpointJSONhttps://wsdl-test.protel.io/services/ProtelApiSyncService.ProtelApiSyncServiceHttpsJsonEndpoint

not in use

Connecting to prod:prod

pci/1/io/reservationsEndpoint for all inbound OTA_HotelResNotifRQ messages
Asynchronous API (CD-Proxy-Sydney)
SystemEndpointVariantURLCommentsESBAsynchronous API
SOAP 1.2https://
service
pci-sydney.protel.net/cd-proxy-io/
services/ProtelApiService.ProtelApiServiceHttpsSoap12EndpointWebsocketwss://wsesb.protel.io:443not in useJSON
pci/1/io/reservationsEndpoint for all inbound OTA_HotelResNotifRQ messages for protel Customers located in Sydney
WSDLSOAP 1.2https://wsdl.protel.io/services/ProtelApiService
.ProtelApiServiceHttpsJsonEndpoint not in useSynchronous APISOAP 1.2

https://service.protel.io/services/ProtelApiSyncService.ProtelApiSyncServiceHttpsSoap12Endpoint

JSONhttps://wsdl.protel.io/services/ProtelApiSyncService.ProtelApiSyncServiceHttpsJsonEndpointnot in use

Format of the Acknowledgment (ASYNC communication)

To communicate with an ASYNC pattern, the receiver of the message needs to send an ACK with the HTTP status code 200 and the following payload back to the sender before the receiver starts the processing of the message. 

Codeblock
languagexml
titleExample ACK
<?xml version='1.0' encoding='UTF-8'?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
	<env:Header>
		<htnga:CorrelationID xmlns:htnga="http://htng.org/PWSWG/2007/02/AsyncHeaders">RES#045627#CREATE#000002#1575294717780#6244XXX</htnga:CorrelationID>
		<htnga:RelatesToCorrelationID xmlns:htnga="http://htng.org/PWSWG/2007/02/AsyncHeaders">RES#045627#CREATE#000002#1575294717780#6244XXX</htnga:RelatesToCorrelationID>
	</env:Header>
	<env:Body>
		<ns:HTNG_AcknowledgeReceipt xmlns:ns="http://htng.org/2014B"/>
	</env:Body>
</env:Envelope>

WSDL

...


NAT Gateway IP Addresses

EnvironmentNAT Gateway - Out
ESB TEST34.249.236.99
ESB PROD34.248.234.12

Circular Message Flow


The circular message flow prevents a message loop between Integration Partner and Protel.

It is applicable for message types which the PMS accepts in both directions In/Out (e.g. OTA_ProfileModifyRQ, OTA_HotelResNotifRQ, etc.)

Sample:

The Integration Partner sends an OTA_ProfileModifyRQ message to Protel. This profile is modified in the PMS and then sent again as OTA_ProfileModifyRQ by the PMS. The Integration Partner will also modify the profile again and send it back to Protel, thus creating an endless loop. 



Image Added



To stop this endless loop, we have implemented the "Caused-By CorrelationID". The "Caused-By CorrelationID" is automatically added to the outbound messages by the PMS if a modification has been made due to an inbound message. Based on the "Caused-By CorrelationID", our ESB knows to which Ontegration Partner the message does not have to be sent. 


Image Added