| Table of Contents |
|---|
General Overview of Error Handling
Expectations for Error Handling over SMX
It is expected that your PMS/CRS/RMS has a robust error handling process. This includes a queuing mechanism and a robust retry strategy.
| Note |
|---|
Please read the below to make sure you have a good understanding on the requirements for error handling over SMX for PMS. |
...
Application Level Error Handling
Below outlines the OTA (OpenTravel) standard EWT codes that will be used..
...
Solution: You will need to adjust your implementation to include the missing information/data.
...
Handling HTTP 500 Error Responses on SMX
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 SMX has been configured correctly. |
...