Promotions are a very efficient way to increase sales. Businesses need to be able to easily create promotions for any and every occasion. Having a good promotion engine integrated with your e-shop will definitely make your sales higher and your customers happy. E-commerce platforms commonly have built-in promotion engines. This year hybris 6.0 introduced a new promotion engine. It is based on Drools, the popular open source Java-based rules engine project. This promotion engine is used mainly for the cart calculation. There are no promotion messages on the product pages, category pages or search result pages in hybris 6.0. This post is about designing a solution where promotions are calculated for category and search pages. These pages all have a set of products. So the challenge is to calculate promo prices for every item according to the product-level promotion rules and to do it fast!

Complexity

The promotion calculation is a CPU and memory intensive process. Performing heavy calculations for category and search pages will significantly affect the overall system performance. To meet the performance requirements, you need to considerably scale-up your application cluster. Hybris mainly uses the promotion engine on the cart page which is not requested very often (~5%). For category pages you need to call the promotion engine up to 20x more often, all inside one http request session. The category page is used at least twice as often than the cart page. So the promotion calculation for category and search pages will create a significant, additional burden on the application cluster. To overcome this issue, you can use brute force by scaling up the application cluster. However, adding new hybris application nodes can be costly because of the SAP licensing model. Today’s experiment shows that the promotion engine is no longer a bottleneck in hybris.

Video of PoC

Solution

• Real time promotion calculation on the product list pages, search result pages, and product detail pages.
• Promo prices may depend on parameters, such as the currently logged customer.
• Reconfiguring promotion rules will affect the storefront immediately.
• The calculation service is relatively fast. I did some quick measurements with jMeter. The numbers are shown at the end of the video.

  Promotion calculation cluster:

• Does not use hybris core and hybris database (no license limitations)
• Based on the lightweight http server and has its own load balancer
• Has its own caching subsystem (caching is off in the video)
• Stateless, so easily scalable
• Supports batch calculations (for a set of products at a time)
• RESTful web interface

Limitations

• The proof of concept demonstrates only product-level promotions.
• Two types of actions are supported now: order entry percentage discount action and order entry fixed discount action.
• The following RAO objects are only supported in the PoC:
  • ProductRAO
  • CartRAO
  • UserRAO
  • OrderEntryRAO

Technical details

• Jetty webserver:
  • Two servlets (https):
    • /calculate
      • Input parameters:
        • XML, hybris RAO objects
      • Output:
        • XML, contains recalculated prices
    • /updateRules
      • Input parameters:
        • ID of the drools rule
        • XML, drools rule
• Hybris side:
  • Javascript on the product page / search page
  • RuleCompileService:
    • You need to add a listener or rewrite a service to off load the Drools rules to the promotion calculation cluster

© Rauf Aliev, July 2016