Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

Introduction

For the 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.

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

Matrix



LOS prices using pricecache

LOS prices using cashflowrules

Nightly rates on unit level

Nightly rates on type level

PerformanceProcessing time (faster = more real-time)(minus)(plus)(plus)(plus)(plus)(plus)(plus)

Index size (smaller = faster search)(minus)(minus)(plus)(plus)(plus)






RequirementsNightly rate

(tick)

(tick)(tick)(tick)

Length of stay (LOS) rates(tick)(error)(error)(error)

Every day departure(tick)(tick)(tick)(tick)

Departure on specific days(tick)(tick)(tick)(tick)






FunctionalInheritance of prices(tick)(error)(error)(error)

Length of stay price calculation(tick)(tick)(tick)(tick)

Fixed rate discounts (e.g., -20)(tick)(tick)(tick)(tick)

Relative (percentual) discounts (e.g., -10%)(tick)(tick)(tick)(tick)

Override discounts (override price for specific period)(tick)

(tick)

(error)(error)

X=Y discounts (e.g., 7 days for price of 6)(tick)(error)(error)(error)

Exact period only offers(tick)(tick)(tick)(tick)

Combination of offers (max. 2)(error)(error)(error)(tick)

Implies fixed amount per stay(tick)(tick)(error)*(error)*

Implies fixed amount per night(tick)(tick)(error)*(error)*

Implies with relative prices(error)(error)(error)(error)

Implies on unit level(error)(tick)(error)(error)

Search amenity on location level(tick)(tick)(tick)(tick)

Search amenity on type level(tick)(tick)(tick)(tick)

Search amenity on unit level(tick)(tick)(tick)(error)

Gap configuration(tick)(tick)(tick)(tick)

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

General Flow

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

  • Re-indexes are running twice a day: in the early morning and early evening (concern time zone). These completely refresh the availability index.
  • Updates are running every hour or every half an hour (this differs per customer). These updates process changes in prices, rentability, representations, releases, and reservability.
  • Depending on how many changes need to be processed, this process can take several seconds (no or few changes) to 40 minutes (many changes that need a complete refresh of the index).
  • If Elasticsearch uses pricecache to get prices, changes that require calculation first, will be processed in the next update/re-index after these are calculated.
    This means that it can take in worst-case at most 3,5 - 4 hours (2 hours 20 minutes + 30 minutes/1 hour (index process frequency) + 40 minutes (maximum run time of index process)) before changes that require prices are available online.
    In best-case, when prices are calculated just before the next index process, it will take just over 30 minutes (30 minutes + calculation time + indexing time).
    On average changes that require price calculation will available after 1.5 hours – 2 hours depending on the index frequency.
  • If Elasticsearch uses cashflowrules directly to get prices, it will pick up changes right away with every update/re-index process.
    This means, in worst-case, it can take at most 1 hour 10 minutes – 1 hour 40 minutes (30 minutes/1 hour (index frequency) + 40 minutes (maximum run time of index process) before changes are available online.
    In best-case it will take just over 30 minutes – 1 hour (30 minutes/1hour (index frequency) + indexing time).
    On average changes can be expected to be available after 45 minutes – 1 hour 25 minutes depending on the index frequency.
  • Changes in reservability will be picked up right away with every update/re-index process, so in worst-case at most 1 hour 10 minutes (30 minutes (index process frequency) + 40 minutes (maximum run time of index process)).
    In best-case it will take just over 30 minutes – 1 hour.
    On average changes can be expected to be available after 45 minutes – 1 hour 25 minutes depending on the index frequency.

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

  • Changing an amenity
  • Changing capacity
  • Changing the number of bathrooms
  • Changing the number of bedrooms
  • Changing priority
  • Updates in rating
  • Adding new stayperiods
  • Check/Uncheck the “Only add if the period is the same as the period of the resources above this resource” for Specials.
  • No labels