SAP Hybris Clusters on Redis

What Is SAP Hybris?

SAP Hybris is an e-commerce platform originally introduced in 1997. The Hybris software was acquired by the German multinational corporation SAP in 2013. In June 2018, the platform was rebranded as SAP Customer Experience in order to further integrate it under the SAP umbrella. Over the years, Hybris users have included major firms such as Adidas, Samsung, and Vodafone.

From a technical perspective, Hybris is a Java-based software application that uses a three-layer architecture including web, application, and database. It includes features such as web content management, customer service, product catalogs, and payment integrations.

In addition, SAP Hybris can be run as a cluster, which is a group of server nodes that are tightly connected and act as a single system. The benefits of using SAP Hybris clusters include high availability, parallel processing, and load balancing.

What Is User Session Failover?

User session failover is the term for the strategies used when the server holding a user's session fails, placing this information at risk of loss.

When a user logs into an SAP Hybris cluster, the application creates a session on one of the servers in the cluster. During times of high demand, however, the SAP Hybris load balancer may route the user to another server in the cluster that does not have the same session information. As a result, the user appears to be logged out of the application.

There are two solutions to this problem, which are often referred to as "sticky" and "non-sticky" sessions:

• With sticky sessions, the application uses a cookie to uniquely identify users. This permits the application to always send the same user to the same server. The drawback of this method is that users will lose all of their session data if the server crashes unless the data is shared across multiple servers.

• With non-sticky sessions, each user request is placed in a session on a different server. Sessions are replicated across servers, allowing users to continue even if one server has crashed.

There are two tactics for the problem of data loss:

• Session replication: When a server fails, the load balancer redirects the user to another server that also has a session for that user. This allows you to pick up where you left off before the interruption, with little or no disruption.

• Central storage: Persistent stores are used to contain user sessions. NoSQL databases such as Redis, MongoDB, and Cassandra are frequently used for this purpose due to the frequency of inserting and updating information.

Configuring Tomcat Session Management With Redis

Apache Tomcat is an open-source Java software that allows you to create an HTTP web server environment for running Java code. SAP Hybris uses Tomcat as its default web server.

Tomcat can handle the problem of clustering in order to efficiently handle incoming user requests. For example, if you expect that your website will be receiving a large volume of traffic, or you plan to expand the site in the future, it's a good idea to configure Tomcat's session management.

Meanwhile, Redis is an in-memory data store that can be used as the database for your web application. You can use Redis as a central storage hub to hold information about your user sessions. However, Redis can't interface with Tomcat right out of the box. Instead, Redis Java clients such as Redisson make it easy for Redis to work with Java-based applications such as Tomcat.

In this section, we'll discuss how to configure Tomcat session management with Redis and Redisson.

Step 1: Update Tomcat Context XML File

First, you need to add the following line to your tomcat/conf/context.xml file:

<Manager className="org.redisson.tomcat.RedissonSessionManager" 
         configPath="${catalina.base}/redisson.yaml"
         readMode="MEMORY" 
         updateMode="DEFAULT" 
         broadcastSessionEvents="true"/>

Take a closer look at the attributes in this XML: broadcastSessionEvents, readMode and updateMode. readMode controls how session attributes should be stored. There are two modes available:

• MEMORY: Stores attributes in both the local Tomcat session and Redis. Further session updates are propagated to the local Tomcat session using Redis-based events. This is the default setting.

• REDIS: Stores attributes in Redis only.

updateMode controls how session attributes should be updated. There are two modes available:

• DEFAULT: Session attributes are stored in Redis only through the setAttribute method. This is the default setting.

• AFTER_REQUEST: All session attributes are stored in Redis after each request.

broadcastSessionEvents controls the broadcasting of sessionCreated and sessionDestroyed events across all Tomcat instances and causes all registered HttpSessionListeners to be triggered.

Step 2: Copy Files

Once you've adjusted the tomcat/conf/context.xml file to your liking, the next step is to copy two .jar files into the TOMCAT_BASE/lib directory. The first .jar file is redisson-all-3.10.7.jar. The second .jar file will depend on the version of Tomcat that you use:

• Tomcat 6.x: redisson-tomcat-6-3.10.7.jar

• Tomcat 7.x: redisson-tomcat-7-3.10.7.jar

• Tomcat 8.x: redisson-tomcat-8-3.10.7.jar

• Tomcat 9.x: redisson-tomcat-9-3.10.7.jar

Using Redis and Redisson

Enabling Redis and Tomcat to work together isn't the only benefit of Redisson. The primary goal of Redisson is to enable distributed Java applications when using Redis. Redisson offers different caching implementations, as well as implementations of common Java interfaces such as data structures and locks.

To learn more about Redisson, visit the project website or view the source code on GitHub.