#LRIS2014 - MessageBus, Cluster communication and Caching on B2B

MessageBus, Cluster communication and caching on B2B

Mariuzzo MauroLiferay Architect, SMC Treviso srl

Liferay Symposium Italy, Rome 2014- 2 -

Requisito

Creare una soluzione B2B per consentire a Partner e Rivenditori di:● vedere il catalogo dei prodotti● effettuare ordini e vederne lo stato di

avanzamento● vedere i propri documenti fiscali (ordini,

fatture)


Prodotti coinvolti - ERP

Fonte aziendale autoritativa per:● Anagrafiche Cliente, Anagrafiche Prodotto, ...● Lavorazioni● Ordini● Fatture● Listini Particolari Cliente e metodi di calcolo del prezzo● Contratti e Promozioni● ....

ERP


Soluzione CRM open source realizzata in Java secondo un paradigma model-driven.

Gestisce le problematiche CRM, SFA, MA.

Implementa diversi meccanismi di integrazione: CalDAV, CardDAV, IMAP, LDAP, ...

Prodotti coinvolti - CRM

OpenCRX


Replica i dati ERP e li arricchisce per i contesti “non fiscali”:● Customer Satisfaction (Help-Desk, TTS, ....)● Sales Force Automation● Marketing Automation● ....

Prodotti coinvolti - CRM

OpenCRX


● Fornisce all'utente una User Interface semplificata che migliora la sua User eXperience– Rispetto a ERP e CRM

● Unico punto di accesso applicativo per gli utenti esterni● Moltiplicatore di accessi

– I CRM non sono pensati per centinaia di utenti contemporanei

● Arricchisce i contenuti per una fruizione “responsiva” e cross-browser

● ....

Prodotti coinvolti - Portale

Liferay-Portal


DMZ LAN

Soluzione - Architettura

Internet


Soluzione – Screenshots


DMZ LAN

Soluzione - Architettura

Internet


Problematiche – Integrazione Liferay-CRM

OpenCRX dispone di un ricco set di API REST per accedere alle informazioni ed alle funzionalità

La “soluzione B2B” è composta da diversi plugins (file .war separati)

Come evitare di duplicare il codice di integrazione?


Problematiche – Integrazione Liferay-CRM – plugin shared

Per i servizi SOAP posso generare una “client library” partendo dal wsdl.

Per i servizi REST me la devo costruire.

Con il Liferay Plugins SDK posso realizzare la “client library” come plugin “shared”:● un particolare tipo di plugin che produce “.jar”

invece di “.war”● pensato per codice senza stato (stateless)


Problematiche – Integrazione Liferay–CRM – plugin shared

Esempio: knowledge-base-portlet, knowledge-base-shared

Il file build.xml

<?xml version="1.0"?><!DOCTYPE project>

<project name="knowledge-base-shared" basedir="." default="deploy"><property name="plugin.version" value="1" />

<import file="../build-common-shared.xml" /></project>


Problematiche – Integrazione Liferay–CRM – plugin shared

Il file “build.xml” nel portlet che vuole usare lo shared

<?xml version="1.0"?><!DOCTYPE project>

<project name="knowledge-base-portlet" basedir="." default="deploy"><import file="../build-common-portlet.xml" />

<property name="import.shared" value="knowledge-base-shared" /></project>


Problematiche risolte

✔ Gestire il codice di integrazione con OpenCRX in una libreria riusabile da più plugins


Problematiche – Evitare sovraccarico CRM

Come evitare che tutti i plugin parlino direttamente con il CRM sovraccaricandolo?

Il plugin “shared” non mi aiuta.

Posso usare i service con il required-context!


Liferay Plugins SDK - Required context

● Anche un plugin può dichiarare dei servizi (file service.xml)

● Il servizio si basa su 3 elementi:– L'interfaccia (es: KBArticleService)– La classe di implementazione (es: KBArticleServiceImpl)– La classe singleton (es: KBArticleServiceUtil)

● Interfaccie e singleton finiscono in un file “xxxx-service.jar”

● L'implementazione è caricata in modalità “lazy” tramite Spring



● Un plugin può dichiarare che vuole usare i servizi usati da un altro plugin– Nel file “liferay-plugin-package.properties”– Proprietà “required-depoyment-contexts”

● A compile-time il file “xxxx-service.jar” viene copiato in “docroot/WEB-INF/lib” e finisce nel .war

● Nella fase di deploy il plugin non viene reso operativo in assenza del contesto richiesto

● Spring crea un tunnel tra i due plugin (i due contesti)● L'infrastruttura Liferay permette di trasferire oggetti

complessi senza ClassCastExcpetion

● I servizi sono dichiarati nel file “service.xml”● Possono gestire entità reali (tabelle a

database) <entity name="FavoriteSite" local-service="true" remote-service="false"> <column name="favoriteSiteId" type="long" primary="true" /> <column name="groupId" type="long" /> <column name="companyId" type="long" />

● Oppure entità “di servizio” <entity name="SocialOffice" local-service="false" remote-service="true">  <reference package-path="com.liferay.portal" entity="Group" /> </entity>



● Dichiaro delle entità di servizio per gli elementi CRM (es: CRMProductService*)

● Sfrutto il required-deployment-contexts per fornire i servizi agli altri plugins




✔ Concentrare l'accesso al CRM in un unico plugin



I metodi dei services devono ritornare i dati del CRM

Come evitare che Bean complessi mi sollevino una ClassCastException?



● I servizi devono ritornare oggetti semplici (int, long, String)– gli oggetti complessi sono JSON

● Ho bisogno di un ulteriore strato che:– Dichiari i POJO delle entità CRM (es: CRMProduct)– Si preoccupi di convertire gli oggetti JSON in POJO

(es: CRMProductUtil)





✔ Gestire gli elementi CRM come oggetti complessi


Problematica – Sovraccarico CRM

Come evitare di sovraccaricare il CRM con troppe richieste contemporanee?



Come evitare di sovraccaricare il CRM con troppe richieste contemporanee?

Creando qualcosa di simile ad un connection-pool.

Uso il MessageBus per creare delle code di elaborazione.


MessageBus

● E' un framework sviluppato da Liferay per gestire code di messaggi.

● E' stato realizzato per essere leggero e flessibile.

● Non si appoggia ad alcun framework esterno● Composto da tre elementi principali

– Il Messaggio– La Destinazione (dove viene recapitato il

messaggio)– Il Listener (l'attore che elabora il Messaggio)


MessageBus

Le Destinazioni sono● Asincrone: utilizzano più worker per elaborare i

messaggi– Seriale: dispacciano il Messaggio ad un Listener alla volta– Parallela: dispacciano il Messaggio su più Listener

contemporaneamente

● Sincrone: utilizzano un singolo worker

com....kernel.messaging.SerialDestination

com....kernel.messaging.ParallelDestination

com....kernel.messaging.SynchronousDestination


MessageBus

L'invio dei messaggi può essere:● Sincrono

– il processo sender rimane appeso in attesa di una risposta– finché non arriva o per un periodo di tempo certo (timeout)

● Asincrono– il processo sender continua– posso indicare un callback su cui ricevere la risposta– Posso “inviare e dimenticare”

MessageBusUtil.sendMessage(destination, payload)

MessageBusUtil.SendSyncronousMessage(destination, payload)



Il plugin “crm-integration-web”● Implementa il dialogo con il CRM● Tramite il ServiceBuilder gestisce le entità CRM come entità “di

servizio”– Sotto forma di oggetti JSON

● Dichiara delle MessageBus Destination per creare delle code di accesso ai servizi generati dal ServiceBuilder

Il plugin “crm-integration-shared”● Dichiara / Implementa i Bean delle entità CRM● Implementa le classi per interagire con il MessageBus

– Inviare i messaggi– Trasformare le risposte JSON (Payload) in POJO



Plugin ONE

crm-integration-shared

Plugin TWO

crm-integration-shared

crm-integration-web

Destination

Destination

Service

Destination

Listener

Listener

Listener

CRM


Caching strato servizi

Posso fare di più?

Cache!

Per le entità reali il ServiceBuilder genera la classe xxxPersistenceImpl che sfrutta la MultiVMPoolUtil per gestire la cache dei Model e dei Finder



Per le entità “di servizio” questa classe non c'è.

Ma la posso creare.

Devo creare sia l'interfaccia nella parte service

public interface CrmProductPersistence {

public int countByC_P_D_C_B_TT(

long userId, String customerId, String productNumber,

String description, String categoryId, String brandId,

CrmProductSearchTerms terms)

throws CrmComunicationException, CrmResponseException;



Ed ovviamente la sua implementazione

public class CrmProductPersistenceImpl extends CrmBasePersistenceImpl implements CrmProductPersistence {.... public List<String> findByDescription( long userId, String customerId, String productNumber, String description, String categoryId, String brandId, CrmProductSearchTerms terms, Locale locale, int start, int count) throws CrmComunicationException, CrmResponseException {

Object[] finderArgs = new Object[] { productNumber, description, categoryId, brandId, terms, start, count, locale};

@SuppressWarnings("unchecked") List<String> list = (List<String>)FinderCacheUtil.getResult( FINDER_PATH_FIND_BY_DESCRIPTION, finderArgs, null);

if (list == null) { ... list = crmItemsValuesFromResponse(productsResponse);

if ((list != null) && !list.isEmpty()) { FinderCacheUtil.putResult(FINDER_PATH_FIND_BY_DESCRIPTION, finderArgs, list); } }

return list; }



La configurazione della cache si trova in “portal-impl/src/ehcache”






✔ Ridurre sovraccarico CRM (code + cache)


Problematica - cluster

● E se ho una installazione Liferay in Cluster?● La cache di Liferay è di tipo “Invalidante”

– Se un dato non è presente in cache, oppure è scaduto o invalidato

● lo leggo e lo metto nella mia cache

– Se modifico un dato● Lo salvo sul DB● Lo aggiorno nella mia cache● Informo gli altri nodi di invalidarlo nella loro cache

– Se cancello un dato● Lo cancello dal DB● Lo invalido nalla mia cache● Informo gli altri nodi di invalidarlo nella loro cache



Possibilità UNO: dichiaro una specifica cache di replica nel MultiVMPoolUtil

<cache eternal="false" maxElementsInMemory="100000" name="it.smc.....CRMProduct" overflowToDisk="false" timeToIdleSeconds="600"> <cacheEventListenerFactory class="com....ehcache.LiferayCacheEventListenerFactory" properties="replicatePuts=false,replicateUpdatesViaCopy=false" propertySeparator="," /> <bootstrapCacheLoaderFactory class="com....ehcache.LiferayBootstrapCacheLoaderFactory" /></cache>

"replicatePuts=true,replicatePutsViaCopy=true,replicateUpdatesViaCopy=true"



Possibilità DUE: Uso la SingleVMPoolUtil e decido io come propagare la cache tra i nodi.

Per propagarla utilizzo il framework “ClusterExecutor”



com.liferay.portal.kernel.cluster.ClusterExecutorUtil

public List<ClusterNode> getClusterNodes(); public ClusterNode getLocalClusterNode() throws SystemException; public Address getLocalClusterNodeAddress(); public void initialize(); public boolean isClusterNodeAlive(Address address); public boolean isClusterNodeAlive(String clusterNodeId); public boolean isEnabled();

public FutureClusterResponses execute( ClusterRequest clusterRequest) throws SystemException;



Il metodo Execute mi permette di eseguire un metodo di una classe negli altri nodi● Identifico il metodo da chiamareMethodKey myMethodKey = new MethodKey( MethodClass.class, "methodName", FirstSerializableArguement.class ...);

● Creo l'handler del metodoMethodHandler myMethodHandler = new MethodHandler( myMethodKey, myFirstArguement....);

● Lo invoco– Metto true su skipLocal per saltare me stesso

ClusterRequest clusterRequest = ClusterRequest.createMulticastRequest( methodHandler, true);ClusterExecutorUtil.execute(clusterRequest);






✔ Ridurre sovraccarico CRM (code + cache)✔ Gestire installazione in Cluster


MessageBus, Cluster communication and caching on B2B

Mariuzzo MauroLiferay Architect, SMC Treviso srl

#LRIS2014 - MessageBus, Cluster communication and Caching on B2B

Technology

Transcript of #LRIS2014 - MessageBus, Cluster communication and Caching on B2B