...

Image Added

Introduction

For the web managerAPI, 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.

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 modes mode the requirements, benefits, and limitations are listed.

Index Mode Matrix

...

LOS prices using pricecache

...

LOS prices using cashflowrules

...

Nightly rates on unit level

...

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

Nightly rate

Rate Option - Night rates

	Rate Option - Length of stay

(LOS)

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

discounts

offers (e.g., -20)

*	*
	Relative (percentual)

discounts

offers (e.g., -10%)

*

Override discounts (override price for specific period

*
	Offer that overrides accommodation price ("New price" offer)

**	**
	X=Y

discounts

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

* support for these will be added through  Image RemovedMXTS-26931 - Add support for internet additional costs in the night price index OPEN

General Flow

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
• Information on which pricecaches are active per client can be found here: /wiki/spaces/OWC/pages/11403480.
• Information on which client uses pricecache for prices in the Elasticsearch index and which uses the price calculation in the indexer application itself can be found here: /wiki/spaces/DEV/pages/5016084.

Elasticsearch index process

...

Side notes

If an accommodation type gets fully booked for a certain period, the availability index will be updated immediately by removing that accommodation type for that period from the index.

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).

...

	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.