Why am I receiving a 'Throttle limit reached, please try again later...' message?
You have breached the throttle limit that is placed on all our pmsXchange V2 connections. There are 3 breaches that will generate this response:
- Exceeding requests per minute threshold. The requests per minute count is reset every minute (eg from 00:00:00.000 to 00:00:59.999). Reservation requests (OTA_ReadRQ) do not have a threshold limit (however, OTA_ReadRQs should be no more frequent than every 2 minutes, and no less frequent than every 5 minutes).
- Exceeding message size threshold. The message size is the amount of 'AvailStatusMessage', 'RateAmountMessage' etc per message.
- Exceeding concurrent message threshold.
What are the throttle parameters I need to work within?
Request per minute throttle = 40
Messages per request (message size) = 500 messages
Concurrent requests Limit = 3
NOTE: These throttle parameters are what you'll have when you go through our certification process, and will be the initial throttle parameters you initially have in production. These parameters can be tweaked in consultation with our Application Operations team as the number of hotels you have grows. You'll be given contact details for the Application Operations team once you are certified and live in production.
Do I need to send 'Delta' updates to pmsXchange when a change is made in my pmsXchange connected integration?
Yes, it is extremely important that you only push 'Delta' changes to pmsXchange. Full refreshes are only allowable a maximum of once per day. Many throttling breaches are to due large requests being sent, even though only small amounts of data have changed in the upstream integration.
Why does pmsXchange apply throttling to incoming requests?
pmsXchange applies throttling to ensure we have a way to manage performance on the pmsXchange service. Many partners from all over the world connect to SiteMinder via pmsXchange, so it's really important for SiteMinder to maintain a high level of availability for all our partners.
I haven't experienced throttling in the past, how come I am experiencing it now?
With more and more partners coming on board everyday, we need to actively throttle to maintain performance for all partners using pmsXchange (especially if you are generating larger than normal size/frequency requests). Throttling has always been something we've always had as part of the pmsXchange spec, and we're now actively looking to apply known throttle parameters to all partners.
Am I likely to breach the throttle limits? How important is it that I take action to handle throttling?
Currently there are a low number of partners who are likely breach our throttle limits. In saying that, it is very important that you are aware and can take appropriate action to handle throttling.
It is very important to ensure that you have measures in place to handle throttling. If you receive a 'Soap Fault' response advising your integration has been throttled, it is important that the situation can be flagged and action taken by your application/infrastructure support teams. After throttling occurs, it is important that your team takes immediate action to correct the cause of the throttle breach. Our Application Operations teams can work with your technical team to arrive at a solution.
What do I need to do if I've been throttled because my requests contain too many messages?
You'll need to break out the messages in your single request across multiple requests to ensure you fall under our MessagesPerRequest throttle. Our team will advise what the MessagesPerRequest throttle is.
What do I need to do If I've been throttled because my requests are too frequent?
You'll need to ensure that you batch more messages into a single request. You will need to mindful that we also have a MessagesPerRequest throttle too, so be mindful of the amount of messages you're going to be batching into a single request.
What do I need to do If I've been throttled because I send to many requests at the same time?
If you send too many messages concurrently to pmsXchange, you will hit our concurrentRequestsLimit. You will need to queue messages, and 'PUSH' them steadily over time ensuring that you do not breach the concurrentRequestsLimit. Our team will advise on the concurrentRequestsLimit that will apply to your integration.