Technical training

Hybris - Core trail

21
20
/
03
/
11

SQLI
 HYBRIS CORE
OVERVIEW

+ This part of the training aims to:

 Illustrate the core functionality and main
concepts of the hybris Platform
 Demonstrate the software
 Give the idea of what’s available out-of-the-
box and what has to be implemented
 Give you a chance to write a “hello world” for
each area presented

@SQLI
© SQLI2021
2013 2
 Be
fo
re
yo
u
sta
rt

3
 BEFORE YOU START
ONLINE RESOURCES

+ Hybris Wiki

+ Hybris Help

+ Hybris Expert

@SQLI
© SQLI2021
2013 4
 BEFORE YOU START
RELEASES

+ Backward compatibility
+ Previous release is supported up to 24
months upon availability of newer (unless
yours SLA specifies different)
+ Easy upgrades
+ Numbering convention:

1905
Year. Month

@SQLI
© SQLI2021
2013 5
 A
r
O c hi
ve te
rv ctu
ie re
w

6
 ARCHITECTURE OVERVIEW

BASIC ARCHITECTURE

• SAP Hybris Commerce is divided into individual packages.

• Packages consist of individual modules, also referred to as extensions.

@SQLI
© SQLI2021
2013 7
 ARCHITECTURE OVERVIEW

BASIC ARCHITECTURE

• Extension :
• Represents the technical structure of a module.
• Can contain business logic, type definitions, a web application, or other

• Extensions are written by hybris or the implementation partner of your project.

• A full hybris Commerce Suite installation therefore consists of:
• The hybris Platform. Custom Custom
Packag Extensi Packag Extensi Packag
• A hybris packages.
e on e on e
• Custom extensions. Platform

@SQLI
© SQLI2021
2013 8
 ARCHITECTURE OVERVIEW
BASIC ARCHITECTURE

@SQLI
© SQLI2021
2013 9
 ARCHITECTURE OVERVIEW

LAYER ARCHITECTURE

SAP Hybris Commerce contains several layers, each of which has a different
function and data abstraction level.

@SQLI
© SQLI2021
2013 10
 ARCHITECTURE OVERVIEW

MODES OF OPERATION

Single mode

@SQLI
© SQLI2021
2013 11
 ARCHITECTURE OVERVIEW

MODES OF OPERATION

Cluster mode

@SQLI
© SQLI2021
2013 12
 ARCHITECTURE OVERVIEW

MODES OF OPERATION

Tenant mode

@SQLI
© SQLI2021
2013 13
Ex
co te
n c nsi
e p on
t
 EXTENSION CONCEPT
DEFINITION

Extension : project with its own data model and business logic.

Goal: keeping CUSTOM code separated from Hybris code, making the custom code easier to reuse
nd to migrate to future versions.

 Extensions are encapsulated modules, which can contain:

• business logic
• data model definition
• web application
• Backoffice configuration
• ….etc
 By default: independent from other extensions (except platform)
 Extension concept benefit: Easy to migrate and update

Always use your own extension to create, extend or overload existing hybris business logic

@SQLI
© SQLI2021
2013 15
 EXTENSION CONCEPT
STRUCTURE OF AN EXTENSION

.externalToolBui Contains the Eclipse builder that

lders automatically generates Hybris Models if any
extension's items.xml file has been modified
in Eclipse.
.settings Contains configuration files for Eclipse
lib All external library files should be stored
here
resources Contains the <$extension> -items.xml file
and the localization for the extension types
(within the /localization subdirectory).

src , testsrc Contains the source code & junit tests files
web This directory contains the web extension
module parts of the extension (JSP files,
libraries).
.classpath Classpath file for Eclipse.
@SQLI
© SQLI2021
2013 16
 EXTENSION CONCEPT
STRUCTURE OF AN EXTENSION

pmd , ruleset Control file, Ruleset file for PMD with

Hybris-specific settings.

project Project file for Eclipse.

buildcallbacks.x Allows you to implement custom build

ml framework logic.

extensioninfo.xm Configures the extension modules. This

l file is used by the build framework. It
also determines which extensions are
required for proper functioning.
project.properties Configuration properties for the
extension.
external- Third party dependencies of Hybris
dependencies.xm Commerce extensions are defined here.
l
@SQLI
© SQLI2021
2013 17
 EXTENSION CONCEPT
STRUCTURE OF AN EXTENSION

During an extension build, some additional

directories and files are created:

classes Contains all .class files for src, testsrc and gensrc
folders of the extension.
build.xml This build file calls the Platform build file for actual
action and provides the necessary parameters to it.
This way ant targets are consistent throughout the
entire installation.
extensioninfo.xsd Copied from <${HYBRIS_BIN_DIR}>
/platform/resources/schemas. Allows validating the
extensioninfo.xml file.
platformhome.properties Automatically generated file. It contains only the
relative path to <${HYBRIS_BIN_DIR}>/platform.
@SQLI
© SQLI2021
2013 Do not modify it. 18
 EXTENSION CONCEPT
CONFIGURATION FILES

Each extension has:

project.properties with extension-specific configuration
extensioninfo.xml with extension dependencies configuration
<extension-name>-items.xml: Hybris data Model is defined in this xml file, new data types for ext
s called item types,

or global settings and to override any extension specific configuration always use the config folder,
local.properties
 Overrides any properties specified in each extension project.properties file
 Introduces global properties like database url and credentials
localextensions.xml
 List of extensions used by build framework
Beside that: configuration templates for bundled servers, language packs, license,

@SQLI
© SQLI2021
2013 19
 EXTENSION CONCEPT
BUILD FRAMEWORK

nt & Eclipse compiler to automatically run tasks such as code generation and copying, parsing, and
es.

AP Hybris Commerce as a whole consists of extensions of the Hybris Platform plus any other product
y referencing an extension in the localextensions.xml file, that extension is integrated into the SAP H
ommerce build framework.
Build Scope:
• platform-wide: Hybris Platform and all extensions
• extension-wide: Current extension only

When you call ant, the build framework:

• generates and compiles “Model” classes
 according to the definitions in the *-items.xml files
 In order of extensions dependency (hierarchy)
 collects localization property files (locales_XY.properties).
 ….etc

@SQLI
© SQLI2021
2013 20
 EXTENSION CONCEPT
BUILD TARGETS

@SQLI
© SQLI2021
2013 21
 EXTENSION CONCEPT
AVAILABLE CONTEXTS

@SQLI
© SQLI2021
2013 22
 EXTENSION CONCEPT
AVAILABLE CONTEXTS

@SQLI
© SQLI2021
2013 23
D
at
aM
od
el
 DATA MODEL

data model underlying SAP Hybris Commerce is defined in XML files.

w data types for extensions, called item types, are defined in <extension-name>-items.xml files.

P Hybris Commerce uses a system of types to organize data, for example product information, custom
resses, or orders.

@SQLI
© SQLI2021
2013 25
 DATA MODEL
ITEMS AND TYPES

There are two major kinds of types: System-related types and business-related types.

 System-related types:
• Infrastructure types: ComposedTypes (also referred to as ItemTypes)
• Data types: CollectionTypes, MapTypes, EnumerationTypes, and AtomicTypes.

 Business-related types: like Order, Discount, Shoe.

@SQLI
© SQLI2021
2013 26
 DATA MODEL
JAVA CLASSES VS HYBRIS TYPES

@SQLI
© SQLI2021
2013 27
 DATA MODEL
TYPES AND ATTRIBUTES

@SQLI
© SQLI2021
2013 28
 DATA MODEL
ATTRIBUTES OF A (COMPOSED) TYPE

@SQLI
© SQLI2021
2013 29
 DATA MODEL
EXTENDING THE DATA MODEL

Create new types:

• Define a type by extending already existing types, such as:

• Define “completely new types”, such as:

Extend existing types:

• Add attribute definitions to existing types (attribute injection), such as:

• Add attribute definitions to existing types (attribute injection), such as:

@SQLI
© SQLI2021
2013 30
 DATA MODEL
EXTENDING

@SQLI
© SQLI2021
2013 31
 DATA MODEL
ATTRIBUTES

@SQLI
© SQLI2021
2013 32
 DATA MODEL
ENUMERATED TYPES

@SQLI
© SQLI2021
2013 33
 DATA MODEL
COMPOSED TYPE REFERENCE

@SQLI
© SQLI2021
2013 34
 DATA MODEL
RELATIONS

@SQLI
© SQLI2021
2013 35
 DATA MODEL
TABLE STRUCTURE

@SQLI
© SQLI2021
2013 36
 DATA MODEL
AUTOMATIC GENERATION

@SQLI
© SQLI2021
2013 37
 DATA MODEL
INITIALIZE & UPDATE SYSTEM

System Initialization:
• Entire type system is created from scratch.
• ALL database tables are dropped.
• Data model is created from scratch as defined in the items.xml files.
• New tables with initial dataset are created
• Existing data model definitions will be lost!

System Update:
• Existing tables are updated to match changes in the domain model.
• No loss of data!
• Two major aspects:
 Adding newly defined types to the type system definition in the database
 Modifying type system definition in the database to match the definition in the domain mode

Or using ant : ant updatesystem & ant initialize

@SQLI
© SQLI2021
2013 38
 DATA MODEL
DATA BASE

• By default, all items for subtypes are stored in the same database tables as their supertypes.
• Technically, the process of specifying into which database table the items of a type are stored is ca
deployment

• Each Item type can have its own db table:

 specify deployment only for the first layer of GenericItem subtypes

@SQLI
© SQLI2021
2013 39
 BUNDLED SERVER
WHAT IS THE HYBRIS SERVER

@SQLI
© SQLI2021
2013 40
 BUNDLED SERVER
WHAT IS THE HYBRIS SERVER

 Optimized and pre-configured server based on Apache Tomcat

 Production-ready quality and best suited to run all applications of the hybris
Multichannel Suite

 Configuration templates available for development and production deployment

 Independent of the operating system

 Easy installation

 Can be run as a system service under Microsoft Windows or Linux

 Contains a wrapper that automatically restarts the Apache Tomcat Java Virtual Machine
if the Apache Tomcat hangs or stops.
@SQLI
© SQLI2021
2013 41
 Im
po
rt
Ex a nd
po
rt
 IMPORT AND EXPORT
IMPEX

ImpEx: is an out-of-the-box import / export framework

It’s an interface between CSV files and the hybris Multichannel Suite’s Type System
• you can “import” instances of types from CSV.
• you can “export” instances of types into CSV.

You can create, update, export, and remove items

@SQLI
© SQLI2021
2013 43
 IMPEX
TYPICAL FIELDS PF USE

• In live operation:
 to import customer data into a production system
 to synchronize data with other systems, such as an ERP or LDAP
 to create backups
 to update data at runtime
 can be run from CronJobs

• In migrations:
 to migrate data from one hybris installation to another

• In development:
 to import sample data (e.g. on system initialization)
 to import test data into testing system

@SQLI
© SQLI2021
2013 44
 IMPEX
SYNTAX BASICS

@SQLI
© SQLI2021
2013 45
 IMPEX
BASIC SYNTAX EXAMPLE

@SQLI
© SQLI2021
2013 46
 IMPEX
SYNTAX ELEMENTS

@SQLI
© SQLI2021
2013 47
 IMPEX
CATALOG EXAMPLE

@SQLI
© SQLI2021
2013 48
 IMPEX
USING MACROS AND DEFAULTS

@SQLI
© SQLI2021
2013 49
 IMPEX
MORE EXAMPLE

@SQLI
© SQLI2021
2013 50
 IMPEX
SCRIPT FOR EXPORT

@SQLI
© SQLI2021
2013 51
 IMPEX
WHERE IMPEX CAN BE EXECUTED

HMC: Create an
HAC
ImpExImportCronJob or
ImpExImportCronJob

Or Via the API You can use the ImportService

@SQLI
© SQLI2021
2013 52
 IMPEX
ESSENTIAL DATA VS. PROJECT DATA

ssential Data:
ecessary during initialization: Creates the Default catalog, restrictions, and basic CronJobs, for exam
roject Data:
xtension-specific project data

@SQLI
© SQLI2021
2013 53
 Fl
ex
Se ib
ar le
ch
 FLEXIBLE SEARCH
OVERVIEW

• SQL-like syntax

• Abstracts a database query into a hybris Item query

• Returns a list of objects (hybris Items)

• Makes properties easily queryable

• Is translated into native SQL statements on execution

• Allows nearly every feature of SQL SELECT statements

• Queries go through cache

@SQLI
© SQLI2021
2013 55
 FLEXIBLE SEARCH
SYNTAX

@SQLI
© SQLI2021
2013 56
 FLEXIBLE SEARCH
QUERY EXAMPLES

@SQLI
© SQLI2021
2013 57
 FLEXIBLE SEARCH
MORE QUERY EXAMPLES

@SQLI
© SQLI2021
2013 58
 FLEXIBLE SEARCH
QUERYING WITH PARAMETERS

@SQLI
© SQLI2021
2013 59
 Th
eS
er
la vi
ye ce
r
 SERVICE LAYER
OVERVIEW

The Hybris ServiceLayer is an API for developing services for SAP Hybris Commerce.
t provides a number of common services, while allowing you to extend these or develop your own.

• It is based on a service-oriented architecture.

• It provides a clean separation of business logic and persistence logic.
• It provides a number of services, each with its well-defined responsibilities.
• It provides a framework to develop your own services and to extend existing ones.
• It is heavily based on the Spring Framework.
• It is based on common patterns, such as interface-oriented design and dependency injection
• It is the layer where partners should implement their business logic.
• It provides hooks into model life-cycle events for performing custom logic.
• It provides hooks into system event life-cycle events such as init and update process.
• It provides a framework for publishing and receiving events.
@SQLI
© SQLI2021
2013 61
 SERVICE LAYER
STRUCTURE OVERVIEW

@SQLI
© SQLI2021
2013 62
 SERVICE LAYER
STRUCTURE OVERVIEW

A client in this context is any software component that uses the ServiceLayer, such as:
• Page Controllers of an MVC framework
• Web Service clients
• Scripts
• Other services

Services: hold the logic to perform business processes

@SQLI
© SQLI2021
2013 63
 SERVICE LAYER
SERVICES

 SAP Hybris Commerce exposes all of its functionality through services:

• Business Services.
• Infrastructure Services.
• System services.

The service methods should be as fine-grained as possible to enable reuse.

Extensions must provide their functionality as services.

Services may use other services to perform their tasks but should keep their interdependencies to a
avoid overly tight coupling with other components

@SQLI
© SQLI2021
2013 64
 SERVICE LAYER
STRATEGIES

A service may delegate parts of its tasks to smaller micro-services, called strategies.
Strategies help to further encapsulate behavior and make it more adaptable/usable.

@SQLI
© SQLI2021
2013 65
 SERVICE LAYER
DAO & MODEL

DAO (Data Access Object):

• save, remove, and find models.
• SQL or FlexibleSearch statements
• interact with services via models and with the database via FlexibleSearch and SQL statement
Models:
• are a way to represent Hybris items, whereby each of these items is represented by a Model cla
• Each Model contains all item attributes from all extensions thus unifying access to an item's da
• During a Hybris build, the build framework generates Model classes and configuration files fo
each item type.
• Models are generated into the bootstrap/gensrc directory.
• Created by ProductModel product = modelService.create(ProductModel.class); or
ProductModel product = new ProductModel();

@SQLI
© SQLI2021
2013 66
 SERVICE LAYER
MODEL LIFE CYCLE

A Model represents a state in the database. The representation is not live,

that means that modified Model values are not written to the database automatically.
Instead, when you modify a Model, you must explicitly save it to the database to have its state refle

@SQLI
© SQLI2021
2013 67
 SERVICE LAYER
HOOKS FOR INITIALIZATION AND
UPDATE PROCESS

ou may use the @SystemSetup annotation in any ServiceLayer class to hook ServiceLayer
to the Hybris initialization and update life-cycle events.
Spring Configuration of Java Class

The Java classes, in which the @SystemSetup annotation is used, must be registered as Spring beans
n the ApplicationContext:

Example:

@SQLI
© SQLI2021
2013 68
 SERVICE LAYER
INTERCEPTORS OVERVIEW

 There are various types of interceptors allowing you to interrupt the intended course of a Model’s l

 An interceptor addresses a particular step in a Model's life cycle

 With interceptors, you can modify a Model or raise exceptions to interrupt the current step

g. certain values may be validated before a Model is saved

 An interceptor is registered as a Spring bean

@SQLI
© SQLI2021
2013 69
 SERVICE LAYER
INTERCEPTORS

@SQLI
© SQLI2021
2013 70
 SERVICE LAYER
IMPLEMENTING INTERCEPTORS

To create an interceptor, one the following interfaces needs to be implemented:

 The LoadInterceptor is called whenever a model is loaded from the database

 The InitDefaultsInterceptor is called to fill a model with its default values

 The PrepareInterceptor is called before a model is saved to the database and before it i
by ValidateInterceptor

 The ValidateInterceptor is called before a model is saved to the database and after it ha
prepared by the PrepareInterceptor

 The RemoveInterceptor is called before a model is removed from the database

@SQLI
© SQLI2021
2013 71
 SERVICE LAYER
REGISTERING AN INTERCEPTOR

@SQLI
© SQLI2021
2013 72
 SERVICE LAYER
MAPPING THE INTERCEPTOR

Add a de.hybris.platform.servicelayer.interceptor.impl.InterceptorMapping to the XML file:

myextension-spring.xml

For more details: Interceptors

@SQLI
© SQLI2021
2013 73
 SERVICE LAYER
EVENTS

 The Event System is a framework provided by the ServiceLayer allowing

end and receive events within the hybris Multichannel Suite

 One software component acts as a source and publishes an event that is re

by registered listeners

 Event listeners are objects that are notified of events and perform business
corresponding to the event that occurred

 Events can be published locally or across cluster nodes

 The hybris Event System is based on the Spring event system

@SQLI
© SQLI2021
2013 74
 SERVICE LAYER
IMPLEMENTING THE EVENT SYSTEM

@SQLI
© SQLI2021
2013 75
 SERVICE LAYER
IMPLEMENTATION – EVENT LISTENERS

@SQLI
© SQLI2021
2013 76
 SERVICE LAYER
IMPLEMENTATION – EVENT LISTENERS

@SQLI
© SQLI2021
2013 77
 SERVICE LAYER
IMPLEMENTATION – EVENT LISTENERS

@SQLI
© SQLI2021
2013 78
 SERVICE LAYER
EVENTS

ote that, by default, event publishing is synchronous on the same Hybris

ultichannel Suite instance.

hat means that the current thread is locked until all listeners have reacted
an event. Therefore you should keep an eye on the performance of your list
d make sure that your code scales well.

owever, on a Hybris Cluster, the event publishing runs asynchronously on

her cluster nodes.
vents on the same cluster node are still processed synchronously.

less it is a ClusterAware event, in which case the event is always processed

ynchronously,
@SQLI
© SQLI2021
2013 79
 SERVICE LAYER
EVENT CLUSTER AWARE

@SQLI
© SQLI2021
2013 80
 SERVICE LAYER
TRANSACTION-AWARE EVENTS

@SQLI
© SQLI2021
2013 81
 SERVICE LAYER
PREDEFINED EVENTS – CLUSTERAWARE AND TRANSACTIONAWARE
EVENTS

@SQLI
© SQLI2021
2013 82
 SERVICE LAYER
PREDEFINED EVENTS – NON-CLUSTER AWARE EVENTS

@SQLI
© SQLI2021
2013 83
 SERVICE LAYER
JAVA BEANS

 Java Beans are used as transport objects for the frontend layer
 Contain an abstraction of models (subset of attributes from models)
 Are automatically generated
 Their class name, attributes or superclass are defined in xml configuration
 Each extension may provide a bean configuration file
 Definitions of these Java Beans or Enums are merged across extensions.
 Java Beans Overview

@SQLI
© SQLI2021
2013 84
 SERVICE LAYER
JAVA BEANS

@SQLI
© SQLI2021
2013 85
 SERVICE LAYER
JAVA BEANS –TEMPLATE-

@SQLI
© SQLI2021
2013 86
Cr
on
Jo
bs
 CRONJOBS
OVERVIEW

 Automated tasks
 Performed at a certain time (such as 16:05), or at
fixed intervals (such as every five minutes)
 Can be used for:
 Backups
 Updating / synchronizing catalog contents
 Imports / Exports
 Re-calculating prices
 etc…

@SQLI
© SQLI2021
2013 88
 CRONJOBS
OVERVIEW

@SQLI
© SQLI2021
2013 89
 CRONJOBS
HOW TO CREATE A CRONJOB

@SQLI
© SQLI2021
2013 90
 CRONJOBS
HOW TO CREATE A CRONJOB

@SQLI
© SQLI2021
2013 91
 CRONJOBS
HOW TO START A CRONJOB

@SQLI
© SQLI2021
2013 92
Ba
ck
of
f ic
e
 BACKOFFICE
OVERVIEW

 User-centric backend interface

 Easily manage any kind of data within a hybris system

 Specific widgets needed to create administrative and management tools:

search, list views, or navigation tree

 Hybris extension platformbackoffice, accessible by default at

http://localhost:9001/backoffice.

 The Application Orchestrator mode is used to create and modify the

application widgets without having to write any code: add widgets, configure
and connect them, configure settings and access restrictions. Accessible by
pressing F4 key in the backoffice application.

 visible to a user depends on his business role.

@SQLI
© SQLI2021
2013 94
 BACKOFFICE
OVERVIEW

@SQLI
© SQLI2021
2013 95
 BACKOFFICE
WIDGETS

@SQLI
© SQLI2021
2013 96
 BACKOFFICE
EVENT COLLABORATION

 To follow the idea of loosing dependencies between

components, the event collaboration principle is incorporated
 There is no direct communication between components
(widgets).
 Components actually do not know about each other.
 A component sends out information and all other components
receive that information. Only the ones for which the
information is valid, process it.
 A component sends out all pieces of information that might be
significant for other components. Simultaneously, it listens to
other components to get these pieces of information that are of
interest for itself.
 Ex: an item list component. It informs other components each
time an item is selected by a user, so the item detail component
@SQLI can
2013 react to it
© SQLI2021 97
 BACKOFFICE
COMMUNICATION BETWEEN WIDGETS

@SQLI
© SQLI2021
2013 98
 BACKOFFICE
WHAT CONSTITUTES A WIDGET?

@SQLI
© SQLI2021
2013 99
 BACKOFFICE
EXAMPLE WIDGET DEFINITION: PRODUCT LIST

@SQLI
© SQLI2021
2013 100
 BACKOFFICE
EXAMPLE WIDGET VIEW: PRODUCT LIST

@SQLI
© SQLI2021
2013 101
 BACKOFFICE
EXAMPLE WIDGET CONTROLLER: PRODUCT LIST

@SQLI
© SQLI2021
2013 102
W
or
kf
lo
w
 WORKFLOW
OVERVIEW

@SQLI
© SQLI2021
2013 104
 WORKFLOW
KEY CONCEPT

@SQLI
© SQLI2021
2013 105
 WORKFLOW

@SQLI
© SQLI2021
2013 106
 WORKFLOW
WORKFLOW EXTENSION

xample of workflow creation: https://wiki.hybris.com/pages/viewpage.action?pageId=294094210

@SQLI
© SQLI2021
2013 107
Ca
ch
e
 CACHE

Updating existing cache region:

@SQLI
© SQLI2021
2013 109
 CACHE

Adding new cache region:

@SQLI
© SQLI2021
2013 110
 CACHE

@SQLI
© SQLI2021
2013 111
 CACHE

@SQLI
© SQLI2021
2013 112
 CACHE

@SQLI
© SQLI2021
2013 113
 CACHE

@SQLI
© SQLI2021
2013 114