Message Size Limits and Bundling Best Practices

1 Message Size Limits
2 Delta Changes
3 Bundling updates
4 Full flushes

Message Size Limits

pmsXchange has a message size limit of 2MB. Messages received that are greater than this size will not be processed and the following soap fault will be returned.

<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
	<SOAP-ENV:Header/>
	<SOAP-ENV:Body>
		<SOAP-ENV:Fault>
			<faultcode>SOAP-ENV:Server</faultcode>
			<faultstring xml:lang="en">Unable to process message. Payload too large</faultstring>
		</SOAP-ENV:Fault>
	</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Messages larger than 2MB will need to be broken down into smaller messages or the updates bundled more effectively.

Delta Changes

It is important to only send us delta changes. By this we mean only send us data that has changed since the last update was sent. So if a room availability changes to 4 on 2022-11-08 then only send us the availability update and don’t include any of the room restrictions for that date or updates of other room rates. Even though the OTA_HotelAvailNotifRQ message supports both availability and restrictions.

For the above example, we would expect this:

<AvailStatusMessages HotelCode="TESTHOTEL">
	<AvailStatusMessage BookingLimit="4">
		<StatusApplicationControl Start="2022-11-08" End="2022-11-08" InvTypeCode="DBL" RatePlanCode="BAR"/>
	</AvailStatusMessage>
</AvailStatusMessages>

But not this:

<AvailStatusMessages HotelCode="TESTHOTEL">
	<AvailStatusMessage BookingLimit="4">
		<StatusApplicationControl Start="2022-11-08" End="2022-11-08" InvTypeCode="DBL" RatePlanCode="BAR"/>
		<LengthsOfStay>
			<LengthOfStay MinMaxMessageType="SetMinLOS" Time="1"/>
			<LengthOfStay MinMaxMessageType="SetMaxLOS" Time="999"/>
		</LengthsOfStay>
		<RestrictionStatus Status="Open"/>
	</AvailStatusMessage>
</AvailStatusMessages>

Bundling updates

The ideal way for ARI messages to be constructed would be for them to contain a single room and rate code and that the message contains all dates that have changed for that room rate combination. Avoid sending small single date updates where possible. If the changes you need to send for a room/rate have consecutive dates and the Availability is the same for those dates, then this update should be bundled by using the Start and End dates.

Another way of bundling messages is the use of the days of the week flags. Enabling you to specify which days of the week the update applies for a specified date range.

This is an example where we have 2 separate update messages. Both update BAR/DBL for a year.

The first message sets a rate for Sunday-Thursday (using the rate weekday flag):

The second message sets a rate for Friday-Saturday (using the rate weekday flag):

These 2 messages could be bundled down to a single update by including both RateAmountMessages in a single message:

It's also important to try to group dates where the rate, restriction or availability is the same.

For example, this rate message has 2 RateAmountMessages for the same rate amount but for consecutive range of dates:

Could be bundled into one single RateAmountMessage by consolidating the dates:

Full flushes

When sending a full flush, try to keep updates to a single room or room/rate combination and include as many dates as you can per message for that room/rate combination. We would rather receive single large update/echotoken for a room/rate combination that has lots of dates, rather than lots of smaller updates/echotokens with only a few dates per message.