Expectations for Error Handling over pmsXchange
It is expected that your PMS/CRS/RMS has a robust error handling process as outlined as agreed to in our 'Best Practices'. This includes a queuing mechanism and a robust retry strategy. More information in relation to Error Handling is outlined below.
Please read the below to make sure you have a good understanding on the requirements for error handling over pmsXchange.
Common Error Handling Scenarios you may encounter over pmsXchange
Application Level
If the response back from pmsXchange contains an OTA RS message with an 'Error' element, then the update can not be processed because some data is invalid. Below are some common application level error scenarios:
HTTP Server Level
Below outlines the OTA (OpenTravel) standard EWT and ERR codes that will be used in-conjunction with the error messages outlined in each pmsXchange API.
PmsXchange will use the following OTA error types from OTA Error Warning Type (EWT)
EWT | Error Type | Description |
---|---|---|
1 | Unknown | Indicates an unknown error. |
3 | Biz rule | Indicates that the XML message has passed a low-level validation check, but that the business rules for the request message were not met. |
4 | Authentication | Indicates the message lacks adequate security credentials |
6 | Authorization | Indicates the message lacks adequate security credentials |
10 | Required field missing | Indicates that an element or attribute that is required in by the schema (or required by agreement between trading partners) is missing from the message. For PmsXchange this type will also be returned if the xml message does not meet the restrictions (e.g data types) specified by the xml schema. |
12 | Processing exception | Indicates that during processing of the request that a not further defined exception occurred. |
pmsXchange will use the following OTA error types from OTA Error Codes (ERR)
Error Codes
ERR | Error Code | Description |
---|---|---|
249 | Invalid rate code | Rate does not exist |
375 | Hotel not active | Hotel is not enabled to receive inventory updates |
385 | Invalid confirmation or cancellation number | Confirmation or cancellation number does not exist |
392 | Invalid hotel code | Hotel does not exist |
402 | Invalid room type | Room does not exist |
448 | System error | |
450 | Unable to process | |
783 | Room or rate not found | Room and rate combination does not exist |
Error Code | Error Reason | Suggested Handling Method |
---|---|---|
500 - Internal Server Error | A generic error message, given when an unexpected condition was encountered and no more specific message is suitable. | Please implement a retry strategy that aims to establish whether the 500 error received is a random event. Once established the error is not a random event (using a retry strategy), please verify the request is valid. If you believe the request to be valid, please reach out to our Application Operations team. |
501 - Not Implemented | The server either does not recognise the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API). | Please fail request and review whether the request is currently supported by the web service attached to this endpoint. |
502 - Bad Gateway | The server was acting as a gateway or proxy and received an invalid response from the upstream server. | For this you should implement a retry strategy that is sympathetic to high load situations. We suggest that you implement an 'Exponential Backoff' strategy (see Exponential Backoff). We'd recommend something like: 5 seconds → 10 seconds → 20 seconds → 40 seconds → then every minute until a defined timeout. We recommend at least 30 minutes from the initial request until a timeout is considered. Once the time out is reached and the message has failed, please reach out to our Application Operations team. |
503 - Service Unavailable | The server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state. | For this you should implement a retry strategy that is sympathetic to high load situations. We suggest that you implement an 'Exponential Backoff' strategy (see Exponential Backoff). We'd recommend something like: 5 seconds → 10 seconds → 20 seconds → 40 seconds → then every minute until a defined timeout. We recommend at least 30 minutes from the initial request until a timeout is considered. Once the time out is reached and the message has failed, please reach out to our Application Operations team. |
504 - Gateway Timeout | The server was acting as a gateway or proxy and did not receive a timely response from the upstream server. | For this you should implement a retry strategy that is sympathetic to high load situations. We suggest that you implement an 'Exponential Backoff' strategy (see Exponential Backoff). We'd recommend something like: 5 seconds → 10 seconds → 20 seconds → 40 seconds → then every minute until a defined timeout. We recommend at least 30 minutes from the initial request until a timeout is considered. Once the time out is reached and the message has failed, please reach out to our Application Operations team. |
505 - HTTP Version Not Supported | The server does not support the HTTP protocol version used in the request. | Please fail the request and ensure that the client making requests to pmsXchange has been configured correctly. |