Technical Articles
SAP Commerce in OpenShift 4.x using OpenShift SAP Hybris OpenShift Operator
Content for this blog was provided by Faizal Abdul Khader. Many thanks to Faizal and the Red Hat engineering team, in particular Xieshen Zhang and Marco Yeung for creating this operator.
This blog describes the process of taking an SAP Commerce B2B eCommerce platform onto OpenShift 4.x using the SAP Hybris OpenShift Kubernetes Operator. SAP Commerce provides a platform to build a powerful eCommerce website. The implementation experience described in this post uses the experience gained from a real-world use case of SAP Commerce supporting an eCommerce web site where people can purchase HVAC manufactured by this company.
Figure 1 SAP Commerce generated eCommerce site
The website offers designing, and personalization to its dealers, language customization. SAP Commerce is further integrated at this enterprise to a mix of heterogeneous applications to present the best of UI, UX and CX.
SAP Commerce is a large family of products that at their core will provide any given user the ideal customer experience possible. SAP Commerce focuses on a variety of different areas, including:
- E-commerce – provides easy channel communication for B2C, B2B, merchandising.
- Marketing
- Sales
- Services
Figure 2 SAP Commerce Administration Dashboard
- Typical challenges faced by SAP Commerce customers:
- Accelerate the deployment and releases –
eCommerce sites, to stay competitive in its market, must cater for release cycles that are very short. It becomes necessary for a complete automated build and deploy cycle. As the eCommerce solution is being containerized, the new platform has to support a similar level of agility as its build deploys cycles. This in OpenShift is enabled using the SAP Hybris Operator for OpenShift along with use of OpenShift Pipelines.
- Setting up High Availability –
The SAP Commerce Cluster is a number of individual SAP Commerce installations using a common set of data on one database. A cluster configuration lets the platform balance the load between the nodes to scale SAP Commerce in a way that is transparent to the user.
The Clustering in SAP Hybris lets the platform share the Node-specific runtime configurations, Cron jobs, Session failover, Advanced logging and debug modes and Encryption capability. The core of an SAP Commerce Cluster is a network communication system that makes sure the cache of each individual cluster member only holds valid data.
SAP Hybris OpenShift operator enables the deployment of SAP Commerce in a Clustered setup using UDP and Multicast as the option. It facilitates the setting of individual node specific metadata related to clustering in a containerized environment. In an SAP Commerce cluster, the individual SAP Commerce is referred to as a ‘Node’. Each Node uses an individual SAP Commerce instance running in an individual JVM. Each Node in the containerized environment of SAP Commerce is represented by a Kubernetes Pod when deployed in OpenShift.
More about the deployment model will be explored later.
Figure 3 SAP Commerce Clustered Setup
- On Demand Scalability
A common challenge with SAP Commerce has been the capability to dynamically scale the Nodes based on load. In an on-prem setup if the platform needs to be scaled horizontally, a new app server Node has to be provisioned. With SAP Commerce running in a containerized platform, scalability is push-button on-demand, or can be automated based on resource usage. Both the models for scalability are easily supported by the use of the SAP Hybris OpenShift Operator.
Technique:
- Architecture
The architecture of the SAP Hybris OpenShift Operator has two main APIs to it.
- Create a base image stream for the SAP Commerce using the Hybris Base API
- The second part takes the base image stream created along with location of the application source code, uses ‘Source to Image’ S2i and creates a Hybris App image
The idea behind this design is to allow creation of the base image stream once per need and create a new build for every code change committed to the source code repository. For both the creation of Hybris Base and Hybris App the internal OpenShift registry is used to store the image streams created by the Operator.
Note: In order quickly try out the methods stated here in this writeup, an OpenShift cluster can be stood up in short time by using one of the self-service options mentioned here – https://www.redhat.com/en/technologies/cloud-computing/openshift/try-it
- SAP Hybris Operator Configuration
The SAP hybris OpenShift operator deploys as a private catalog available in the public GitHub repository https://github.com/redhat-sap/sap-commerce-operator/blob/main/config/samples/catalog.yaml
Once installed the Operator shows up in the Installed catalog dialog.
Figure 4 SAP Hybris Operator in an Installed state
The SAP Hybris operator as explained earlier exposes two APIs. Hybris Base lets the user create a base image once that can be shared across for multiple reuses for the different solutions needs. The steps to create the base image can be found documented here https://github.com/redhat-sap/sap-commerce-operator/tree/main/docs
Figure 5 APIs available under the SAP Hybris Operator
- Build and Deploy process
Building the Hybris base image starts by downloading the archive from the SAP provided download location with your SAP account
The instructions to create the base image can be found here – https://github.com/redhat-sap/sap-commerce-operator/tree/main/docs
Figure 6 SAP Hybris Base Image creation dialog
Once the base image creation is triggered, OpenShift creates a BuildConfig and starts an instance of a Build. Once the Build completes successfully the image is available as ImageStream in OpenShift. The tag in the ImageStream tells you the version used for the image.
Figure 7 SAP Hybris base image stream
After the base image creation, the next step is to create Hybris App from the customizations created as source code. When creating the Hybris App, a Git location is provided where the source code needs to be picked up from. Also, the base image created earlier is one of the inputs that needs to be provided here. All the rest of the inputs are SAP Commerce specific, and a SME would be needed to complete them. Namely the entries allow the user to customize the JVM route name used for AJP working, the ANT tasks used for the SAP Commerce build actions can be provided, and property files used for SAP Commerce can be customized using an explicit path from the source control.
Figure 8 Creating an instance of the Hybris App
Figure 9 Customizing Hybris App Deployment
Once the Hybris App gets deployed, the secure port HTTPS port 9002 is exposed for external access. The service create also exposes 9001 the HTTP port, and 8009 the AJP port.
Figure 10 SAP Hybris Route after Deployment
- Objectives from a typical implementation of SAP Commerce in OpenShift:
-
- Compare the performance of SAP Commerce running in OpenShift to a baseline performance on-prem
- Identify the optimal pods needed to handle the peak load needed for eCommerce, and scale for future growth
- Measure the performance of backend DB RFC executions
- Measure CPU utilization across peak load conditions in eCommerce
- Proof of value for using OpenShift 4.x as a complete application development platform
- Common issues experienced with an SAP Commerce containerization need:
- F5 Integration:
In an enterprise environment it is usual that the external integration gateway is usually managed by F5. This will necessitate that the secure Route setup by SAP Hybris Operator need to be exposed through the F5 gateway. This will also require the gateway to maintain stickiness for user sessions preforming shopping cart eCommerce transaction.
- CORS:
Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any other origins (domain, scheme, or port) than its own from which a browser should permit loading of resources.
For security reasons, browsers restrict cross-origin HTTP requests initiated from scripts. This means that a web application can only request resources from the same origin the application was loaded from unless the response from other origins includes the right CORS headers.
If CORS is a requirement in the implementation of SAP Commerce (this totally applies to specific instance customizations), then the external access of the solution has to be enabled through actual Kubernetes Ingress of HAProxy, Nginx etc. OpenShift Routes will not be a suitable option for such a situation.
- Navigate performance challenges:
A usage of OpenShift infrastructure nodes in the setup of SAP Commerce is a recommended design due to the high resource utilization under peak load eCommerce situations.
When Infrastructure nodes are used in OpenShift, logging, monitoring and OpenShift Routes should be made to run on these nodes.
- Kubernetes scheduling challenges:
SAP Commerce Pods have to be equally spread across the available dedicated OpenShift Cluster Worker nodes. This can be enabled using concepts as Node Selectors, Topology Spreading etc.
- Conclusion:
OpenShift is a great PaaS that provides multiple facades for Developers, Operations, Security etc. One of its great capabilities is its integrated use of Kubernetes operators that has been further enhanced using a life cycle manager. All of its ease of use is provided right into the browser console.
When this Operator capability gets combined along with other OpenShift capabilities like OpenShift Pipelines, it brings in a greater level of agility to a solution lifecycle.
Here in this writeup we explored the possibilities of turning a legacy eCommerce application into a containerized new generation solution with push button or automated scalability, all made simple by the using of SAP Hybris Operator and OpenShift 4.x.
- References: