Liferay AUI Auto Complete Ajax Example

Alloy UI AutoComplete Ajax Example


1. Cos’è AlloyUI?

AlloyUI (abbreviato in AUI) è un meta framework Open Source realizzato da Liferay che ingloba una serie di librerie javascript fornendo un set di API per la creazione di applicazioni web robuste e flessibili che toccano i tre livelli del browser:  struttura, stile e comportamento. AUI è costruito su Yahoo User Interface (YUI) e ha il supporto per una vasta gamma di funzioni avanzate studiate appositamente per la tecnologia delle portlet.

2. Obiettivo

Le applicazioni web “moderne” sono sempre più vicine alle comuni applicazioni desktop, framework sempre più completi, complessi e di semplice utilizzo, rendono l’implementazione relativamente semplice, inoltre con l’avvento di HTML 5 la distanza con le applicazioni desktop diventa ancora più breve. In quest’articolo vedremo come sia semplice realizzare una combo completa di funzione auto complete, i cui dati presentati non sono “statici”, bensì, provenienti da una base dati. Sfrutteremo Ajax per il reperimento dei dati da mostrare all’interno della combo. Ovviamente realizzeremo il tutto all’interno di una portlet. In Figura 1 è illustrato il risultato finale del lavoro. Quanto realizzato nel corso dell’articolo è disponibile come progetto Maven Liferay Portlet sul mio repository GitHub all’indirizzo liferay-aui-autocomplete-ajax-example

Alloy UI Autocomplete Ajax Example

Figura 1. Alloy UI Autocomplete Ajax Example

3. Requisiti

Per seguire con profitto il corso dell’articolo, è richiesta una conoscenza minima degli standard e tecnologie che ruotano nell’intorno delle Portlet, oltre che un minimo di dimestichezza con Liferay e il suo ambiente di sviluppo. Gli strumenti a supporto dovrebbero essere i seguenti:

  1. Liferay SDK 6.1
  2. Eclipse + Liferay Plugin o Liferay Studio
  3. Liferay Portal 6.1

L’esempio completo della portlet che troverete sul repository GitHub, è stato realizzato tramite Maven e l’archetype liferay-portlet-archetype versione 6.1.1 Community Edition.

 4. Serving resources

Nella prima versione delle specifiche Java Portlet Specification 1.0 (JSR 168), non era possibile servire risorse generate dinamicamente direttamente dalla portlet, era necessario un ulteriore servlet che serviva le risorse. Questa limitazione ha alcuni svantaggi:

  • Non è disponibile il contesto della portlet, il che significa non avere accesso a render parameters, portlet mode, window state, portlet preferences, portlet session e altro ancora;
  • Le URL generate nella servlet sono al di fuori dello scope del portale, inoltre, lo stato corrente delle pagine del portale viene perso;
  • La servlet non è eseguita nel contesto di sicurezza del portale;

Un vantaggio di servire risorse attraverso una servlet è il meno overhead, dovuto al fatto che la richiesta non deve passare attraverso l’intera struttura del portale, per esempio, quando è necessario servire grandi flussi multimediali.

La seconda versione delle specifiche Java Portlet Specification 2.0 (JSR 286) introduce un nuovo tipo di URL, la resource URL. La resource URL consente di attivare il metodo serveResource, sull’interfaccia ResourceServingPortlet che è possibile sfruttare per creare risorse dinamiche direttamente nel portlet.

package javax.portlet;

/**
 * The <code>ResourceServingPortlet</code> interface allows
 * serving resources through the portlet.
 *
 * The portlet container must call this method for links created by
 * the <code>RenderResponse.createResourceURL()</code> call.
 * If the portlet creates resource URLs with <code>RenderResponse.createResourceURL()</code>
 * it must implement this lifecycle method.
 *
 * @since 2.0
 */
public interface ResourceServingPortlet {

    /**
     * Called by the portlet container to allow the portlet to generate
     * the resource content based on its current state.
     * The portal / portlet container must not render any output in addition
     * to the content returned by the portlet. The portal / portlet container
     * should expect that the portlet may return binary content for a
     * <code>renderResource</code> call.
     *
     * @param   request
     *          the resource request
     * @param   response
     *          the resource response
     *
     * @exception   PortletException
     *              if the portlet has problems fulfilling the
     *              rendering request
     * @exception  UnavailableException
     *                   if the portlet is unavailable to perform render at this time
     * @exception  PortletSecurityException
     *                   if the portlet cannot fullfill this request because of security reasons
     * @exception  java.io.IOException
     *              if the streaming causes an I/O problem
     */

    public void serveResource(ResourceRequest request, ResourceResponse response)
        throws PortletException, java.io.IOException;
}

Noi sfrutteremo questo nuova caratteristica per fornire alla view i dati da mostrare all’interno della combo.

5. Implementazione del serverResource

Partendo dal presupposto che abbiate creato una portlet MVC, vediamo come implementare il metodo serverResource(). Prima di procedere con il come, affrontiamo il cosa, ovvero, che tipo di risorsa e quali dati il metodo deve restituire alla view?. Ipotizziamo che i dati da voler mostrare sulla combo siano l’insieme di ruoli definiti su Liferay e il formato dei dati da restituire deve essere in formato JSON; detto questo, in breve occorre:

  1. Definire una Dynamic Query sull’entità Role;
  2. La Dynamic Query deve esplicitare una where conditions di tipo like sull’attributo name dell’entità Role;
  3. Utilizzare il Local Service Util per recuperare i dati dei ruoli applicando il filtro attraverso la Dynamic Query definita in precedenza;
  4. Preparare l’oggetto JSON contenente i ruoli estratti in precedenza;
  5. Inviare alla view i dati.

La Dynamic Query consente di recuperare la lista dei ruoli il cui nome fa “scopa” con quanto digitato dall’utente all’interno della combo, per esempio, se l’utente digitasse Site* allora sarebbe recuperata la lista di ruoli dove ogni item ha l’attributo name che inizia con Site. Cercando di rispettare l’ordine delle cose da fare (visto in precedenza), cercherò di mostrare brevemente i pezzi di codice del come.

JSONObject json = JSONFactoryUtil.createJSONObject();
JSONArray results = JSONFactoryUtil.createJSONArray();
json.put("response", results);
Source 1 – Inizializzazione oggetti JSON.

Il codice illustrato sopra è una semplice inizializzazione degli oggetti JSON (Object e Array) utilizzati in seguito come contenitori di dati. Invece, a seguire, al Source 2 è mostrata la definizione e creazione della Dynamic Query secondo le regole descritte in precedenza.

DynamicQuery dynamicQuery = DynamicQueryFactoryUtil.forClass(Role.class).
			add(PropertyFactoryUtil.forName("name").like(searchPattern));
Source 2 – Definzione e creazione della Dynamic Query.

Al Source 3, sono invece mostrati il recupero della lista di ruoli e la successiva preparazione dei dati appena restituiti dal Role Local Service  in formato JSON.

List roles = RoleLocalServiceUtil.dynamicQuery(dynamicQuery);
for (Role role : roles) {
	JSONObject listEntry = JSONFactoryUtil.createJSONObject();
	listEntry.put("key", role.getRoleId());
	listEntry.put("name", role.getName());
	listEntry.put("description", role.getDescription());
	listEntry.put("type", role.getType());
	results.put(listEntry);
}
Source 3 – Recupero lista dei ruoli e preparazione dati in JSON.
resourceResponse.setContentType(ContentTypes.APPLICATION_JSON);
PrintWriter writer = resourceResponse.getWriter();
writer.println(json.toString());
Source 4.a – Invio dei dati in formato JSON alla view.

Le ultime righe di codice del Source 4.a inviano la lista di ruoli che soddisfano la ricerca verso la view in formato JSON. La prima riga informa il client che riceve i dati circa il formato degli stessi. Al Source 5 è possibile vedere un esempio di dati inviati alla view. L’esempio completo della classe ViewAUIAutocompleteAjax che implementa l’MVCPortlet è disponibile all’indirizzo ViewAUIAutocompleteAjax.java. In realtà è possibile approfittare del metodo writeJSON() della classe com.liferay.portal.kernel.portlet.LiferayPortlet per ottenere lo stesso risultato del codice precedente (vedi Source 4.b).

writeJSON(resourceRequest, resourceResponse, json);
Source 4.b – Invio dei dati in formato JSON alla view.
{
"response": [
{
"description": "<!--?xml version='1.0' encoding='UTF-8'?-->Site Administrators are super users of their site but cannot make other users into Site Administrators.",
"name": "Site Administrator",
"type": 2,
"key": 10153
},
{
"description": "<!--?xml version='1.0' encoding='UTF-8'?-->All users who belong to a site have this role within that site.",
"name": "Site Member",
"type": 2,
"key": 10154
},
{
"description": "<!--?xml version='1.0' encoding='UTF-8'?-->Site Owners are super users of their site and can assign site roles to users.",
"name": "Site Owner",
"type": 2,
"key": 10155
}
]
}
Source 5 – Dati in formato JSON.

6. Implementazione della view

La view (che dovrebbe poi essere la jsp view.jsp) fondamentalmente si compone di uno script AUI che utilizza i seguenti componenti:

  1. AUI AutoComplete (Alloy UI Modules)
  2. DataSource.IO (YUI Modules)

Il primo elemento è responsabile della visualizzazione e selezione dell’insieme di dati resi disponibili dal secondo componente di datasource, quest’ultimo è invece responsabile del recupero dei dati inviando la richiesta alla resourceURL della portlet. Al Source 6, è mostrato lo script AUI che crea la combo vista precedentemente in Figura 1.


var dataSource = new A.DataSource.IO(
    {
        source: '<%=ajaxResourceURL %>'
    }
);

var autocomplete = new A.AutoComplete(
    {
        dataSource: dataSource,
        delimChar: '',
        contentBox: '#myAutoComplete',
        matchKey: 'name',
        schema: {
            resultListLocator: 'response',
            resultFields: ['key','name','description', 'type']
        },
        uniqueName:'keyword',
        schemaType:'json',
        typeAhead: true,
        cssClass: 'ac_input'
    });

autocomplete.generateRequest = function(query) {
    return {
        request: '&<%=DisplayTerms.KEYWORDS %>=' + query
    };
}

autocomplete.render();
Source 6 – AUI Script per l’AutoComplete Ajax.

Nel codice sorgente mostrato al Source 6, ho voluto evidenziare le righe che ritengo più rilevanti:

  1. L’attributo source del componente DataSource impostato al valore della resourceURL della portlet (vedi Source 7);
  2. L’attributo schema del componente di AutoComplete che informa lo stesso circa lo schema della struttura dati JSON restituita;
  3. Il metodo generateRequest() genera un oggetto che sarà poi passato al metodo sendRequest() del DataSource. In breve, alla resourceURL sarà “appeso” il valore digitato nella combo.
<portlet:resourceURL var="ajaxResourceURL">
	<portlet:param name="<%=Constants.CMD %>" value="<%=ActionKeys.GET_LIFERAY_ROLES %>"/>
</portlet:resourceURL>
Source 7 – Creazione resourceURL della portlet.

Ovviamente è possibile sfruttare il metodo serverResource() per eseguire diverse azioni distinte per la stessa portlet, per questo motivo sulla resourceURL creata (vedi Source 7), è stato impostato un parametro che esplicita l’azione da eseguire. L’esempio completo della view è disponibile all’indirizzo view.jsp

7. Conclusioni

Ancora una volta abbiamo visto come il riutilizzo dei componenti software e il progredire delle tecnologie favoriscono la creazione di qualunque manufatto soprattutto in termini di tempo, quest’ultimo prezioso visto il diminuire del Time to Market. Il progetto AUI è un percorso quasi obbligato per tutti coloro che intraprendono la strada di Liferay e in particolare modo per coloro che sviluppano o avranno intenzione di sviluppare applicazioni che richiedono un livello spinto d’interazione uomo-macchina. Purtroppo la documentazione a corredo del progetto è molto povera e gli esempi presentati non soddisfano mai gli usi reali.

Annunci
Figura 7 - Vista completa del progetto Hook Mavenizzato

Creare progetti Liferay tramite il plugin m2eclipse (Maven for Eclipse)


Il vostro processo di sviluppo software richiede l’utilizzo di Maven per la gestione del vostro progetto Java? Bene, in questo articolo vedremo come sia possibile creare ogni tipo di progetto (o plugin) Liferay utilizzando Maven, il tutto senza scrivere una riga di comando del tipo mvn archetype:generate. La versione di Liferay cui faremo riferimento è la 6.1 GA1 Community Edition.  I requisiti minimi in termini di software per ottenere il risultato atteso, sono i seguenti:

Supposto che il vostro ambiente di sviluppo sia correttamente installato e configurato e abbiate una buona conoscenza di Eclipse e dello strumento Maven, direi di andare avanti nella trattazione. Nel caso siate completamente a “secco” di Maven, consiglio la lettura di una serie di articoli pubblicati su MokaByte e di cui il primo della serie è Maven: best practices per il processo di build e di rilascio dei progetti in Java

1. Liferay Maven Artifacts

Liferay ha aggiunto il supporto a Maven come ottima alternativa al tool Ant plugin SDK. Gli artefatti sono stati pubblicati sul Central Repository tramite http://oss.sonatype.org, di nostro particolare interesse sono i Maven plugin e gli archetypes per tutti i tipi di plugins Liferay:

  • GroupId: com.liferay.maven.archetypes
  • ArtifactId:
    • liferay-ext-archetype
    • liferay-hook-archetype
    • liferay-layouttpl-archetype
    • liferay-portlet-archetype
    • liferay-servicebuilder-archetype
    • liferay-theme-archetype
    • liferay-web-archetype 

Ogni archetype può essere utilizzato per realizzare la base di ogni plugin Liferay mostrato nel precedente elenco, come per esempio un plugin di tipo Hook che poi andremo effettivamente a creare. L’indirizzo del central repository per il GroupId com.liferay.maven.archetype è:

2. Creazione di un Hook Plugin

La creazione di un Hook Plugin tramite il plugin m2eclipse è davvero un gioco da ragazzi. Gli step da eseguire da Eclipse sono appena quattro che riporto a seguire:

  • Creazione di un nuovo progetto Maven
  • Aggiungere l’archetype liferay-hook-archetype inserendo le seguenti informazioni:
    • Archetype GroupId
    • Archetype ArtifactId
    • Archetype Version
    • Repository URL
  • Selezionare l’archetype aggiunto in precedenza
  • Introdurre le informazioni del progetto Maven per l’Hook
    • GroupId (per esempio: it.dontesta.liferay.hook.sugarcrm)
    • ArtifactId (per esempio: liferay-hook-sugarcrm)
    • Version (per esempio: 0.0.1-SNAPSHOT)
    • Package (per esempio: it.dontesta.liferay.hook.sugarcrm)

Le figure possono essere sempre d’aiuto, quelle a seguire mostrano alcuni degli step di creazione del progetto Maven.

Figura 1 - Creazione nuovo progetto Maven

Figura 1 – Creazione nuovo progetto Maven

Figura 2 - Impostazioni predefinite del progetto

Figura 2 – Impostazioni predefinite del progetto

Lasciare le impostazioni predefinite. In particolare, la non selezione della prima opzione consentirà successivamente l’aggiunta e la selezione dell’archetype liferay-hook-archetype per creare il nostro plugin di tipo Hook.

Figura 3 - Aggiunta dell'Archetype

Figura 3 – Aggiunta dell’Archetype

Figura 4 - Aggiunta dell'Archetype

Figura 4 – Aggiunta dell’Archetype

Aggiunta dell’archetype inserendo i dati specificati in precedenza ricordando d’inserire l’indirizzo del repository.

Figura 5 - Impostazione proprietà del progetto

Figura 5 – Impostazione proprietà del progetto

 

Per il progetto appena creato, in pieno stile Maven, saranno risolte tutte le dipendenze necessarie. L’unica operazione che richiede un minimo di manualità è l’inserimento di una serie di proprietà sul POM che riguardano la propria installazione di Liferay. Il Listato 1 mostra quali sono le proprietà aggiunte sul POM. I valori delle proprietà indicate al Listato 1 sono riferite alla mia installazione di Liferay 6.1.1 CE.

<properties>
<liferay.version>6.1.1</liferay.version>
<liferay.auto.deploy.dir>
  /opt/liferay-portal-6.1.1-ce-ga2/deploy
</liferay.auto.deploy.dir>
<liferay.app.server.portal.dir>
  /opt/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT
</liferay.app.server.portal.dir>
<liferay.app.server.lib.global.dir>
  /opt/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/lib/ext
</liferay.app.server.lib.global.dir>
<app.server.deploy.dir>
  /opt/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps
</app.server.deploy.dir>
</properties>

Listato 1 – Proprietà installazione Liferay aggiunte sul POM (link al file completo).

Figura 6 - POM con evidenza delle proprietà di Liferay

Figura 6 – POM con evidenza delle proprietà di Liferay

Figura 7 - Vista completa del progetto Hook Mavenizzato

Figura 7 – Vista completa del progetto Hook Mavenizzato

 3. Package & Deploy

Una volta creato l’Hook di esempio, non resta altro che creare il package (che in questo caso è un war) da installare in seguito sulla propria installazione di Liferay. Quest’ultima operazione può essere anche eseguita tramite un apposito Maven Goal. La creazione del package liferay-hook-sugarcrm-0.0.1-SNAPSHOT.war e l’eventuale deploy su Liferay, può essere eseguito tramite il menù Run Configurations -> Maven Build specificando rispettivamente i goals package liferay:deploy, così come indicato in Figura 8.

Figura 8 - Configurazione Maven Run

Figura 8 – Configurazione Maven Run

Figura 9 - Esecuzione del Goal liferay:deploy

Figura 9 – Esecuzione del Goal liferay:deploy

4. Conclusioni

Abbiamo visto come sia semplice e immediato creare ogni tipo di plugin Liferay utilizzando uno strumento completo e complesso come Maven grazie al supporto fornito dal plugin m2eclipse. Ovviamente è possibile applicare quanto appena descritto a qualunque progetto Java che utilizzi Maven e il plugin m2eclipse è davvero un grande aiuto nella facilitazione di una serie di attività.

Figura 4 Il CRM dentro il CMS.

SugarCRM inside of Liferay


Certainly the title of the article may seem a little odd, but I have not found better title. I could give a title like “Integration between CRM ….” but then I was not very convinced!

The protagonists of this short article are: SugarCRM implementing a Customer Relationship Management (or CRM) and Liferay instead implements a Content Management System (or CMS).

We are going through a phase where it is needed more and more integration between most disparate information systems with different responsibilities, it’s like doing a puzzle, combine sets different pieces so that their collaboration allows to reach the goal, trying to maintain a single interface to interact with the whole or parts of the puzzle.

We will then see how it is possible and easy to put SugarCRM “inside” Liferay. Assuming a scenario where Liferay implements a web portal of a hypothetical company would not be something out of the ordinary, give access to CRM from the web portal without having to be forced to open a new browser window and avoid repeating the authentication .

Achieving the goal is really simple with Liferay, it is only an activity configuration of the iFrame portlet, already available with Liferay. As shown in the course of the discussion is applicable to the Community Edition and Enterprise Edition of Liferay, the version used is a 6.1 CE GA2.

1.  Requirements

To ensure that the proposed solution is applicable, it is essential that the following requirements are met:

  • Access to the portal with an administrative role or a role that allows you to add applications (portlets) and configuration options;
  • Ability to perform administrative tasks, such as operations of start, stop and change configurations;
  • URL of SugarCRM.

2.   Behavior

Each user of the portal, so authenticated, you can access directly from the portal to the application of CRM, without repeating the authentication procedure. As introduced above, this is possible through iframe portlets.

The Iframe portlet makes it possible to embed another HTML page inside the current page. Furthermore the user can navigate through the embedded page without loosing the context of the portal page.

The Iframe portlet uses the HTML iframe tag that is part of HTML 4 and is supported in all major browsers. The iframe portlet will adjust to the size of the HTML page if that page is hosted in the same server. The browser will add scrollbars if the embedded page does not fit within the size of the iframe.

An important feature of this portlet and fundamental in this scenario, the possibility to perform the authentication process for us. Supports two types of authentication: Basic and Form, we will use the second method, however, the choice depends on the type of authentication supported by the web application to integrate.

You may have guessed that a prerequisite in order for the authentication to work properly, you must have your username (usually the attribute screen name) and password of the portal coincide with those of CRM.

3.   Configuration

Once you add the portlets on a your page, you just have to continue with the configuration whose main parameters and values ​​are as follows:

  • URL of SugarCRM to which you want to give access;
  • Authentication type:
    • Type: Form
    • Method: POST
    • Username
      • FieldName: user_name
      • Value: @screen_name@
    • Password:
      • FieldName: user_password
      • Value: @password@
    • Hidden Variable
      • module=Users;action=Authenticate

The values ​​shown as @screen_name@ and @password@, then replaced at runtime with the actual values ​​and then sent to SugarCRM in the process of authentication, that’s why it is necessary that the credentials match, in Otherwise you will be necessarily required to manually perform authentication in the form of SugarCRM. In Figure 1 is shown the configuration of the iFrame portlets. The specified URL refers to an instance of SugarCRM CE 6.5 hosted on the Cloud Open Shift.

Figura 1 Configurazione iFrame Portlet per SugarCRM.

Figure 1 Configuration of the iFrame Portlet for SugarCRM.

There is a security mechanism such that your credentials are not stored (in session, cookies, etc …) by default, you can also make sure that only users belonging to a particular role can send your password to external systems through the iFrame portlet.

Figura 2 Creazione del ruolo per l’autenticazione trasperente.

Figure 2 Create a new Role for iFrame Portlet

Through the configuration properties (see the Listing 2) you can enable the storage of the password (unencrypted) in session, and also specify the role to be assigned to users who need to be able to send your password to the outside through the iFrame portlet.

public static String getPassword(PortletRequest portletRequest, String password)
throws PortalException, SystemException {
if (!isPasswordTokenEnabled(portletRequest)) {
return StringPool.BLANK;
}
if (Validator.isNull(password) || password.equals("@password@")) {
password = PortalUtil.getUserPassword(portletRequest);
if (password == null) {
password = StringPool.BLANK;
}
}
return password;
}

Listing 1 Get clear password from session (Link on Gist ).

Listing 1 shows GetPassword() class IFrameUtil com.liferay.portlet.iframe.util package that retrieves the user’s password from the session, checking the association role/user using the method isPasswordTokenEnabled().

Figura 3 Associazione del ruolo all’utente.

Figure 3 User Roles.

###
# IFrame Portlet
###
# Specify a role name that a user must be associated with in order to
# configure the IFrame portlet to use the @password@ token. This token is
# used to post the password of users who access this portlet in order to
# automatically login to the framed site.
#
# No role is required by default. However, it is recommended that you
# specify a role in high security environments where users who configure
# this portlet may attempt password theft. See LPS-5272 for more
# information.
#
iframe.password.token.role=iFrameUserToken
##
## Session
##
#
# Set this to true to store the user's password in the session.
#
session.store.password=true

Listing 2 Configuration properties file portal-ext.properties (Link su Gist).

The configuration (see Listing 2) shows the role (a name of your choice) to which users must belong and the explicit instruction to store in session, the user’s password. The application of this configuration requires a restart of the portal. The configuration shown in Listing 2 must be specified in the file portal-ext.properties. This file must be created or found within the directory webapps/ROOT/WEB-INF/classes.

After restarting the portal and set the iFrame portlet, you would login with your credentials to get your workspace ready to use CRM.

Figura 4 Il CRM dentro il CMS.

Figure 4 SugarCRM inside of Liferay.

Figure 5 shows instead the passage of the parameters to the target application, in this case SugarCRM. I have highlighted in particular the password attribute, passed in the clear.

Figure 5 - Sending the password to the instance of SugarCRM

Figure 5 – Sending the password to the instance of SugarCRM

4.   Conclusions

In this short article we have seen how easy it is to integrate SugarCRM “inside” Liferay exploiting the potential provision by the iFrame portlet. Is certainly convenient to be able to authenticate in a transparent manner. This solution can be used to integrate any type of web application.

Importazione Certificati SSL sul Java Keystore (JKS)


Reblog di uno degli articoli più letti.

Antonio Musarra's Blog

Il meccanismo solitamente adottato per la protezione dei dati End-To-End sulla rete internet è basato sull’utilizzo del protocollo Transport Layer Security (TLS) e il suo predecessore Secure Sockets Layer (SSL), entrambi sono dei protocolli crittografici che permettono una comunicazione sicura e una integrità dei dati su reti TCP/IP, cifrano la comunicazione dalla sorgente alla destinazione sul livello di trasporto.

Una tipica connessione TLS/SSL (per esempio via browser internet) prevede un tipo di autenticazione denominata unilaterale : solo il server è autenticato (il client conosce l’identità del server), ma non vice-versa (il client rimane anonimo e non autenticato). Il client (browser web, EmailUI, Java Client, etc…) valida il certificato del server controllando la firma digitale dei certificati del server, verificando che questa sia valida e riconosciuta da una Certificate Authority conosciuta utilizzando una cifratura a chiave pubblica.

In Figura 1 è illustrato il caso in cui il browser stabilisce una connessione…

View original post 1.440 altre parole

Il blog si trasferisce ma non chiude


Carissimi lettori, da qualche mese la residenza del mio blog è cambiata ma non temete, i battenti di certo non si chiuderanno. Ho iniziato a pubblicare qualche articolo sul nuovo blog e mi farebbe davvero piacere ricevere un vostro feedback e avervi come nuovi follower o per dirla nella nostra lingua, come “miei seguaci”.

Cercherò di mantenere sempre la stessa linea e non far mancare aggiornamenti frequenti, anche se su questo punto il tempo è sempre tiranno. Vi rinnovo l’invito a suggerimenti per argomenti che vorreste vedere pubblicati. A questo punto non resta altro che puntare il vostro browser (che non sia IE) su Antonio Musarra’s Blog.

Grazie a tutti.

Antonio.

2013 in review


The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 58,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 21 sold-out performances for that many people to see it.

Click here to see the complete report.

Creare report con KReporter


Reporting su SugarCRM CE? Possibile e semplice. Date una lettura all’articolo di Alessandro Cecconi.

Sugar corner

KR logoEbbene, come potrei continuare a dribblare impunemente uno degli argomenti principe per chi si imbatte sulla edizione Community di Sugar: il reporting sui dati! Va bene che le funzionalità di ricerca avanzata previste su ogni modulo del nostro CRM sono, per l’appunto, molto avanzate, quasi da costituire esse stesse dei report elementari ma…

View original post 691 altre parole

Come configurare Liferay 6.1 per PostgreSQL


Nel precedente articolo Come configurare Eclipse per Liferay Portal in Mac OS X, pubblicato sul mio blog, abbiamo visto come configurare un ambiente di sviluppo completo per Liferay 6.0 analogamente per la versione successiva di Liferay 6.1. La distribuzione Liferay di default prevede l’utilizzo del data base HSQL (Hypersonic) per la persistenza dei dati. L’utilizzo di questo tipo di data base in ambienti di produzione non è però consigliato. Nel corso di quest’articolo vedremo Step-by-Step come configurare il data base PostgreSQL per la persistenza dei dati di Liferay. Non saranno…READMORE

WSO2 ESB SugarCRM Proxy Service


L’articolo nasce e prende spunto da una domanda indirizzata a me qualche giorno addietro. Esattamente il quesito recitava: Come posso configurare un Proxy Service di SugarCRM sull’Enterprise Service Bus (ESB) di WSO2? La risposta al quesito è stata abbastanza semplice e nel corso di quest’articolo vedremo come sia semplice configurare un Proxy Service. 1. Cos’è un Proxy Service Un Proxy Service è un servizio virtuale che riceve i messaggi e opzionalmente li elabora prima di essere inoltrati a un servizio definito da un end point. Quest’approccio consente di…READ MORE

How to use the Liferay Portal Client Example


Welcome dear readers!

A few days ago, I made ​​a simple example of using the Liferay Client Library. The project is based on Maven. Below are shown the steps needed to perform a test. I remember that the operations performed by the sample program are:

  • Performs login on Liferay;
  • Retrieves the CompanyID based on the virtualhost;
  • Retrieve UserId of the user to ScreenName and CompanyID;
  • Retrieves the GroupId of the site Guest;
  • Performs the upload of a document on the Document Library site Guest.
$ git clone git://github.com/amusarra/liferay-portal-client-example.git
$ cd liferay-portal-client-example/
$ mvn package

List 1. Clone repository and build the package

$ cd target/
$ java -jar portal-client-example-0.0.1-SNAPSHOT-jar-with-dependencies.jar

List 2. Run the portal client example

[00:18:15,816 INFO UploadDocumentOnDL]: Try lookup User Service by End Point: http://will:will@localhost:8080/api/secure/axis/Portal_UserService...
[00:18:16,176 INFO UploadDocumentOnDL]: Try lookup Company Service by End Point: http://will:will@localhost:8080/api/secure/axis/Portal_CompanyService...
[00:18:16,343 INFO UploadDocumentOnDL]: Get UserID...
[00:18:16,378 INFO UploadDocumentOnDL]: UserId for user named will is 11801
[00:18:16,378 INFO UploadDocumentOnDL]: Try lookup Group Service by End Point: http://will:will@localhost:8080/api/secure/axis/Portal_GroupService...
[00:18:16,441 INFO UploadDocumentOnDL]: Found the group Guest (GroupId: 19) to publish the document
[00:18:16,441 INFO UploadDocumentOnDL]: Try lookup DL App Service by End Point: http://will:will@localhost:8080/api/secure/axis/Portlet_DL_DLAppService...
[00:18:16,922 INFO UploadDocumentOnDL]: The file BenchmarkingSugarOnSolaris-SugarCon2009.pdf has been correctly added to liferay
[00:18:16,922 INFO UploadDocumentOnDL]: File Id:13101
[00:18:16,922 INFO UploadDocumentOnDL]: File Size: 735142
[00:18:16,922 INFO UploadDocumentOnDL]: File Version: 1.0

List 3. Show the performed tasks.

Figure 1 - List View of the Document Library

Figure 1 – List View of the Document Library

Figure 2 - Detail View of the document inserted by SOAP Services

Figure 2 – Detail View of the document inserted by SOAP Services