...
...
...
...
...
...
...
...
Integration Requirements Guidelines
In accordance with the API Services Terms of Use Agreement signed by the PMS /CRS partner before development has commenced, these guidelines are in place to ensure efficient and proper use of the pmsXchange SMX for PMS API.
The following Integration Requirements must be adhered to by all PMS' that have or wish to have an interface to pmsXchange.For PMS providers that have already been implemented, the below may require changes to the set up they currently have. Whilst SiteMinder could be flexible in accommodating exceptions in the past, the constant increase in the number of PMS installations and is reaching a level where exceptions can no longer be allowedSiteMinder Exchange for Publishers.
Failure to follow these guidelines could jeopardise the PMS interface and, if no action is taken by the PMS provider to rectify non-compliance within 3 months from notification, SiteMinder reserves the right to disable the interface till such corrections have taken place.
Please note, however, that if the non-compliance of the PMS puts the performance to the whole SiteMinder production environment at risk, SiteMinder reserves the right to disable the interface immediately.
| Table of Contents | ||
|---|---|---|
|
...
...
EchoTokens
EchoTokens are essential for all requests being made over the pmsXchange v2 SiteMinder Exchange 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.
SSL/TLS
pmsXchange V2 supports TLSv1.2
File Upload Size
Uploaded messages must not be larger than 2MB (uncompressed)
...
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 PMS 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 pmsXchange 'Developer Guide'.
In addition to this, these updates MUST be sent to pmsXchange V2 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 pmsXchange v2 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 is expected that your PMS has a robust error handling process whereby errors can be queued and resent. It's also expected that you make hoteliers aware of errors affecting the syncing of their data over pmsXchange. 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 pmsXchange to the PMS
Reservation PULL Model
The PMS should 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 SiteMinder.
If upon receipt of a reservation, the PMS system is unable to process it, the reservation XML message MUST nevertheless be accepted by the PMS system and acknowledged as 'Success' or 'Error' back to SiteMinder, regardless of possible errors (for instance if they contain a rate code that is not yet defined in the PMS system or if it is a cancellation for a reservation not found in PMS). The pmsXchange system 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 the PMS and responding to the message successfully. In case of application of Default codes, the PMS should 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 the PMS capability, pmsXchange compatibility, and as described in the transfer of availability messages to pmsXchange.
- The PMS provider MUST ensure 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.
- Identical changes in availability for consecutive days should 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, the PMS provider should send one single message to pmsXchange with start date Jan 1st and end date Jan 3rd rather than 3 daily messages.
The PMS will need to establish 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 pmsXchange because of erroneous content (for example if it contains a room type code that is not recognised error message. The PMS provider must ensure 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. If no corrective action is taken, and the incorrect message continues to attempt to upload in a loop, SiteMinder will reserve the right to disable the interface till such time as corrective action is taken.
It is advisable that the PMS has a queuing mechanism that queue upload messages in case of lack of connectivity with the pmsXchange service or during scheduled release outages. If pmsXchange fails to respond at all, then the messages should be re-sent when connectivity is re-established.
- pmsXchange v2 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 SiteMinder 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 PMS to SiteMinder
...
For day to day usage, when ARI changes are made, the PMS provider must ensure 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.
...
Identical changes in rates for consecutive days should be 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, the PMS provider should send one single message to pmsXchange with start date Jan 1st and end date Jan 3rd rather than 3 messages.
...
The PMS will need to establish 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 pmsXchange because of erroneous content (for instance if it contains a rate code that is not recognised by pmsXchange the PMS provider must ensure 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 and/or PMS must ensure the appropriate correction is applied as soon as possible and ideally no later than 12 hours from receipt of the message. If no corrective action is taken, and the incorrect message continues to attempt to upload in a loop, SiteMinder will reserve the right to disable the interface till such time as corrective action is taken.
...
It is advisable that the PMS has a queuing mechanism that queue upload messages in case of lack of connectivity with the pmsXchange service or during scheduled release outages. If pmsXchange fails to respond at all, then the messages should be re-sent when connectivity is re-established.
...