Image Added

Introduction

For the API, Web Manager, bookings engine, my environment and webservices we don't use database listeners. For this, we have a separate flow in place, because we require additional information (such as pre-calculated prices) in the Elasticsearch index.

This flow is described below.

Image Removed

Pricecache

• The Price calculation process runs every hour for all clients.
• Calculates prices for specific distribution channels only (usually internet and tour operators) and stores these in the pricecache.
• After a change has been made that needs (re)calculation or removal of prices it can take at most 1.5 hours before this gets picked up by the price calculator. The price calculator only picks up changes which are at least 30 minutes old. This has been done for efficiency reasons, because when multiple changes are made affecting the same accommodations these will be merged together, so it only has to calculate prices once.
• Changes that require price calculation are:
  • Changes in cashflowrules
  • Changes in rentability
  • Changes in representations
  • Changes in releases
  • Changes/creation of specials
• In general, one run of the price calculator will calculate all the prices for changes made since the last time it ran, one run takes at most 50 minutes.
  So, in worst-case, prices will be calculated after at most 2 hours and 20 minutes (1.5 hours + 50 minutes (maximum calculation time)).
  In best-case the calculation just needs a couple of minutes, so just over 30 minutes (30 minutes + calculation time).
  On average prices can be expected to be calculated in one hour.
• However, it can occur that one run of the price calculator won’t be enough to calculate all the prices for a change. This is because the duration of the calculation depends on the impact of the change. If a change spans a large period and/or affects a large part of the accommodations, calculation times will increase.
  Examples of this kind of changes are:
  • Creating a special that is valid for all accommodations and all arrivals will require many prices to be calculated and
  • Opening a new release
  • Closing a release

Elasticsearch index process

...

Side notes

The following changes will not show up online:

• Creating a new accommodation type (it needs to have prices, rentability and a release before it will be available to book online, in the Reservation Manager and Newyse).

The following changes (including newly adding) require a complete re-index before they will be available online, therefore it can take up to 12 hours (time between two re-indexes before they will be available online).

...

We use Elasticsearch to store availability and prices. Elasticsearch is a search engine that provides fast searches and grouping of data (so-called aggregations).
The availability index consists of documents and each document represents a possible stay; it contains (among other fields) a resourceId, arrival date, duration, distribution channel, units, price, and possibly an offer code.
Only accommodation types meeting the following criteria will be indexed:

• Are released
• Have rentability
• Have prices

Index Modes

We have several index modes available which all have their requirements and benefits. Below you can find a matrix in which per index mode the requirements, benefits, and limitations are listed.

An overview of which customer uses which index mode can be found here: Index Modes.

Matrix

		Length of Stay using Pricecache	Night Rates on Unit level	Night Rates on Type level
Performance	Processing time (faster = more real-time)
	Index size (smaller = faster search)
Requirements	Rate Option - Night rates
	Rate Option - Length of stay rates
	Every day departure
	Departure on specific days
	Difference in units of one accommodation type  (e.g., amenities)
Functional	Inheritance of prices
	Length of stay price calculation
	Fixed rate offers (e.g., -20)		*	*
	Relative (percentual) offers (e.g., -10%)		*	*
	Offer that overrides accommodation price ("New price" offer)		**	**
	X=Y offers (e.g., 7 days for price of 6)
	Subject-based offers
	Exact period only offers
	Combination of offers (max. 2)		***
	Implies fixed amount per stay
	Implies fixed amount per night
	Implies subject-based
	Implies with relative prices
	Implies on unit level
	Search amenity on location level
	Search amenity on type level
	Search amenity on unit level
	Gap configuration
	Reallocation
	Include unavailable units

* only if configured with nightly or consumption rates.

** only when the offer is "exact period only", support for partially valid offers will be build in: 

*** only in optimised mode

Troubleshooting

To check why some availability is missing, see Checklist availability online.