Integration requirements

Guidelines

Please make sure you have received a Tesipro Solutions Terms of use agreement signed by the Channel Manager, Booking Engine, RMS or similar before development has commenced these guidelines are in place to ensure efficient and proper use of the Ulyses Cloud Channel Manager API.

The following Integration Requirements must be adhered to by all partners that have or wish to have an interface to Ulyses Cloud Channel Manager API.

For Channel Manager providers that have already been implemented according the TesiproCon Push version, the below may require changes to the set up they currently have. Whilst Tesipro Solutions could be flexible in accommodating exceptions in the past, the constant increase in the number of Channel Manager installations and is reaching a level where exceptions can no longer be allowed.

Failure to follow these guidelines could jeopardise the Channel Manager interface and, if no action is taken by the Channel Manager/Booking Engine/RMS provider to rectify non-compliance within 3 months from notification, Tesipro Solutions reserves the right to disable the interface till such corrections have taken place.

Please note, however, that if the non-compliance of the Channel Manager puts the performance to the whole Ulyses Cloud production environment at risk, Tesipro Solutions reserves the right to disable the interface immediately.


Echotoken

Linespacing

Content-type

File upload size

Bundling updates

Delta and actions performed only updates

Overlapping dates

Error handling / Hotelier error awareness

Reservation delivery

Availability (Restrictions &/OR Inventory) uploads

Rate uploads


EchoToken

EchoTokens are essentiyal for all requests being made over the pmsXchange v2 as per the following link - EchoToken, Timestamp and POS.

NOTE: Please ensure that you implement EchoTokens that are as 'unique' as possible to ensure that log trawling for troubleshooting purposes on either side is quick and efficient. Implementing GUIDs are recommended and more information about GUID can be found - http://en.wikipedia.org/wiki/Globally_unique_identifier .

Linespacing

All Soap XML requests made to pmsXchange should be contained on one line with no linespacing. We ask this to assist our support teams in extracting messages from our logs.

Content-Type

The ‘Content-Type’ for all Soap XML requests made to pmsXchange V2 must be 'text/xml; charset=utf-8'. Any other ‘Content-Type’ will not be accepted.

File Upload Size

Uploaded messages must not be larger than 2MB (uncompressed)

Bundling Updates

Rate, Availability or Restriction updates must be bundled in instances where the values for consecutive dates are the same. For example, if you are changing a rate of $120 from the 1 July - 14 July you must bundle the message. More information on bundling is included within the 'Developer Guide'.

Delta and Actions Performed Only Updates

Request messages (Availability, Restrictions & Rates) must ONLY CONTAIN data relevant to the action being performed in your PMS. For example, if a Ulyses Cloud user is changing the availability of a room in the PMS, you must only send the availability update and no other rate or restriction messages. No unchanged dates should be included in these request messages. More information on each message structure will be contained in the Ulyses Cloud Channel Manager api 'Developer Guide'.

In addition to this, these updates MUST be sent to UC Channel Manager API in as close to real-time as possible. Updates should be sent within 2 minutes of the change occurring in your PMS.

Overlapping Dates

Any 'Inventory API' requests made over UC Channel Manager API should not contain overlapping dates. All date ranges in a singular message should be unique for each Inventory Code/Rate Code combination.

Error Handling / Hotelier Error Awareness

It's expected that you make hoteliers aware of errors affecting the syncing of their data over UC Channel Manager API. More information can be found below under 'Availability (Restrictions &/OR Inventory) Uploads' and 'Rate Uploads' and within our Error Handling page.

Reservation delivery

This message pertains to the delivery of reservations from the Channel Manager to the Ulyses Cloud

Reservation PULL Model

The PMS will never request for reservations more often than:

  • Every 2 minutes for a decentralised interface, and no less often than every 5 minutes.

  • Every 2 minutes for a centralised interface, and no less often than every 5 minutes. Exceptions to be agreed with the Channel Manager.

If upon receipt of a reservation Ulyses Cloud is unable to process it, the reservation XML message will be accepted by our platform and acknowledged as 'Success' or 'Error' back to the Channel Manager, regardless of possible errors (for instance if they contain a rate code that is not yet defined in Ulyses Cloud or if it is a cancellation for a reservation not found in Ulyses Cloud). The Channel Manager API is only transiting the reservation after it has been made in the distribution channels and will not be able to modify the reservation upstream. This can be achieved of course by using default values in case of mismatching codes or ignoring cancellations for which there is no reservation in Ulyses Cloud and responding to the message successfully. In case of application of Default codes, Ulyses Cloud will notify the user so that any code mapping error can then be rectified.

Availability (Restrictions &/OR Inventory) Uploads

These uploads include all messages pertaining to the transfer of inventory counts and restrictions with Ulyses Cloud capability, UC Channel Manager API compatibility, and as described in the transfer of availability messages to UC Channel Manager API.

  1. Ulyses Cloud ensures that only changes to availability and restrictions, and not full refreshes, are sent. Refreshes should only be sent at most once per day and at times when traffic is low i.e. between midnight and 5 am. Only in exceptional circumstances should additional full refreshes be sent.

  2.  Identical changes in availability for consecutive days will be condensed into one message wherever possible. For instance, if the change in inventory counts for room type SGL is = 10 for Jan 1st, Jan 2nd and Jan 3rd, Ulyses Cloud sends one single message to the Channel Manager with start date Jan 1st and end date Jan 3rd rather than 3 daily messages.

  3. Ulyses Cloud establishes transaction/error logs to collect error messages generated by the system in case of errors in the transmission of your upload messages. The error log and error messages must be available to the property use for regular checks (to be undertaken by the properties, at a minimum, on a daily basis). For example, if an availability message is rejected by the Channel Manager because of erroneous content (for example if it contains a room type code that is not recognised error message. Ulyses Cloud ensurea such message is made available for the property to view and that the property is alerted the transaction was not successful. Upon viewing the error message the property must ensure the appropriate correction is applied as soon as possible and ideally no later than 12 hours from receipt of the message. 

  4. Ulyses Cloud has a queuing mechanism that queue upload messages in case of lack of connectivity with the Channel Manageduring scheduled release outages. If either Ulyses Cloud or its public API fails to respond at all, then the messages should be re-sent when connectivity is re-established.

  5. UC Channel Manager API only allows Inventory Updates for Room/Rate code combinations that are known to SiteMinder (i.e. have been setup and mapped to the PMS within the Channel Manager). If we receive an Inventory Update that contains a Room/Rate code that is unknown to SiteMinder Channel Manager, the entire Update will fail.

Rate Uploads

These uploads include all messages pertaining to the transfer of rate data from the Ulyses Cloud to the Channel Manager (or similar)

  1. For day to day usage, when ARI changes are made, Ulyses Cloud ensures that only changes to rates, and not full refreshes, are sent. Full refreshes should only be sent at most once per day and at times when traffic is low i.e. between midnight and 5 am. Only in exceptional circumstances should additional full refreshes be sent.

  2. Identical changes in rates for consecutive days are condensed into one message wherever possible. For instance, if the change in rates counts for room type SGL is = $100 for Jan 1st, Jan 2nd and Jan 3rd, Ulyses Cloud sends one single message to the UC Channel Manager API with start date Jan 1st and end date Jan 3rd rather than 3 messages.

  3. Ulyses Cloud establishes transaction/error logs to collect error messages generated by the system in case of errors in the transmission of your upload messages. The error log and error messages must be available to the property user for regular checks. For example, if a rate message is rejected by the Channel Manager API because of erroneous content (for instance if it contains a rate code that is not recognised by the UC Channel Manager API, Ulyses Cloud ensures such message is made available for the property to view and that the property is alerted the transaction was not successful. Upon viewing the error message the property must ensure the appropriate correction is applied as soon as possible and ideally no later than 12 hours from receipt of the message. 

  4. Ulyses Cloud has a queuing mechanism that queue upload messages in case of lack of connectivity with the Ulyses Cloud Channel Manager API during scheduled release outages. If the API fails to respond at all, then the messages should be re-sent when connectivity is re-established.

  5. The Channel Manager API only allows Rate Updates for Room/Rate code combinations that should be known to the Channel Manager (i.e. have been setup and mapped to Ulyses Cloud within the Channel Manager). If we receive an Inventory Update that contains a Room/Rate code that is unknown to theh Channel Manager, the entire Update will fail.