B2B e-commerce for Inter Cars: how we developed a SAP Hybris Commerce-based system for 16 countries

The Universal Sales Application (USA) project for Inter Cars was a great technological and organizational challenge for our team. That was due to many aspects: the choice of a technological solution, specific automotive industry requirements and arrangements regarding the method of integration with other systems that changed mid-project.

The SAP Hybris Commerce (henceforward referred to as “Hybris”) is a finished e-commerce framework implemented in Java 8 and the popular Spring framework. Very simply stated, it allows to almost immediately launch a finished online store in both B2C and B2B models. All you need to do is enter your products via the administration panel, configure it to run under the selected domain, switch on the server, and you’re ready to sell online. It sounds as if it doesn’t require input by any programmer – so what was a team consisting of a few dozen members doing for over 12 months?

Challenge 1: Automotive market data model

Anyone who at least tried to buy a part for their car, e.g. a tire or brake pads, had to notice that the specific nature of purchasing these products significantly differs from buying a camera or a T-shirt. We start by choosing the make of our motor vehicle, so that only products that match it will be displayed in the store. The database includes passenger cars, lorries, motorcycles and other special purpose and is standardized by the TechDoc, which is estimated to be over one hundred thousand records with data about:

• Producer
• Model
• Engine type
• Year of the production
• Car body and additional equipment

Assuming that the products database contains over a million items and each of them may match numerous motor vehicles, then from a technical standpoint this creates a matrix of connections numbering in over 100,000 x 1,000,000 records. In practice, however, it is a “sparse” matrix and the product offer features many products independent from vehicles, such as accessories and repair shop equipment. In addition, at times a single product may match many vehicles, but in different contexts, e.g. a popular 5W bulb may be used in position lights in one vehicle, in registration plate lighting in another, or in a reading lamp in the cabin of yet another vehicle.

In order to take those requirements into account, in the final system version we have included over 200 additional types in the data model, both own and those expanding on standard types, over 50 new enumerated types and over 100 additional relations between types.

Challenge 2: Importing data to the product catalog

Data included in the product catalog featured in the sales application originate from two sources: the aforementioned TecDoc and the customer’s own Product Information Management (PIM) system. Due to the very large volume of data, its frequent change, the inability to export differential data and absence of a universal interface (WebService, ESB, etc.), it was not possible to apply the standard integration mechanism used in Hybris, i.e. the Data Hub.

In order to meet the assumptions in these conditions, we have applied a completely “custom” solution consisting in the import of data directly from the PIM system via the JDBC protocol using the QueryDSL library and including this data in the Hybris database directly via API. In addition, in order to improve efficiency, we decided to utilize import via the so-called “ServiceLayer Direct”, i.e. the fastest type of programming API added to Hybris in version 6.0 and aimed to ultimately replace the older and already discontinued “JALO Layer”.

The final challenge was managing the order and parallelism of importing specific data types, as they have different update cycles. On one hand they are dependent on each other (e.g. images can be imported only after completing the import of basic product data), while on the other hand different types of data can be imported simultaneously to streamline operation. A dedicated coordinator was implemented to define and supervise this process.

Ultimately, the data import solution included over 150 own classes in the Java language (excluding automatically generated code) with a total number of over 20,000 lines of code plus unit test code.

Challenge 3: User interface

Our objective was to develop an application that is convenient and user-friendly. In practice, this concerned 5 areas.

Single Page Application elements

A standard user interface delivered by Hybris is a classic server-side application where the customer moves through subsequent HTML pages with “reloadings” via a web browser. Modern applications to which customers are accustomed (such as Facebook) often operate in the Single Page Application (SPA) model where subsequent steps taken by the customer change the website content but without “reloading” it in its entirety. In order to ensure that users enjoy a similar experience by using the sales application, we have applied SPA elements in selected areas, e.g. in the vehicle choice widget, using the developed JavaScript framework that internally utilizes a popular jQuery library that is also available in Hybris.

Dedicated product search engines

Together with the client, we have developed 5 dedicated product search engines that allow to find popular products quickly, e.g. tire search engines that take into account sizes that match the selected vehicle, season of the year, speed index, load or preferred manufacturer. Such search engines tailored to existing customer habits significantly facilitate finding a product, as compared to the default, “flat” filtering mechanism available in Hybris.

Use of keyboard shortcuts in the order placement process

A target group study showed that a large number of people, used to classic desktop applications, predominantly use keyboard shortcuts. That is why we have developed the interface in such a way, so as to ensure that it is possible to find a product and place an order without using a mouse cursor – using keyboard shortcuts only.

RWD

The interface is fully functional in different web browser window sizes, i.e. supports Responsive Web Design (RWD). The aforementioned studies showed that a number of users uses tablets at work in place of desktop computers. For this reason, the application must operate correctly when clicking on large buttons and various types of “swipes” specific to finger-operated devices.

Non-standard searches

The application must support non-standard product search types, i.e. product and component frameworks. It is yet another element of the specific nature of making purchases in the automotive industry: a mechanic often doesn’t know the name or appearance of the part, but rather searches for it on a schematic diagram between other elements. Apart from browsing, product data presentation on the diagram and the option to add products to the shopping cart, this functionality also required creating a visual editor in which managers responsible for product data place necessary data on images.

Challenge 4: Application efficiency

The Hybris platform has standard assumptions regarding application efficiency with certain assumed entry parameters, such as the number of products, customers, views, etc. Unfortunately, in the case of such non-standard project as ours, these assumptions quickly proved useless.

In order to face the efficiency challenge, we have appointed a dedicated project team whose first task was to implement stress tests using the Gatling tool – they provided information about the application interface operation speed in important business scenarios, such as browsing the product catalog, adding products to the shopping cart and placing an order.

Upon obtaining this data, another task was to identify the slowest elements of the application’s bottlenecks, analyze them using profiling tools such as JProfiler and DynaTrace, and then to optimize the code, optimize the database model, apply the rarely changing data cache mechanism, etc.

Independent works concerned the full-text search engine utilizing the SOLR library, which despite being part of Hybris required independent optimization in cooperation with external consultants.

A separate, but equally important task was to optimize the efficiency of the aforementioned mechanism for importing data from external systems.

Challenge 5: Large number of smaller dedicated solutions

Developing such large and advanced application also required solving a number of other issues, chief among them:

• multi-nationality (to be ultimately implemented in 16 markets) with a user interface and data in many languages
• personalized (differing) prices for each customer, imported online from the ERP system
• option to place an order containing only a sub-set of products added to the shopping cart
• integration with CDN storing millions of product photos
• a complex algorithm for sorting product search results from the “business” perspective
• an “anti-scraping” mechanism preventing mass copying of product data
• implementation of user authentication and authorization (SSO) using the “OpenID Connect” standard
• limiting the visibility of information and application functions depending on different possible user roles

Summary

From the perspective of technical workers (programmers, front-end developers, architects, testers), this project shows the scale of Hybris’ capabilities as regards the adaptation of the platform to non-standard solutions, the volume of stored data and quick operation.

The specific nature, scale and dynamic rate of change on this market means that the sales application will have to be adapted to changing requirements on a continuous basis. The knowledge and experience of our team will ensure professional support in the implementation of those changes.