Integrazione Sistemi CRM (Joomla) & CRM (SugarCRM)

INTEGRAZIONE DI SISTEMI

Sessione introduttiva 31 Marzo 2010

1

METODI E APPROCCIO AL PROBLEMA

Progetto Formazione - RLS Autore/i Antonio Musarra [email protected] Blog: http://musarra.wordpress.com

Oggetto Integrazione di Sistemi D. Rilascio 31/03/2010

Revisione 1.1 – 06/04/2010

Antonio Musarra's Blog - Integrazione di Sistemi (Metodi e Approccio al Problema)

Introduzione

31 Marzo 2010 Antonio Musarra's Blog - Integrazione di Sistemi (Metodi e Approccio al Problema)

2

Il titolo dato alla presentazione è molto generico, il che implica la vastità dell’argomento, il sottotitolo cerca invece di mettere degli argini all’argomento trattato. Questa sessione di formazione introduttiva non vuole essere teorica ma alquanto pratica, con l’obiettivo finale di lasciare ai partecipanti uno “strumento” che consenta di portare a termine e nel migliore dei modi i problemi legati all’integrazione tra sistemi.

Lo strumento a cui si è fatto riferimento nel precedente paragrafo è possibile definirlo come l’insieme di: “Attrezzi” e metodi che facilitano l’approccio al problema.

Nel corso di questa sessione di formazione sarà affrontato un esempio pratico d’integrazione tra due tipologie di sistemi, cercando di mettere in risalto per quanto possibile i principali ruoli coinvolti in questo tipo di attività.

Introduzione

31 Marzo 2010

3

Il processo d’integrazione tra diversi tipi di sistemi informatici avviene attraverso l’utilizzo di software e soluzioni architetturali. In questa sessione di formazione, i sistemi informatici (a titolo d’esempio) da sottoporre al processo d’integrazione sono due e appartengono a due diverse tipologie: ¨  Content Management System – CMS ¨  Customer Relationship Management – CRM

Il CMS che prenderemo come riferimento è rappresentato dalla soluzione

software Open Source (scritto in PHP) Joomla, invece il CRM che prenderemo come riferimento è rappresentato dalla soluzione software Open Source (scritto in PHP) SugarCRM.

La soluzione architetturale da adottare in questo “semplice” processo d’integrazione sarà basata interamente sull’utilizzo dei Servizi Web (o Web Service), la scelta di questa soluzione è giustificata dal fatto che entrambi i sistemi sono Provider di Servizi Web.


L’oggetto dell’integrazione

31 Marzo 2010

4

Nella precedente slide abbiamo visto in breve quali saranno i sistemi coinvolti nel processo d’integrazione. A questo punto non resta che far luce sull’oggetto dell’integrazione. Credo che uno scenario possibile d’integrazione tra i due tipi di sistemi possa essere il seguente:

La società Acme Corporation che gestisce i propri clienti e relativi

processi attraverso un CRM, ha la necessità di far accedere i propri clienti a determinati contenuti pubblicati sul portale internet realizzato con il sistema di CMS.

Lo scenario d’integrazione mi sembra abbastanza chiaro, può

rendere ancora più chiare le idee lo schema illustrato nella slide successiva.


L’oggetto dell’integrazione: Il Cosa

31 Marzo 2010

5

Il risultato finale dell’integrazione, quindi, “il cosa” l’integrazione consentirà di fare, è illustrato in maniera semplice e sintetica nello schema sopra riportato. Il cliente registrato sul CRM di Acme potrà accedere per esempio ai documenti PDF dei contratti o degli ordini, accedere a un servizio di supporto al cliente che potrebbe avvenire tramite un sistema di Chat e tanto altro ancora.

Site Map

Form

Acrobat Document

Search Page Web Page

Portale ACME C.

Customer ACME C.

ChatAcrobat

DocumentChat


L’oggetto dell’integrazione: Il Come

31 Marzo 2010

6

Il Cosa (visto nella precedente slide) e Il Come sono due termini importanti nell’ingegneria del software, vivono in fasi diverse, il primo nella fase definita di Avvio e Analisi, il secondo nella fase definita di Progettazione e Implementazione.

In una delle precedenti slide d’introduzione è stato fatto accenno circa la soluzione architetturale da adottare, la scelta e ricaduta sull’utilizzo dei Servizi Web che rappresentano Il Come, in altre parole, come l’integrazione trai i due sistemi di CMS e CRM dovrà avvenire affinché si possa verificare Il Cosa.

Per fissare ancor meglio le idee, nella prossima slide è illustrato un semplice schema che mostra come i due sistemi saranno integrati.



31 Marzo 2010

7

E’ possibile affermare che i sistemi sono tre, anche il cliente può essere considerato come tale, dato che però non è parte attiva dell’integrazione può essere trascurato. E’ ormai assodato che i due sistemi (CMS & CRM) comunicheranno tra loro fruttando i Servizi Web, ma quali dovranno essere le responsabilità di ogni sistema che partecipa all’integrazione ?

Portale ACME C. (CMS)

Sistema Gestione Clienti (CRM)

Customer ACME C.

Comunicazione su protocollo HTTP Comunicazione via Servizi Web

(Web Service)



31 Marzo 2010

8

¨  Il sistema di CRM ha la responsabilità di fornire ai fini dell’integrazione una serie di Servizi Web che espongo le funzionalità richieste;

¨  Il sistema di CMS ha la responsabilità di agire come consumatore dei Servizi Web esposti dal sistema di CRM.

Portale ACME C. (CMS)

Sistema Gestione Clienti (CRM)

Customer ACME C.

Comunicazione su protocollo HTTP Comunicazione via Servizi Web

(Web Service)

Service Consumer Service Provider


Conoscere i sistemi da integrare

31 Marzo 2010

9

Quando si parla d’integrazione tra sistemi, esiste quella figura professionale (o azienda) che prende il nome di System Integrator cui compito è quello di far dialogare impianti diversi tra di loro allo scopo di creare una nuova struttura funzionale che soddisfi i requisiti richiesti (Il Cosa).

Considerando i sistemi come delle “scatole nere”, i System Integrator hanno la sola necessità di conoscere per ogni sistema da integrare le sole interfacce pubbliche e i metodi di accesso a quest’ultime.

Nel nostro scenario, dove i sistemi coinvolti sono:

¨  Joomla che implementa il sistema di CMS. La versione di riferimento è la 1.5; ¨  SugarCRM che implementa il sistema di CRM. La versione di riferimento è la 5.5. sappiamo che entrambi espongono parte o tutte le funzionalità attraverso le cosiddette interfacce pubbliche, quest’ultime implementate fruttando la tecnologia dei Servizi Web.



31 Marzo 2010

10

Sullo scenario descritto nelle precedenti slide, ipotizziamo di ricoprire il ruolo di System Integrator e Owner del sistema CMS (Joomla). In qualità di Owner del sistema CMS dobbiamo essere in grado di sviluppare il componente (potrebbero essere più di uno) software che soddisfi il requisito funzionale descritto precedentemente nelle slide 4 e 5.

Per quanto riguarda invece il sistema CRM (agiamo quindi come System Integrator), siamo tenuti a conoscere la sola interfaccia pubblica (realizzata attraverso i Servizi Web) di cui è disponibile ampia documentazione.

Vediamo in breve quali sono le azioni “di sviluppo” da compiere sui due sistemi: ¨  CRM: Nessuna azione di sviluppo da intraprendere; ¨  CMS: Sviluppo di un componente software che consenta di colloquiare con il sistema di CRM (attraverso i Servizi Web) affinché il cliente possa autenticarsi e accedere ai propri contenuti. Ricordiamo che le informazioni sul cliente sono di proprietà del CRM, quest’ultimo diviene quindi l’attore principale del processo di autenticazione.



31 Marzo 2010

11

Da questa slide in poi vedremo come sviluppare il componente richiesto sul sistema CMS. Il nostro sistema di CMS di cui noi siamo Owner è sviluppato interamente in PHP e adotta in pieno il paradigma OOP (Object Oriented Programming), tra l’altro fa largo uso di soluzioni progettuali tra le più comuni (vedi Design Pattern), consentendo in questo modo una certa facilità d’estensione, resa anche possibile grazie alla struttura a componenti di Joomla.

In linea generale, quando bisogna estendere sistemi di qualunque natura costruiti secondo “schemi standard” (tra cui rientra il nostro Joomla), potrebbe essere più che sufficiente per noi sviluppatori l’accesso alla documentazione fornita a corredo. E’ vero che la sola documentazione non basta, o meglio, il lettore deve possedere dei requisiti minimi che lo facilitano nella comprensione della documentazione stessa e del codice applicativo: ¨  Buona conoscenza di OOP; ¨  Buona conoscenza dei più comuni Design Pattern;

¨  Sufficiente conoscenza del linguaggio UML.



31 Marzo 2010

12

Le risorse disponibili su Joomla, che sono poi il primo punto di partenza per la conoscenza dello strumento, sono tutte concentrate sul portale dedicato: Joomla! Official Documentation. Vediamo quali sono le sezioni più d’interesse:

¨  Administrators ¨  Web designers ¨  Developers ¨  Joomla! Framework API Reference.

¤  API 1.5 ¤  API 1.6

Le risorse di nostro interesse che riguardano invece il sistema di CRM sono disponibili sul

portale di SugarCRM all’indirizzo: http://developers.sugarcrm.com/documentation.php?edition=OS.

Ai fini dell’integrazione è utile per noi la documentazione rivolta agli sviluppatori, in particolare la sezione dedicata ai Servizi Web disponibile all’indirizzo: http://developers.sugarcrm.com/docs/OS/5.5/-docs-Developer_Guides-Sugar_Developer_Guide_5.5-Chapter%202%20Application%20Framework.html#9000194


Lo sviluppo su Joomla

31 Marzo 2010

13

Ipotizzando di aver studiato la documentazione introduttiva su Joomla riguardo la sua struttura d’insieme e i possibili punti di estensione, è possibile affermare che il nostro obiettivo si traduce nello sviluppo di un Plugin Joomla di tipo Autenticazione. La funzionalità del nuovo Plugin contribuirà in massima parte alla risoluzione del requisito richiesto.

Per lo sviluppo di Plugin su Joomla è possibile far riferimento alla documentazione ufficiale disponibile ai seguenti indirizzi:

¨  Joomla Plugins

¨  How to create a Joomla! Plugin

Ricordo che i Plugin sono estensioni che si basano su un particolare design pattern, chiamato Observer. In pratica essi restano inattivi fino a che Joomla lancia un particolare evento. Ogni Plugin si registra per un determinato evento e quando esso avviene, il Plugin viene eseguito. Il nostro Plugin prenderà il nome di SugarCRMOverSOAP e dovrà assolvere i seguenti compiti:

¨  Sulla base delle credenziali fornite dall’utente del portale deve inviare il messaggio di login() verso il sistema di CRM;

¨  Deve richiedere la User ID al sistema CRM sulla base della sessione restituita in risposta al messaggio di login(). La richiesta avviene inviando il messaggio get_user_id() al sistema di CRM;

¨  Deve richiedere le informazioni di dettaglio sul cliente (Nome, Cognome, Email, etc…) sulla base della User ID inviando un messaggio get_entry() al sistema di CRM;

¨  Estrae le informazioni del cliente d’interesse per il CMS;

Nella precedente lista dei “requisiti” del Plugin ho indicato i soli segmenti del flusso degli eventi principale, non sono quindi presenti l’eccezioni. Nella successiva slide una digramma di sequenza dimostra la comunicazione tra i principali attori coinvolti nell’integrazione.



31 Marzo 2010

14

Sull’evento di Autenticazione (onAuthenticate) scatenato da Joomla viene istanziato il nostro Plugin.

Web Service API’s del sistema di CRM SugarCRM

Scambio dei messaggi tra il sistema Joomla (attraverso il Plugin) e il sistema di CRM SugarCRM. Lo scambio dei messaggi avviene tramite protocollo SOAP.

Qualora il cliente è al suo primo accesso al portale, sarà creato come utente del sistema di CMS, condizione necessaria imposta dal CMS stesso.



31 Marzo 2010

15

Il Plugin che andremo a sviluppare e che abbiamo deciso di chiamare con il nome di SugarCRMOverSOAP è tipo Authenticate e deve rispondere all’evento onAuthenticate, evento generato da Joomla quando è richiesto un processo di autenticazione, in altre parole, un utente del portale esegue una login attraverso l’opportuna form visualizzata sul portale. La costruzione del Plugin si traduce quindi in:

¨  Estensione della classe JPlugin e l’implementazione dell’evento

onAuthenticate così come indicato nel Class Diagram mostrato nella successiva slide;

¨  Creazione del Manifest file (in formato XML) che contiene descrizione e caratteristiche del Plugin. Il Manifest è richiesto per la fase d’installazione del Plugin;

¨  Creazione del Package d’installazione del Plugin.



31 Marzo 2010

16

class extension

JObserverJPlugin

+ JPlugin(subject :var*) : var+ update(args :var*) : var

plgAuthenticationSugarCRMOv erSoap

+ onAutenticate(response :JAuthenticateResponse, options :array, credentials :array) : boolean

Figura 1. Class Diagram del Plugin SugarCRMOverSOAP



31 Marzo 2010

17

<?xml version="1.0" encoding="utf-8"?>

<install version="1.5" type="plugin" group="authentication">

<name>SugarCRM SOAP Authentication</name>

<author>Antonio Musarra</author>

<creationDate>Marzo 2010</creationDate>

<copyright>Antonio Musarra ©. All rights reserved.</copyright>

<license>http://www.gnu.org/licenses/gpl-2.0.html GNU/GPL</license>

<authorEmail>[email protected]</authorEmail>

<authorUrl>musarra.wordpress.com</authorUrl>

<version>1.5</version>

<description>Autenticazione on SugarCRM (versione 5.5 CE) over SOAP</description>

<files>

<filename plugin="sugarcrmoversoap">sugarcrmoversoap.php</filename>

</files>

<params>

<param name="SoapEndPoint" type="text" size="255" default="http://crmcorporate.dev.dontesta.it/soap.php?wsdl" label="SOAP End Point" description="PARAMSOAPENDPOINT" />

<param name="CheckPortalEnabled" type="radio" default="0" label="Check Portal Enabled" description="PARAMCECKPORTALENABLED">

<option value="0">No</option>

<option value="1">Yes</option>

</param>

</params>

</install>

Informazioni generali sul Plugin. Il primo tag in particolare definisce il tipo di Plugin. Il resto dei tag sono autoesplicativi.

Elementi costitutivi del Plugin. In genere sono Classi e librerie a supporto. In questo caso il Plugin è costituito da una sola Classe PHP che implementa il Plugin.

Parametri di configurazione del Plugin. Un parametro utile per il nostro Plugin è l’Endpoint dei Servizi Web del sistema di CRM.



31 Marzo 2010

18

Analizziamo in breve l’implementazione dell’evento onAuthenticate per il Plugin SugarCRMOverSOAP.

Lettura dei parametri di configurazione del Plugin, particolare attenzione al parametro che definisce l’Endpoint del Servizio Web del sistema di CRM.

Creazione del Client SOAP e successiva chiamata dell’operazione login. L’operazione login accetta come parametro d’input una struttura dati contenente la coppia UserID/Password. Per maggiori informazioni sui parametri d’input e sul ritorno delle operazioni SOAP, fare riferimento alla documentazione dei Web Service API’s di SugarCRM.

La connessione ai servizi SOAP è garantita dalla modulo SOAP Client disponibile dalla versione 5.x di PHP. Tutte le info sul modulo sono disponibili sul sito http://it.php.net/soap



31 Marzo 2010

19

Verifica il buon fine della chiamata all’operazione login e salva l’informazione della session ID assegnata all’utente dal sistema di CRM.

Richiama l’operazione get_user_id sulla base della session ID e successivamente in caso di successo richiama l’operazione get_entry su base User ID, quest’ultimo valore è restituito dalla precedente chiamata.

A fronte del successo della precedente chiamata get_entry, dalla struttura dati restituita, vengono prelevate le informazioni sull’utente: Nome, Cognome e Email, valori assegnati all’oggetto response di tipo JAuthenticateResponse.



31 Marzo 2010

20

Le due figure mostrano due dei ComplexType utilizzati dall’operazione login: ¨  error_value: rappresenta eventuali errori restituiti dall’operazione (per esempio nel caso di username o

password errate);

¨  user_auth: rappresenta il parametro d’input contenente la coppia username/password. Nella slide successiva è illustrato il ComplexType get_entry_result restituito dall’operazione get_entry. Per

maggiori informazioni e dettagli consiglio di far riferimento alla documentazione ufficiale SugarCRM e al documento WSDL dei Servizi Web.



31 Marzo 2010

21

ComplexType che rappresenta gli attributi (field_list) della entry (esempio: Nome, Cognome, Email, etc…)

ComplexType che rappresenta i valori (entry_list) degli attributi della entry (esempio: Mario, Rossi, [email protected], etc…)



31 Marzo 2010

22

Lo sviluppo del Plugin SugarCRMOverSOAP è praticamente giunto al termine, a questo punto non resta che procedere con gli ultimi quattro task prima del test finale:

¨  Creazione del Package d’installazione (vedi doc

Joomla); ¨  Installazione del Plugin (vedi doc Joomla); ¨  Configurazione del Plugin (successive slide); ¨  Abilitazione & Configurazione del modulo Login (vedi

successive slide).


Configurazione del Plugin

31 Marzo 2010

23

Completata l’installazione del Plugin sul proprio ambiente di sviluppo o test di Joomla, l’operazione da eseguire è quella di configurazione. L’unico parametro (significativo) di configurazione è quello che riguarda l’endpoint del Servizio Web del sistema di CRM, parametro fornito dal gestore del sistema.

EndPoint delle Web Service API’s del sistema di CRM SugarCRM. In questo caso l’EndPoint del servizio punta al WSDL dell’installazione SugarCRM di collaudo.

Abilita o Disabilita il Plugin

Configurazione del livello di accesso al Plugin. Per ovvie ragioni l’accesso deve essere impostato a Public.


Abilitazione e configurazione del modulo Login

31 Marzo 2010

24


Conclusioni

31 Marzo 2010

25

Lascio questo spazio ai lettori e ai partecipanti di questo breve corso di formazione. Scrivete le vostre conclusioni finali, utili all’autore del corso come spunto di miglioramento.


Integrazione Sistemi CRM (Joomla) & CRM (SugarCRM)

Technology

Transcript of Integrazione Sistemi CRM (Joomla) & CRM (SugarCRM)