When I started working with Hybris, I only knew it was a Java Spring based, enterprise-level, eCommerce platform offering B2C and B2B store functionality. I had heard good things about it: that it is flexible, scalable, integrates well with SAP and offers a rich set of add-ons.
With 25 years of development experience, including the last six years working with the Java Spring Framework, I was confident I would quickly grasp this new framework. How hard could it be? It was written by humans after all...
As it turns out, quite hard.
First a bit of a background. My company, CNBS Software, has been working in the area of SAP eCommerce for many years as an exclusive US Distributor of WECO eCommerce. Over the last few years, our customers have become curious about SAP C/4 HANA, more precisely, SAP Hybris Commerce Cloud solutions. Many of them came to us looking for recommendations and strategic advice on if (and how) SAP C/4HANA as a Commerce Cloud solution can help them in the future. This all being especially important when they start their transition to S4 HANA.
I was tasked with setting up Hybris eCommerce and SAP Commerce Cloud environments that mirrored our WECO demo environment. They could be used as a testbed to replicate some of the most complicated eCommerce scenarios and SAP workflows. We have done many SAP eCommerce implantations over the years and wanted to see how SAP Hybris can handle some of the more interesting cases (like SAP variant configuration, freight shopping, payment integration, PunchOut functionality, etc.) that we have done successfully using WECO eCommerce over the years.
My first step in this journey was: How does SAP Hybris work? I found documentation that walked me through the SAP Commerce package to get an out of the box (OTB) Hybris system up and running. The process was pretty straight forward. First, I unzipped the current version of the SAP Commerce package downloaded from SAP. Then I installed the recipe for the OTB system I wanted to play with. The Install Recipe is Hybris system for helping you get a base system with the functionality you want for your intended purposes, (B2B, B2C, or B2B & B2C). This installed the basic OTB system. The missing piece was a custom storefront accelerator to enable us to make the changes needed to develop the demo site. This was easily remedied by using the modulegen tool to create our custom accelerator, which I named ´chd´ (short for CNBS Hybris Demo). Afterwards I was able to initialize and run Hybris to see the OTB B2B powertools storefront.
This is where I hit my first pain point. I saw no evidence that my custom chd site had been created.
The modulegen process creates a number of extensions to implement the custom storefront accelerator, one of them being chdinitialidata. This is the extension for all the data files, called impex files, used to populate the custom website. There is data for both the look/feel of the site, known as the Content Management System, and the site´s catalog and products. The problem was all the config files (impex files) were left as templates files, leaving the population process to me.
The first thing I noticed was all these impex data files started with a naming convention of two underscores around the concept, such as the content catalog name and content
$contentCatalog=__CONTENT_CATALOG_NAME__
Solution: Leverage the ant runantbind process to replace all these names with actual values in all 103 default impex files.
An Internet search for __CONTENT_CATALOG_NAME__ and Hybris turned up one blog on the topic of how to use ant-bind-impex-template.xml to do the mass search and replace. After setting up the ant-bind-impex-template.xml correctly and running ant runantbind, I hit my next pain point: understanding the naming convention.
Solution: I looked at how the powertools storefront impex files were structured and changed the chdinitialdata structure to follow the same convention. It took a number of iterations because it took a while to uncover where all 103 impex files were located. It was a good (if time-consuming) exercise that taught me a lot. I concluded that with a customer who only needs one site, I would have kept the original templates to simplify hierarchy and modified the Java code instead of replicating Hybris´ multi-site naming conventions. This is easier for other developers to understand and would keep things simple and clear for others maintaining the system later. Taking a little extra time up front always saves the customer time and money on the backend.
After reinitializing the system, I had high hopes that I might see the beginnings of the new chd site. I was not so lucky - there was still no evidence.
Solution: I had to figure out how to copy one of the existing storefronts.
After comparing the impex files in the chdinitialdata extension to those in powertools, I discovered there was not much of anything in the chdinitialdata files. I ended up copying the contents of all 140 impex files in the powertools storefront extension to chdinitialdata, and then modifying all the parameters to link to the chd site.
Now I had two storefronts – the powertools site, and my custom site looking the same. But when I removed powertools I hit my next pain point. Everything broke.
Solution: I discovered that impex files critical to the CMS configuration were actually scattered through all the other extensions. When I removed the powertools site, I removed some necessary configuration as well. To fix this, I tracked down all these other impex files, copied them into chdinitialdata and modified all the parameters to link to the chd site. It worked!
Now we have a fully functioning demo site: CNBS Electronics Store is up and running. The next step is to add custom features so my colleagues and I can hone our skills and show off what Hybris can do.
Over several blog posts though the year, I will try to cover some of the more interesting integration scenarios and my learnings, as well as highlight how we addressed some real-world business cases using Hybris and Commerce Cloud.