Promotions are a very effective 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 increase your sales and keep 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 mainly used for cart calculation. There are no promotion messages on 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

Promotion calculation is a CPU- and memory-intensive process. Performing heavy calculations for category and search pages will significantly affect overall system performance. To meet the performance requirements, you need to scale up your application cluster considerably.

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 20 times more often, all within a single HTTP request session. The category page is used at least twice as often as 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 product list pages, search result pages, and product detail pages.
• Promo prices may depend on parameters, such as the currently logged-in 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 the hybris core or 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 web server:
  • 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 offload the Drools rules to the promotion calculation cluster

© Rauf Aliev, July 2016