"Hybris Commerce Suite" by Antonino Giannone

03
04
05
02
01
Workshop # TOp
Hybris Commerce Suite
Hybris Suite Commerce
Service Layer - Architectural Components
Platform Architecture
a cura di Antonino Giannone
System Types
HowTo create and prepare a new Extension

03
04
05
02
01
Workshop # TOp
HYBRISSUITECOMMERCE
Data Sheet
Hybris è una piattaforma tecnologica in grado di fornire supporto
a qualunque settore industriale le cui necessità di business siano
orientate al mondo del commercio elettronico, sia esso B2C o
B2B.
Essa diviene driver dei processi di digital transformation ed è
strumento abilitante ad un contesto di omnicanalità dei flussi di
business e della customer experience.
Grazie ad Hybris, diviene possibile far confluire in un’unica
piattaforma qualunque touchpoint, sia esso virtuale o fisico,
attraverso i quali la propria clientela effettua o meno degli
acquisti.
Ciò rende fruibile da parte del management informazioni riferite al
chi effettua acquisti, al cosa viene acquistato ed in quali modalità,
al dove e quando l’acquisto è avvenuto oppure se quest’ultimo
non è andato a buon fine, fornendo comunque informazioni
riferite al contenuto di ciò che alla fine non è stato più
acquistato(carrelli abbandonati).
0101

03
04
05
02
01
Workshop # TOp
HYBRISPLATFORMARCHITECTURE
Architecture by business perspective
I componenti Hybris, moduli ed estensioni, rappresentano bundles
di funzionalità base e fanno da perimetro per alcune necessità di
business. I componenti sono classificati secondo aree di
competenza:
● Content: si riferisce ad un repository centralizzato di dati
strutturati che riguardano testo, contenuti web, layout di
stampa etc
● Commerce: ne fanno parte tutti quei componenti che
permettono la definizione dei flussi di business e processi
indirizzati ad uno o più channel di fruizione dei servizi
erogati
● Channel: si riferisce al management di channel specifici di
visualizzazione ed interazione tra servizio erogato e
customer base o potenziale nuova clientela
● Hybris Commerce Suite: riguarda il set completo di
funzionalità messo a disposizione per tutte le aree appena
descritte
01
02
Content Commerce Channel Orders

Workshop # TOp
03
04
05
0202
01
02
Content
Commerce Channel Orders
Product Cockpit - PCM
E’ lo strumento adoperato
per il content
management dei prodotti
e categorie dei propri
Catalogs.
Architecture by business perspective - Content

Workshop # TOp
03
04
05
0202
01
Architecture by business perspective -
02
Commerce
content Channel Orders
Hybris Management Console - hMC
E’ la plancia di admin della suite, dove
avviene il management degli oggetti di
business: prodotti, customer data,
ordini, promozioni e vaucher, analisi
dei carts e molto altro ancora
Commerce

03
04
05
0202
01
Workshop # TOp
02
Channel
Sono i canali di business e flussi di
informazione che costituiscono, in
termini di sistema informativo, i
meccanismi di comunicazione e
retroazione della propria attività di
business con l’environment circostante
Dei Channel, a vario titolo, fanno parte:
● WCMS
● Customer Service Cockpit
● Websites e mobile
Channel content Commerce Orders
Channel

03
04
05
0202
01
Workshop # TOp
02
Order Management Service - OMS
Permette la view e management degli ordini, review e modifica di
alcune informazioni di shipping, la gestione dei return and refund,
ricerca e view delle informazioni di inventory.
● Management in tempo reale degli inventory attraverso i
vari stock
● Sourcing: determinazione della locazione fisica che si
occuperà degli oggetti da spedire
● Workflow automatizzato degli ordini
● Splitting degli ordini
● Pick, pack, label e confirm shipment attraverso Order
fulfillment Cockpit
● Management return and refund
● View dei report di frode, dettaglio pagamenti e customer
Orders content Commerce Channel
Orders

Workshop # TOp
03
04
05
0202
01
02
Content
Commerc
e
Channel Orders

03
04
05
0202
01
Workshop # TOp
02
Content Commerce Channel Orders

03
04
05
02
01
Workshop # TOp
HYBRISPLATFORMARCHITECTURE
Architecture by technical perspective
Possiamo considerare la seguente layered architecture:
● Presentation layer
○ Cockpits, hmc, storefront-foundation,
other-frontends
● Functionality layer
○ hybris PIM, hybris Commerce, hybris Print, other
modules
● Platform layer
○ Persistence, Caching, Security, Transactions,
Clustering, Internationalization, Import/Export,
Search, Cron Jobs etc
01
02
Cockpits hmc storefront-foundation other
hPIM hCommerce hPrint other
Persistence Caching ….. Cron Jobs

03
04
05
02
01
Workshop # TOp
SERVICELAYER
ARCHITECTURALCOMPONENTS
01
03
Service Layer
E’ di fatto lo strato di API di sviluppo della hybris Commerce Suite.
Le caratteristiche principali sono le seguenti:
● separazione chiara tra business logic e persistence logic
● services component con responsabilità di azione e
connotati ben definiti
● fruizione di un framework necessario alla realizzazione dei
propri componenti di service o estensione di quelli
esistenti, di fatto l’implementazione della propria business
logic
● Spring framework come base tecnologica
● adozione dei pattern più comuni, tra cui l’approccio al
design del codice in termini di interface-driven e la
dependency-injection
● fruizione di meccanismi di hook per l’innesto di custom
logic a livello di model life-cycle, system event life-cycle
come per i processi di init ed update del sistema
● fruizione di un framework per la intercomunicazione tra
componenti basata su eventi

03
04
05
02
01
Workshop # TOp
01
03
Service Layer - Architectural components - Part I
● Client: qualunque componente che adoperi il service
layer(WS, Scripts, Controller, Pages)
● Service: componente che detiene la logica per l’esecuzione
dei processi di business che possiamo distinguere in:
○ Business services
■ Implementazione dei business Use-Case: cart
handling, back-order, price calculation ect
○ Infrastructure services
■ Caching, Security, Transaction, Session
○ System services
■ Model handling e session
SERVICELAYER
ARCHITECTURALCOMPONENTS

03
04
05
0202
01
Workshop # TOp
03
SERVICELAYER
ARCHITECTURAL
COMPONENTS
Service Layer - Architectural components - Part II
● Strategies: è un pattern di tipo comportamentale che permette
di modificare a runtime il comportamento di un componente in
uno o più punti.
I componenti di service posso delegare alcuni dei propri task
ad altri componenti, appunto le strategy. Ciò permette un
migliore incapsulamento del codice ed una maggiore
possibilità di rimpiazzare o adattare alcuni dei task eseguiti dal
componente di service, modificando quindi alcuni dei suoi
comportamenti

03
04
05
0202
01
Workshop # TOp
03
Service Layer - Architectural components - Part II
● DAO: è l’interfaccia di storage attraverso cui vengono
effettuate le CRUD. Il DAO di fatto interagisce con i service
attraverso i Model e con il DB attraverso FlexibleSearch e
statement SQL
● Model: il il modo in cui sono rappresentati gli Item di Hybris
e sono generati dal Type-System della piattaforma. Essi
sono adoperati dai seguenti componenti: DAO, Services,
Strategy, Facade e Converter
SERVICELAYER
ARCHITECTURAL
COMPONENTS

03
04
05
02
01
Workshop # TOp
01
04
Type System
Hybris organizza e descrive relazioni tra oggetti attraverso il
proprio sistema di tipi.
● Un type rappresenta un template di oggetto che ne
descrive le seguenti informazioni: attributi, destinazione di
deployment, classe java dell’oggetto
● Distinguiamo tra:
○ System types:
■ Infrastructure types: Item Type, che contiene
il setup di definizione del “tipo” e da cui
discende ogni componente hybris
■ Data Types: adoperati per descrivere attributi
e relazioni tra oggetti( collezioni, mappe,
enumerazioni, dati atomici )
○ Business types:
■ Oggetti con significato di business come i
Product, Order, Price, Discount ect
TYPESYSTEM

03
04
05
0202
01
Workshop # TOp
Hybris Commerce Suite Type System - Snippets
TYPESYSTEM
04

03
04
05
02
01
Workshop # TOp
01
05
Cosa è una Hybris Extension
Hybris fornisce a livello architetturale un sistema modulare e
flessibile che permette l’introduzione di nuove funzionalità
attraverso, appunto, la definizione di una nuova estensione.
Una estensione incapsula “un pezzo” dello Hybris Commerce Suite
in termini di business logic( service layer ), definizione di tipi( type
definition system - data model ), componenti di admin console(
hMC configuration ) e componenti MVC per la definizione di una
web application.
La realizzazione di una estensione Hybris permette, entro certi
limiti di best practice e dipendenze da altri moduli, la migrazione
dell’estensione stessa da un sistema hybris ad un altro
HOWTOCREATEANDPREPARE
ANEWEXTENSION
MVC components hmc
ServicesFacade
PersistenceModelDAO

03
04
05
0202
01
Workshop # TOp
05
Come si crea una Hybris Extension
Hybris fornisce alcuni tool da CLI, in questo caso quello riferito alla
creazione di una nuova estensione a partire da uno dei template di
scaffolding disponibili.
Attraverso il task ant “extgen” è possibile avviare lo scaffolding di
una estensione adoperando ad esempio il template “yempty”.
Il template “yempty” fornisce una estensione minimale corredata
dei seguenti moduli: core, hmc, web
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Aggiungiamo il nostro DataModel - Part I
Ogni estensione Hybris porta con sé la definizione del proprio
DataModel e questo ultimo risiede all’interno di un xml file con la
seguente naming convention: <extname>-items.xml
Il sistema di building di Hybris analizza tutti i file “*-items.xml” e
da essi deriva e genera diverse Java Class per ogni ItemType. Le
classi generate dal sistema di build sono le seguenti:
● Model class adoperata dai componenti di services
● DTO e Resources adoperate dal module WebServices, se
risulta abilitato
● Entity di persistenza di basso livello Jalo Class
ANEWEXTENSION
Una volta definito il proprio
DataModel ed eventuali
Relations, basta rieseguire la
fase di build e start del server.
In hMC sarà adesso disponibile
il nuovo elenco di Types

03
04
05
0202
01
Workshop # TOp
05
Aggiungiamo il nostro DataModel - Part II
Di ogni Types, per ogni estensione, è possibile definire
l’internazionalizzazione. Per fare ciò Hybris fornisce tra i propri
tools quello di export, sia dei types che delle rispettive localization.
I file esportati di fatto divengono file di properties java da
includere nel proprio progetto
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Aggiungiamo il nostro DataModel - Part III (Impex Extension)
Potrebbe essere utile avere un sistema che mi permetta l’import ed
export di dati e poter creare così anche dei sample data.
Esiste e va sotto la denominazione di “Impex Extension”.
Attraverso questa estensione è possibile importare ed esportare data
types hybris. Ciò permette la definizione di due principali categorie di
file: “essential data” e “project data”. Questi ultimi trovano il proprio
posto all’interno di “ <extname>/resources/impex”
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Data Access Object Pattern - DAO
E’ il pattern adoperato per la definizione delle CRUD di base su di uno
specifico DataModel. Possiamo definire l’interfaccia adoperata poi dalla
classe concreta per recuperare, ad esempio, attraverso l’injection del
FlexibleSearchService, tutti i DigitalProduct che risultino ancora
“available” per il download.
ANEWEXTENSION
Adopereremo la seguente classe
all’interno delle classi di services che
hanno necessità di comunicare con il
DataModel DigitalProduct

03
04
05
0202
01
Workshop # TOp
05
Service Component
Qui troveremo l’injection dei vari componenti di cui necessita la nostra
logica di business. In questo caso, nello specifico troveremo sicuramente
il dao per interagire con il DataModel di nostro interesse. Della nostra
classe di service definiremo anche il bean spring tramite
xml-configuration
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Facade Component and Friends - Part I
Questo tipo di componente costituisce una interfaccia unificata e
semplificata i cui metodi concorrono in modo diretto
all’implementazione dei processi che compongono i vari Use-Case di
business.
Esso permette la comunicazione con uno o più Sub-System di cui
vengono nascoste complessità e dettagli implementativi, oltre ad avere il
compito di aggregare informazioni effettuando le dovute conversioni dei
vari Data Model in Data Transfer Object(DTO) e viceversa.
In Hybris, definiamo per prima cosa i DTO e quindi i presentation data a
livello di Use-Case come spring beans. Tale definizione verrà adoperata
da hybris per generare le classi necessarie e che saranno a disposizione
del sistema nel path: /platform/bootstrap/gensrc,
/platform/bootstrap/modelclasses
La definizione dei bean che riguardano DTO ed enum sono sempre
all’interno del file spring: <extension-name>-beans.xml
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Facade Component and Friends - Part I (snippet code)
Di seguito ciò che accade in termini di codice nel definire i DTO necessari
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Facade Component and Friends - Part II
Se esiste un DTO è probabile che nei dintorni ci sia anche un Converter
che porta con sé la business logic per la conversione che ha come source
un DataModel e come target, appunto, il nostro DTO
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Facade Component and Friends - Part II
Finalmente il nostro componente di Facade
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Cron Jobs
E’ adoperato per eseguire attività in modo periodico secondo regole di
cron. Un cron job è costituito da tre componenti:
● Job: detiene la logica da eseguire ed associata ad un
Job-Performable
● Crono Job: detiene le info di configurazione di una singola
esecuzione del Job
● Trigger: è adoperato per schedulare l’esecuzione del Job
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Events, Interceptor e DataModel Life Cycle - Part I
Events
Hybris aggiunge ulteriore intelligenza al sistema di event fornito da
Spring e fornisce tale enhancement come caratteristica intrinseca del
ServiceLayer.
E’ così possibile pubblicare event e creare listener in ascolto di questi
ultimi, fornendo così un meccanismo di comunicazione asincrona
all’interno dell’environment tra i componenti che ne fanno parte.
Accede, ad esempio, che un “Hybris Item” pubblichi un evento che
informa il sistema sul fatto che alcuni dei suoi attributi hanno subito
modifiche oppure il sistema stesso notifica la creazione di una nuova
sessione oppure che un ordine è andato in submit.
Tutto ciò può avvenire in locale sul singolo nodo oppure in termini di
propagazione sul cluster verso specifici nodi o in broadcast.
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Events, Interceptor e DataModel Life Cycle - Part II
Events
Il meccanismo ad event non è magia, esiste un componente di service
“EventService” e “DefaultEventService” attraverso cui è possibile
registrare e pubblicare eventi.
Un event è una estensione di “AbstractEvent” ed implementa
“ClusterAwareEvent” per la propagazione tra nodi specifici oppure in
broadcast.
La creazione e registrazione di un event listener è posta in essere
estendendo la classe “AbstractEventLister” e definendo quest’ultimo
come bean Spring, mentre sul metodo “onEvent” risiede la logica da
eseguire.
ANEWEXTENSION

03
04
05
0202
01
Workshop # TOp
05
Events, Interceptor e DataModel Life Cycle - Part III
Interceptor
La famiglia degli interceptor, legati al ciclo di vita di un model, è la
seguente:
● Init Default Interceptor: invocato quando il DataModel viene
compilato con i propri valori di default definiti in “items.xml”
● Load Interceptor: invocato subito dopo il caricamento del model
da db
● Prepare Interceptor: invocato poco prima del save su db
● Validate Interceptor: invocato subito dopo il Prepare e poco
prima del save su db
● Remove Interceptor: invocato poco prima del remove di un
model da db
ANEWEXTENSION

03
04
05
02
01
Workshop # TOp
GRAZIE

"Hybris Commerce Suite" by Antonino Giannone

Recommended

Recommended

More Related Content

Similar to "Hybris Commerce Suite" by Antonino Giannone

Similar to "Hybris Commerce Suite" by Antonino Giannone (20)

More from ThinkOpen

More from ThinkOpen (20)

"Hybris Commerce Suite" by Antonino Giannone