B2B e-commerce dla Inter Cars: jak stworzyliśmy system dla 16 krajów oparty na SAP Hybris Commerce

Wyzwanie 1: Model danych rynku automotive

Każdy, kto choć raz próbował kupić część do swojego samochodu, np. opony lub klocki hamulcowe, musiał zauważyć że specyfika takich zakupów znacznie się różni od kupowania aparatu fotograficznego czy T-shirtu. Zaczynamy od wybrania własnego pojazdu, tak aby oferta sklepu pokazywała wyłącznie produkty które do niego pasują. Baza pojazdów obejmuje samochody osobowe, ciężarówki, motocykle i inne pojazdy specjalne.

Pojazdy te są standaryzowane przez bazę danych TecDoc, która zawiera ponad sto tysięcy rekordów zawierających dane o:

• producencie pojazdu
• modelu pojazdu
• rodzaju silnika
• roczników produkcji
• wersjach nadwozia i wyposażenia dodatkowego

Zakładając że w bazie mamy ponad milion produktów i każdy może pasować do wielu pojazdów, to z technicznego punktu widzenia daje macierz powiązań o wielkości ponad 100.000 x 1.000.000 rekordów. Jednak praktycznie jest to macierz "rzadka", ponadto w ofercie znajduje się wiele produktów niezależnych od pojazdu, jak akcesoria czy wyposażenie warsztatów. Ponadto niekiedy jeden produkt może pasować do wielu pojazdów, ale w różnych kontekstach, np. popularna żarówka 5W może w jednym pojeździe służyć jako żarówka świateł pozycyjnych, w innym jako podświetlenie tablicy rejestracyjnej, a w jeszcze innym jako lampka do czytania w kabinie pojazdu.

Aby uwzględnić te wymagania, w finalnej wersji systemu zawarliśmy ponad 200 dodatkowych własnych i rozszerzających standardowe typów w modelu danych, ponad 50 nowych typów enumerowanych i ponad 100 dodatkowych relacji pomiędzy typami.

Wyzwanie 2: Import danych do katalogu produktów

Dane w katalogu produktów w aplikacji sprzedażowej pochodzą z dwóch źródeł: wspomnianej bazy TecDoc oraz z własnego systemu PIM (ang. Product Information Management) klienta. Ze względu na bardzo duży wolumen, częste zmiany danych, brak możliwości eksportu danych różnicowych oraz brak ujednoliconego interfejsu (WebService, szyna ESB, itp.) niemożliwe było zastosowanie standardowego mechanizmu integracji stosowanego w Hybris, jakim jest Data Hub.

Aby spełnić założenia przy takich warunkach, zastosowaliśmy całkowicie "customowe" rozwiązanie polegające na pobieraniu danych bezpośrednio z systemu PIM przez protokół JDBC z użyciem biblioteki QueryDSL i umieszczaniu w bazie Hybris bezpośrednio przez API. Dodatkowo dla zwiększenia wydajności użyliśmy importu przez tzw. "ServiceLayer Direct", czyli szybszy rodzaj API programistycznego dodany do Hybris w wersji 6.0 i mający docelowo zastąpić starszy i wycofywany już "JALO layer".

Ostatnim wyzwaniem było zarządzanie kolejnością i równoległością wykonania importów poszczególnych typów danych, ponieważ mają one inne cykle aktualizacji. Z jednej strony zależą od siebie (np. zdjęcia można importować dopiero po zakończeniu importu danych podstawowych produktów) ale z drugiej strony, import różnych typów danych może działać równolegle w celu przyspieszenia działania. Do definiowania i nadzorowania tego procesu zaimplementowany został dedykowany koordynator.

Ostatecznie rozwiązanie do importu danych zawierało ponad 150 własnych klas w języku Java (z wyłączeniem kodu generowanego automatycznie) z łączną ilością ponad 20.000 linii kodu plus kod testów jednostkowych.

Wyzwanie 3: Interfejs użytkownika

Naszym celem było stworzenie aplikacji, która jest wygodna i przyjazna w obsłudze. W praktyce dotyczyło to 5 obszarów.

Elementy Single Page Application

Standardowy interfejs użytkownika dostarczany przez Hybris to klasyczna aplikacja server-side, w której klient przechodzi przy pomocy przeglądarki WWW pomiędzy kolejnymi stronami HTML z "przeładowaniami". Współczesne aplikacje do których są przyzwyczajeni klienci (jak np. Facebook) często działają w modelu SPA (ang. Single Page Application), w którym kolejne kroki wykonywane przez klienta powodują zmianę zawartości strony ale bez "przeładowania" jej całości. Aby zapewnić podobne wrażenia z używania aplikacji sprzedażowej zastosowaliśmy w wybranych obszarach, np. widgetcie wyboru pojazdu, elementy SPA z użyciem stworzonego frameworku JavaScript korzystającego wewnętrznie z popularnej biblioteki jQuery dostępnej także w Hybris.

Dedykowane wyszukiwarki produktowe

Stworzyliśmy wspólnie z klientem, w oparciu o ich specjalistyczną wiedzę i potrzeby końcowych użytkowników, 5 dedykowanych wyszukiwarek produktowych pozwalających na szybkie znalezienie popularnych produktów, np. wyszukiwarki opon z uwzględnieniem rozmiarów pasujących do wybranego pojazdu, pory roku, indeksu prędkości czy obciążenia czy preferowanego producenta.

Takie wyszukiwarki dostosowane do istniejących przyzwyczajeń klientów znacząco ułatwiają znalezienie produktu w porównaniu do domyślnego, "płaskiego" mechanizmu filtrów dostępnego w Hybris.

Wykorzystanie skrótów klawiszowych w procesie zamawiania

Badanie eksploracyjne grupy docelowej wykazało, że duża część osób, przyzwyczajonych do klasycznych aplikacji desktopowych, wykorzystuje głównie skróty klawiszowe. Dlatego dopracowaliśmy interfejs w taki sposób, by możliwe było znalezienie produktu oraz złożenie zamówienia bez użycia kursora myszki - wyłącznie z użyciem skrótów klawiszowych.

RWD

Interfejs w pełni działa w różnych wielkościach okna przeglądarki WWW, czyli wspiera RWD (ang. Responsive Web Design). Wspomniane badania wykazały, że część użytkowników w pracy chce korzystać z tabletów zamiast komputerów stacjonarnych. Dlatego aplikacja musi działać poprawnie z użyciem kliknięć w duże przyciski i różnego rodzaju "przeciągnięć", specyficznych dla urządzeń obsługiwanych palcami.

Niestandardowe wyszukiwania

Aplikacja musi obsługiwać niestandardowy typ wyszukiwania produktów, jakim są schematy produktów i podzespołów. To kolejny element specyfiki zakupów w branży automotive: często mechanik nie zna nazwy ani wyglądu części, tylko wyszukuje ją na schemacie graficznym pomiędzy innymi elementami. Taka funkcjonalność, oprócz samego przeglądania, prezentacji danych produktu na schemacie i możliwości dodania do koszyka, wymagała także stworzenia edytora wizualnego w którym menedżerowie odpowiedzialni za dane produktów umieszczają niezbędne dane na obrazkach.

Wyzwanie 4: Wydajność aplikacji

Platforma Hybris ma standardowe założenia dotyczące wydajności serwisu przy założonych parametrach wejściowych, jak ilość produktów, klientów, liczba odsłon, itp. Niestety, w przypadku tak niestandardowego projektu jak nasz, te założenia szybko okazały się bezużyteczne.

Aby sprostać problemowi wydajności, w ramach projektu powołaliśmy dedykowany zespół, którego pierwszym zadaniem była implementacja testów obciążeniowych z użyciem narzędzia Gatling - dostarczały one informacji o szybkości działania interfejsu aplikacji w ważnych scenariuszach biznesowych, jak przeglądanie katalogu produktów, dodawanie do koszyka i składanie zamówienia.

Na podstawie takich danych, kolejnym zadaniem była identyfikacja najwolniejszych elementów aplikacji (ang. bottleneck), ich analiza przy pomocy narzędzi do profilowania takich jak JProfiler i DynaTrace, a następnie optymalizacja kodu, optymalizacja modelu bazy danych, stosowania mechanizmu cache'a danych rzadko zmieniających się, itp.

Niezależne prace dotyczyły silnika wyszukiwania pełnotekstowego z użyciem biblioteki SOLR, który mimo że jest częścią Hybris, wymagał niezależnej optymalizacji przy współpracy z konsultantami zewnętrznymi.

Osobnym ale równie ważnym zadaniem była optymalizacja wydajnościowa wspomnianego wyżej mechanizmu importu danych z systemów zewnętrznych.

Wyzwanie 5: Duża ilość mniejszych dedykowanych rozwiązań

Stworzenie tak dużej i zaawansowanej aplikacji obejmowało także szereg innych zagadnień, spośród nich na szczególną uwagę zasługują:

• wielokrajowość (docelowe wdrożenie na 16 rynków) z interfejsem i danymi w wielu językach
• spersonalizowane (różne) ceny dla każdego klienta, pobierane online z systemu ERP
• możliwość złożenia zamówienia zawierającego tylko podzbiór produktów znajdujących się w koszyku
• integracja z CDN do przechowywania milionów zdjęć produktów
• złożony algorytm sortowania wyników wyszukiwania produktów pod względem "biznesowym"
• mechanizm "anti-scraping" uniemożliwiający masowe kopiowanie danych produktów
• implementacja uwierzytelnienia i autoryzacji użytkowników (SSO) z użyciem standardu "OpenID Connect"
• ograniczenie widoczności informacji oraz funkcji aplikacji w zależności od wielu możliwych ról użytkowników

Podsumowanie

Z punktu widzenia pracowników technicznych (programiści, front-end developerzy, architekci, testerzy) ten projekt pokazuje skalę możliwości Hybris w zakresie dostosowania platformy do niestandardowych rozwiązań, ilości przechowywanych danych i szybkiego działania.

Specyfika, wielkość i dynamika zmian tego rynku sprawia że aplikacja sprzedażowa będzie na bieżąco dostosowywana do zmieniających się wymagań, a wiedza i doświadczenie naszego zespołu zapewnią profesjonalne wsparcie tych zmian.