Geo Analysis Tool (actuellement en version alpha 0.6) va permettre aux sociétés et organisations qui possèdent des données au format spatial d’exploiter celles-ci afin d’effectuer des analyses OLAP puissantes et intuitives au travers de clients web (IE, Firefox, Opera).

Pourquoi avons nous développé Geo Analysis Tool ?

• Parce qu’actuellement, une seule implémentation SOLAP existe, celle de Spatialytics avec notamment GeoMondrian et SOLAPLayers. Cette solution nous a séduit (tout comme GeoKettle), notamment par l’implémentation côté serveur avec GeoMondrian, mais nous a frustré par sa difficulté de mise en oeuvre (pas évident de trouver une documentation complète, ni le code source sur sourceforge, il est bien caché… ) et surtout des défauts d’implémentation et des manques fonctionnels en ce qui concerne la partie restitution web

• Parce que Atol CD dispose de compétences techniques pointues en SIG (système d’informations géographiques) et OSBI (Business Intelligence Open Source) et d’une bonne compréhension des besoins fonctionnels des utilisateurs. Atol CD a d’ailleurs déjà réalisé avec MyDocGIS une mashup entre Alfresco (GED open source) et OpenLayers (SIG).

Quel est l’intérêt de Geo Analysis Tool ?

L’objectif du développement de Geo Analysis Tool est très simple:

• Proposer un serveur GEOSBI complet et « out of the box », donc facilement configurable et déployable !

Les prérequis sont les suivants :

• Disposer de données spatiales (le minimum tout de même !)

• Avoir un serveur PostgreSql pour le stockage de ces données avec la cartouche spatiale PostGIS

• Etre capable de créer des schémas de cubes OLAP avec Mondrian

Quelles sont les fonctionnalités de G.A.T. 0.6 alpha ?

Pour les découvrir, je vous invite à visionner la vidéo ci-dessous !

L’architecture de Geo Analysis Tool est la suivante :

Pour continuer, nous avons besoin de vous !

Pour poursuivre nos développements et arriver à la version 1.0 de G.A.T. , n’hésitez pas à déposer vos commentaires, besoins fonctionnels et idées sur GoogleCode, projet geoanalysistool.

Vous y trouverez d’ailleurs une spécification détaillé de Geo Analysis Tool v0.6 !

De notre côté, nous allons préparer et publier sur GoogleCode (dans les 2 mois) le code source et un package d’installation complet…

Sylvain

Atol met à disposition de la communauté Alfresco (sous licence GPL) une extension qui utilise à la fois le Framework Audit Trail et le Framework SURF, son nom de code : AuditSurf.

Cet outil permet d’avoir une vue d’ensemble sur l’utilisation de l’entrepôt Alfresco. Il fournit une assistance à l’administration et un suivi de l’utilisation d’Alfresco.

Fonctionnement général

AuditSurf est découpé en deux blocs :

• un module responsable de la récupération des données d’audit coté entrepôt (module AMP)
• une extension SURF qui assure la présentation / mise en forme des données (Application basée sur le Framework SURF)

Les échanges entre ces deux blocs s’effectuent au travers de connecteurs (HTTP), ce qui permet à notre application SURF d’appeler des WebScripts situés coté entrepôt (le format majoritairement utilisé lors de ces échanges est le JSON).

Voici une schématisation du fonctionnement d’AuditSurf :

Accès aux données :

Les informations d’AuditSurf sont issues du mécanisme d’audit trail d’Alfresco, de JMX (pour la version entreprise seulement) et de l’entrepôt lui-même.

Cette partie va traiter des mécanismes que nous avons utilisés pour extraire les données d’audit de la base de données Alfresco. Si vous désirez avoir des informations sur le mécanisme d’audit au sein d’Alfresco, je vous invite à lire l’article concernant l’audit sur ce blog.

J’illustrerai les mécanismes coté entrepôt Alfresco à l’aide d’un exemple simple (qui sera disponible au téléchargement).

• Accès aux données d’audit (Utilisation d’Hibernate)

La majorité des fonctionnalités de notre application utilisent des données qui sont stockées dans la base de données.

Pour récupérer les informations dans les tables d’audit, nous utilisons le mapping Hibernate mis en place dans Alfresco et plus particulièrement l’API que propose Hibernate : Criteria (c‘est une API d’interrogation par critères intuitive et extensible).

Pour commencer, nous avons créé un service afin de centraliser tous les accès à la base de données via Hibernate. Ce service hérite de la classe abstraite HibernateDaoSupport indispensable pour pouvoir « exécuter » des requêtes Hibernate.

Afin de réaliser des requêtes Criteria, il est utile de consulter le fichier de mapping Hibernate concernant l’audit qui se trouve dans le SDK Alfresco : Audit.hbm.xml.

Prenons un exemple simple : on désire récupérer la liste des documents créés lors des sept derniers jours :

Pour récupérer la liste des documents créés, il faut auditer le service « FileFolderService » et plus particulièrement sa méthode « create ».

Pour construire la requête Criteria, nous aurons besoins des trois tables d’audit :

• La table ALF_AUDIT_SOURCE pour pouvoir sélectionner le service « FileFolderService » et la méthode « create ».
• La table ALF_AUDIT_FACT pour récupérer les informations sur le document (sa date de création et son NodeRef).
• et la table ALF_AUDIT_DATE si l’on souhaite restreindre nos résultats sur une période précise.

Création du service : SimpleAuditService.java

1
2
3
4
5
6
7
8

package com.atolcd.alfresco.auditexample.cmr;
 
import java.util.Calendar;
import java.util.List;
 
public interface SimpleAuditService{
	public List<Object[]> getCreatedDocuments(final Calendar start, final Calendar end);
}

Implémentation du service : SimpleAuditServiceImpl.java

L’implémentation de notre service hérite de la classe HibernateDaoSupport et implémente évidement l’interface SimpleAuditService que nous venons de créer.

• Construction de la requête Criteria

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

package com.atolcd.alfresco.auditexample.repo;
 
import java.sql.SQLException;
import java.util.Calendar;
import java.util.List;
import org.alfresco.repo.audit.hibernate.AuditFact;
import org.hibernate.Criteria;
import org.hibernate.HibernateException;
import org.hibernate.Session;
import org.hibernate.criterion.Expression;
import org.hibernate.criterion.Projections;
import org.hibernate.criterion.Restrictions;
import org.springframework.orm.hibernate3.HibernateCallback;
import org.springframework.orm.hibernate3.support.HibernateDaoSupport;
 
import com.atolcd.alfresco.auditexample.cmr.SimpleAuditService;
 
 
public class SimpleAuditServiceImpl extends HibernateDaoSupport implements SimpleAuditService{
  public List<Object[]> getCreatedDocuments(final Calendar start, final Calendar end){
	HibernateCallback callback = new HibernateCallback()
	{
	    public Object doInHibernate(Session session) throws HibernateException, SQLException
	    {	
		Criteria crit = session.createCriteria(AuditFact.class, "af");
		crit.createCriteria("auditDate", "ad");
		crit.createCriteria("auditSource", "aso");
 
 
		crit.add(Restrictions.eq("aso.service", "FileFolderService"))
		    .add(Restrictions.eq("aso.method", "create"))
		    .add(Restrictions.eq("af.arg3", "{http://www.alfresco.org/model/content/1.0}content"))
			.add(Restrictions.eq("af.fail", false));
 
		if(start != null && end != null)
		    crit.add(Expression.between("ad.date", start.getTime(), end.getTime()));
 
		//Sélection
		crit.setProjection(Projections.projectionList()
		    .add(Projections.property("af.returnValue"))
		    .add(Projections.property("af.date"))
		);
 
		return crit.list();
	    }
	};
 
	List<Object[]> result = (List<Object[]>)(getHibernateTemplate().execute(callback));
 
	return result;
  }
}

Explication de la requête :

La requête ci-dessus est relativement simple et peut se décomposer comme une requête SQL classique.

Puisque l’on utilise Hibernate, on ne travail pas sur des tables mais sur des classes cependant le raisonnement est sensiblement similaire (bien que la construction n’est pas ordonnée de la même façon).

On commence par sélectionner les classes sur lesquelles on désire travailler (équivalent à clause FROM en SQL) en utilisant « createCriteria ». Ensuite, on définit des restrictions (clause WHERE) à l’aide de « Restrictions ». Puis on projette ce dont on a besoin (clause SELECT) à l’aide de « Projections ».

Cette requête Crtieria équivaut à la requête SQL suivante :

1
2
3
4
5
6
7
8
9

SELECT af.return_val, af.timestamp
FROM alf_audit_fact af, alf_audit_date ad, alf_audit_source aso
WHERE af.audit_source_id = aso.id
AND af.audit_date_id = ad.id
AND aso.service = 'FileFolderService'
AND aso.method = 'create'
AND af.arg_3 = '{http://www.alfresco.org/model/content/1.0}content'
AND af.fail = 0
[AND ad.date_only BETWEEN date_debut AND date_fin];

Pour plus d’informations sur Criteria, je vous renvoie vers le site d’Hibernate.

Cet exemple n’est plus d’actualité dans Alfresco 3.2 Entreprise. En effet, dans la dernière monture d’Alfresco, il faut s’intéresser au service « ContentService » et à sa méthode « getWriter » pour avoir des informations sur la création de contenu.
Voici à quoi ressemblerait la requête criteria :

1
2
3
4
5
6
7

crit.add(Restrictions.eq("aso.service", "ContentService"))
	.add(Restrictions.eq("aso.method", "getWriter"))
	.add(Restrictions.eq("af.fail", false));
 
crit.setProjection(Projections.projectionList()
		.add(Projections.property("arg1"))
		.add(Projections.property("af.date"))

• Injection du service via le Framework Spring

Afin de pouvoir utiliser notre service, il faut créer un bean Spring pour que l’on puisse facilement l’injecter dans nos WebScripts.

La déclaration du bean se fait dans le fichier module-context.xml du module :

1
2
3
4
5
6

<bean id="SimpleAuditService"
	class="com.atolcd.alfresco.auditexample.repo.SimpleAuditServiceImpl">
  <property name="sessionFactory">
    <ref bean="sessionFactory"/>
  </property>
</bean>

• Création d’un WebScript

Maintenant que l’on a créé un service capable de récupérer des données d’audit, on peut créer un WebScript qui fera appel à ce dernier.

Les WebScripts d’AuditSurf (coté entrepôt) sont des WebScripts Java-Backed. Ces WebScripts permettent de faire des traitements plus évolués que des WebScripts « classiques ».

Ce genre de WebScript est composé :

• d’une classe Java (qui fera appel à notre service pour pouvoir récupérer les informations d’audit)
• d’un fichier de description qui indique les URLs par lesquelles le WebScript est accessible, son mode d’authentification, …
• d’un ou plusieurs templates (FreeMarker) correspondant aux représentations possibles (un template par format (HTML, JSON, Atom, etc.))
• et éventuellement d’un fichier JavaScript.

Poursuite de l’exemple : on créé un WebScript qui va faire appel à la méthode getCreatedDocuments du service que l’on a créé précédemment (SimpleAuditService).

1. Création de la classe JAVA

Ce WebScript sera de type « DeclarativeWebScript » du fait que les données qu’il renverra seront mises en forme par un template.

Ce WebScript aura besoin du NodeService et du service que nous avons créé. Ces services seront injectés à l’aide de Spring.

Afin de pour pouvoir réceptionner ces services dans la classe Java du WebScript, il faut dans un premier temps définir des « setters ».

Fonctionnement :

Le fonctionnement du WebScript est simple, il va faire appel à notre service puis il va traiter les données qui lui seront renvoyées. Les résultats seront ensuite insérés dans le « model » qui sera transmis au template.

CreatedDocumentsGet.java
(Dans cette exemple, la période est défini par défaut, le WebScript va récupérer les fichiers créés lors des 7 derniers jours)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

package com.atolcd.alfresco.auditexample.web.scripts;
 
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
 
import org.alfresco.service.cmr.repository.NodeRef;
import org.alfresco.service.cmr.repository.NodeService;
import org.alfresco.web.scripts.Cache;
import org.alfresco.web.scripts.DeclarativeWebScript;
import org.alfresco.web.scripts.Status;
import org.alfresco.web.scripts.WebScriptException;
import org.alfresco.web.scripts.WebScriptRequest;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.util.Assert;
 
import com.atolcd.alfresco.auditexample.cmr.SimpleAuditService;
 
 
public class CreatedDocumentsGet extends DeclarativeWebScript implements InitializingBean {
 
  private SimpleAuditService auditService;
  private NodeService nodeService;
 
  // Setters
  public void setAuditService(SimpleAuditService auditService){
    this.auditService = auditService;
  }	     
 
  public void setNodeService(NodeService nodeService){
    this.nodeService = nodeService;
  }
 
  public void afterPropertiesSet() throws Exception {
    Assert.notNull(auditService);
    Assert.notNull(nodeService);
  }           
 
  @Override
  protected Map<String, Object> executeImpl(WebScriptRequest req, Status status, Cache cache){
    try {
	Map<String, Object> model = new HashMap<String, Object>();	
 
	GregorianCalendar start = new GregorianCalendar();
	GregorianCalendar end = new GregorianCalendar();
 
	start.setTime(new Date());
	end.setTime(new Date());
 
	start.add(Calendar.WEEK_OF_YEAR, -1);
 
	List <Object[]> listres = auditService.getCreatedDocuments(start, end);
	Map<Date, NodeRef> docs = new HashMap<Date, NodeRef>();
 
	for(int i=0;i<listres.size();i++){
	  //Exemple : FileInfo[name=AuditHbm.xml, isFolder=false, nodeRef=workspace://SpacesStore/06468917-9e0d-40ee-ba7d-d6125bcbd72f]
	  String fileInfo = (String)listres.get(i)[0];    	
 
	  Pattern pNodeRef = Pattern.compile("nodeRef=([^,]*)]");
	  Matcher matcher = pNodeRef.matcher(fileInfo);
 
	  //Test si le nœud existe
	  if(matcher.find() && this.nodeService.exists(new NodeRef(matcher.group(1)))){
		NodeRef node = new NodeRef(matcher.group(1)); //Récupération du nœud
		docs.put((Date)listres.get(i)[1], node);
	  }
	}			
 
	//Insertion dans le model
	model.put("createdDocs", docs.entrySet());    					
 
	return model;
    }
    catch(Exception e){
	throw new WebScriptException("[CreatedDocumentsGet] Error in executeImpl function");
    }
  }		
}

2. Création du fichier de description du WebScript

Nom du fichier : createddocuments.get.desc.xml

1
2
3
4
5
6

<webscript>
  <shortname>Created documents</shortname>
  <description>Created documents</description>
  <url>/auditexample/CreatedDocuments</url>
  <authentication>admin</authentication>
</webscript>

3. Création de templates

Ensuite, à l’aide de Freemarker, il possible d’effectuer le rendu que l’on souhaite (HTML, JSON, …). Voici deux exemples:

Rendu HTML : createddocuments.get.html.ftl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<#if createdDocs?exists>
  <#if createdDocs?size &gt; 0>
    <ul>
      <#list createdDocs?sort_by("key")?reverse as data>
      <li>
        <#assign node = companyhome.nodeByReference[data.value] />
        <img src="${url.context}${node.icon16}" alt=""> 
        <a href="${url.context}${node.downloadUrl}?ticket=${session.ticket}" title="Download">
	     ${node.properties.name}
	 </a> 
       (${data.key?datetime?string.medium?capitalize})
      </li>
      </#list>			
    </ul>
  </#if>
</#if>

Rendu JSON : createddocuments.get.json.ftl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<#if createdDocs?exists>
  <#if createdDocs?size !=0>
    {
      "node":
      [			
        <#list createdDocs?sort_by("key")?reverse as data>
          <#assign node = companyhome.nodeByReference[data.value] />
          {
		"icon" : "${url.context}${node.icon16}",
		"name" : "${node.properties.name}",
		"downloadUrl" : "${url.context}${node.downloadUrl}?ticket=${session.ticket}",
		"date" : "${data.key?datetime?string.medium?capitalize}"
          }
          <#if data_has_next>,</#if>
        </#list>
      ]
    }
  </#if>
</#if>

4. Injection Spring du Web Script

Il est important de ne pas oublier de lier la classe java (CreatedDocumentsGet.java) au WebScript, pour cela, il est nécessaire de créer un bean Spring, auquel on injectera les deux services dont on a besoin.

1
2
3
4
5
6
7
8
9
10
11

<bean id="webscript.com.atolcd.alfresco.auditexample.createddocuments.get"
	class="com.atolcd.alfresco.auditexample.web.scripts.CreatedDocumentsGet"
	parent="webscript">		
  <property name="auditService">
     <ref bean="SimpleAuditService"/>
  </property>
 
  <property name="nodeService">
     <ref bean="NodeService" />
  </property>				
</bean>

On active l’audit :

1
2

<Audit xmlns="http://www.alfresco.org/model/audit/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" enabled="true" auditInternal="false" mode="all">

On se limitera d’auditer la méthode « create » du service « FileFolderService ».

1
2
3

<Service name="FileFolderService" mode="none">
	<Method name="create" mode="all"/>
</Service>

Cet exemple est disponible ici sous la forme d’un module Alfresco, les sources complètes étant disponibles ici.

Cet exemple ne sera pas fonctionnel en l’état sur Alfresco 3.2 Entreprise.

Adresse pour accéder au WebScript (rendu HTML) :
http://adresse-serveur:port/alfresco/service/auditexample/CreatedDocuments.html

Adresse pour accéder au WebScript (rendu JSON) :
http://adresse-serveur:port/alfresco/service/auditexample/CreatedDocuments.json

Mise en forme / Application SURF :

AuditSurf a été construit à l’aide du Framework SURF (Framework web léger) et est basé sur les WebScripts. (Je vous renvoie vers l’article sur les fondamentaux de SURF, rédigé par Thomas Broyer).

O Comportement SURF

Toute notre application SURF est contenue dans une seule page (hormis la connexion et la déconnexion qui sont gérées par deux autres pages).

La page principale est découpée en une multitude de régions.

Chacune de ces régions étant associée à un composant et chaque composant est lié à un WebScript SURF.

Tous les WebScripts SURF font appels à des WebScripts situés coté entrepôt Alfresco. Pour cela, on utilise des « endpoint » et des connecteurs pour communiquer (Je vous renvoie une nouvel fois vers l’article de Thomas Broyer, §4 de la section « Architecture »).

Ces connecteurs sont définis dans le fichier webscript-framework-config.xml, ils permettent de définir le mode d’accès (mais pas seulement) à l’entrepôt Alfresco (ou une autre source de données).

Nous avons utilisé comme brique de départ, l’excellent tutoriel de Ben Hagan disponible à adresse suivante : http://www.benh.co.uk/alfresco/surf-part-1-getting-started/

• WebScripts SURF, récupération des données :

Fonctionnement général :

Dans AuditSurf, on distingue deux familles de WebScript : ceux destinés à une mise en forme sous forme de « dashlets » (rendu HTML) et ceux destinés pour l’affichage des graphiques (JSON pour Open Flash Chart).

Chaque WebScript de notre extension SURF fait appel à un WebScript qui se situe coté entrepôt Alfresco. Les données récupérées, à l’aide des connecteurs, sont majoritairement des données au format JSON (cependant, ces données peuvent être parfois textuelles).

Ces données sont par la suite traitées afin de pouvoir générer un rendu graphique.

Ces WebScripts sont composés :

• d’un fichier de description
• d’un fichier JavaScript (pour se connecter à un WebScript Alfresco)
• d’un template pour le rendu (HTML ou JSON pour les graphiques)
• des fichiers .properties pour l’internationalisation

Schématisation du fonctionnement des WebScripts coté SURF

Voici un exemple de connexion à un WebScript « Alfresco » via un connecteur (fichier JavaScript) :

1
2
3
4
5

//Création d'un connecteur
var connector = remote.connect("alfresco");
 
//Récupération du JSON renvoyé par le Web Script Alfresco
var json = connector.get("/auditexample/createdDocuments.json");

Il faut ensuite traiter les données (JSON dans le cas présent) afin de récupérer les informations qui nous intéressent.
Ces informations sont ensuite stockées dans le « model » afin que le template Freemarker du Web Script SURF puisse mettre en forme les données.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

//"Evaluation" du JSON
var data = eval( '(' + json + ')');
 
//On boucle sur les objets du JSON
for(var i = 0 ; i<data["documents"].length ; i++) {
	var obj = {
		"icon" : data[i].icon,
		"name" : data[i].name,
		"url" : data[i].downloadUrl,
		"date" : data[i].date
	};					
 
	//On écrit dans le model
	model.items.push(obj);
}

Le fichier Freemarker se charge ensuite de faire le rendu (soit en renvoyant du code HTML soit en renvoyant du JSON pour l’affichage des graphiques).

O Mise en page

La mise en page de notre application SURF est assurée essentiellement par deux choses : d’une part OpenFlashChart pour la génération des graphiques (histogrammes dans notre cas) et d’autre part YUI pour tout ce qui est lié à la mise en page.

• Open Flash Chart

Afin de mettre en valeur les statistiques, nous avons utilisé un projet de rendu graphique Open Source : Open Flash Chart 2.

Cet outil propose une API JavaScript (il existe aussi des librairies PHP, Perl, Python, Ruby, …) pour produire des graphiques en Flash. Les graphiques sont soignés, et offre d’excellentes capacités d’interaction.

Pour générer les graphiques, Open Flash Chart prend en entrée des données au format JSON.

La syntaxe du JSON pour Open Flash Chart est scindée en deux parties : une partie définissant la mise ne page du graphique et une autre partie contenant les données à proprement dit.

http://teethgrinder.co.uk/open-flash-chart-2/json-format.php

L’utilisation de cet outil nécessite l’installation de Flash coté client.

• YUI

YUI est une librairie JavaScript développée par Yahoo (Yahoo User Interface). Cette librairie permet de mettre en place relativement facilement des effets tels que des animations, des panels, la gestion des cookies, etc… Alfresco utilise très largement cette librairie pour son interface SURF Alfresco Share.

YUI a été utilisé, dans AuditSurf, notamment pour :

• créer des effets de transitions
• l’affichage des popups d’information
• le Drag & Drop des dashlets
• et la gestion de cookies (pour se souvenir du positionnement des « dashlets »)

Pour finir :

AuditSurf est disponible dans son intégralité au téléchargement sur la forge Alfresco : http://forge.alfresco.com/projects/auditsurf/

AuditSurf est compatible avec

• les versions Entreprise : 3.0, 3.0.1, 3.1, 3.1.1 et 3.1.2 (cependant les informations JMX avec les versions 3.0.x sont limitées)
• la version Entreprise 3.2
• les versions Community 3.2 / 3.2r / 3.2r2

AuditSurf a été élu contribution du mois d’Août 2009 par Alfresco.

Les fonctionnalités

En plus des fonctionnalités proposées nativement par Kettle et sur lesquelles nous ne reviendrons pas (consulter Sylvain, le spécialiste BI d’Atol pour plus d’infos !), GeoKettle apporte :

Un nouveau type de données « geometry » en plus des types (integer, string, etc.) déjà présents dans Kettle. A la prévisualisation des données, les géométries sont visibles dans leur représentation textuelle Well Known Text (POINT, LINESTRING, POLYGON, etc.) en attendant le « viewer carto » annoncé. Ce type « geometry »est exploitable lors des étapes d’extractions ou d’alimentation depuis ou vers les SGBD Oracle, Postgresql / Postgis / Mysql sans aucune manipulation spécifique (La liste des SGBD supportés devrait par ailleurs s’enrichir prochainement).

De nouvelles étapes dédiées au « GIS » et regroupées dans la catégorie « Geospatial »

• GIS File Input : cette étape permet d’extraire les informations géographiques et attributaires à partir d’une couche ESRI Shapefile (fichiers shp, shx et dbf). Le nom du champ géométrique par défaut est « the_geom ».
• GIS File Output : cette étape permet de générer une couche ESRI Shapefile à partir d’un flux de données contenant notamment un champ de type « geometry ». Si plusieurs champs de type « geometry » sont présents, il faut au préalable passer par une phase d’altération pour sélectionner celui à exporter.
• Set SRS : cette étape permet d’affecter un système de projection cartographique à un champ de type « geometry ». Le code affecté se base sur la liste EPSG mais il est possible de définir sa propre chaine de projection au format WKT. Cette étape est impérative lors d’un import en SGBD spatial dès lors qu’une contrainte sur le système de projection est présente et que le système de projection source associé à la géométrie est inconnu. Elle permet également de de créer le fichier de projection (prj) adéquat lors d’une étape « GIS File Output ». Ce dernier est exploitable par les outils SIG bureautique courants.
• SRS Transformation : cette étape permet de transformer une géométrie d’un système de projection vers un autre. Lors des tests, les résultats pour la transformation du système Lambert 2 Etendu vers le système WGS84 n’ont pas été concluants… Mauvaise manip ?

La modification d’étapes existantes par l’ajout d’opérateurs d’analyse spatiale tels que GIS_INTERSECTS, GIS_EQUALS, GIS_CONTAINS, GIS_CROSS, etc. pour réaliser les opérations de types, « A intersecte B », « A traverse B », etc. Ces opérateurs sont notamment disponibles dans les étapes « Filtrage lignes » et « Produit cartésien ». En terme d’utilisation, les étapes de filtrage de lignes pourront par exemple être utilisées pour effectuer des requêtes spatiales entre fichiers ESRI Shapefile tandis que le produit cartésien permettra de limiter le nombre d’itérations en amont d’une étape de « geoprocessing ».

La possibilité d’exploiter les fonctionnalités de Java Topology Suite (JTS) à travers l’étape « Exécution Scripts Java ». Cette possibilité s’avère intéressante puisque elle permet de tirer partie des opérateurs de construction ou de modification de géométries (effacer A par B, intersecter A et B, fusionner A et B, créer une zone tampon autour de A, etc.) ou d’interroger les propriétés des objets (aire ou périmètre d’un polygone, coordonnées du premier point d’une ligne, etc.). Si les possibilités sont riches, l’utilisation de ces fonctionnalités nécessite de connaitre au minimum les objets, méthodes, etc. offerts par JTS. Cette connaissance s’avère parfois nécessaire, notamment pour effectuer certaines agrégations sur les géométries (l’équivalent du « geomunion » de PostGIS !), l’étape « Agrégation valeurs » de la catégorie statistique n’intégrant pas de fonction «Dissolve» aux cotés de la « somme » ou de la « moyenne ». Pour les habitués du SQL « spatial » allergiques à JTS qui possèdent une connexion à un SGBD spatial (PostgreSQL/PostGIS par exemple), les appels aux fonctions spatiales avec passage de paramètres sont envisageables sans à avoir à charger en amont les données dans son SGBD.

Quelques exemples d’utilisation

• Chargement de fichiers plats en base spatiale pour mise à jour de référentiel géographique sur un serveur de Web Mapping.

• Création d’un fichier Shapefile de polygones à partir d’un fichier Shapefile de polylignes et de points « label » porteurs d’attributs.

• Création de fichiers Shapefile d’entités administratives à partir d’un fichier Shapefile des communes.

Conclusion

GeoKettle trouve naturellement sa place dès lors qu’un processus régulier d’import ou d’export en masse de fichiers géographiques plats est à réaliser mais autorise aussi (sans atteindre les possibilités et les performances d’un « ModelBuilder » d’ESRI ) la mise en place d’opérations de requetage spatial ou de géotraitements , son avantage principal étant de pouvoir s’affranchir là aussi des différentes sources de données. Par ailleurs et d’un point de vue pratique, l’utilisation de GeoKettle ne perturbe pas les méthodes de travail des utilisateurs de Kettle, les fonctionnalités nouvelles spécifiques étant traduites sous formes de nouvelles étapes (alimentation / extraction), d’autres ayant été intégrées au sein étapes existantes (filtrage, produit cartésien). Malgré toute la souplesse et la richesse intrinsèque offerte par GeoKettle, ce dernier possède encore quelques limites :

• Concernant les extractions / alimentations et même si les fichiers ESRI Shapefile restent couramment utilisés, il manque à l’outil la possibilité de pouvoir lire et écrire dans les formats SIG courants (Mapinfo TAB, GML, KML) etc. L’utilisation de la librairie Geotools devrait permettre d’offrir ces fonctionnalités prochainement. En attendant, il est toujours possible de faire appel au sein de tâches à des outils externes en lignes de commande comme OGR2OGR ou à générer et à transformer certains formats basés sur le XML à partir de briques existantes et de transformations XSL (GML,KML).

• Actuellement, l’utilisation des opérateurs de construction géométrique « Buffer, Union, Intersection, Erase, etc. » à travers les scripts reste réservée aux initiés JTS. Là aussi, la mise à disposition d’étapes et d’interfaces graphiques appropriées est annoncé.

• Il manque encore quelques fonctionnalités comme les agrégations (dissolve) de géométries ou la générations de lignes à partir de multi-géométries (Ceci peut être cependant réalisé à travers JTS)

• Enfin, coté performances, si les imports et exports de données géographiques ne posent pas de problèmes particuliers, la manipulation évoluée (opérations successives d’union de buffer, etc) des géométries à travers des scripts JTS consomme beaucoup de ressources. Il faut garder à l’esprit que GeoKettle reste un outil ETL générique et q’uil n’a pas vocation à remplacer les outils SIG spécifiques.

L’avis du spécialiste BI d’Atol

GeoKettle est un projet de Business Intelligence Open Source développé par Spatialytics, une société québecoise qui offre des services et des solutions de GeoBI. A noter que cette société développe également deux autres projets très intéressants dans le domaine du GeoBI :

• GeoMondrian, une version “géo-capable” du serveur OLAP Mondrian que l’on retrouve dans sa version de base dans les plates-formes OSBI Pentaho et JasperServer.GeoMondrian permet une intégration consistante d’objets spatiaux (géométries) dans une structure de données en cube plutôt que de devoir les obtenir ailleurs, à partir d’un SGBD spatial, un Service Web ou des fichiers SIG. GeoMondrian intègre également les premières extensions spatiales au langage de requête multidimensionnel MDX ajoutant ainsi de puissantes capacités de requête et d’analyse spatiale dans les cubes.

• SOLAPLayers (ex « Spatialytics ») est un framework cartographique web 2.0 pouvant être intégré dans des tableaux de bord existants afin de permettre la navigation et l’interrogation spatiale (OLAP Spatial ou SOLAP) de cubes de données, comme ceux que supporte GeoMondrian. Il s’appuie sur OpenLayers et Dojo et permet la connexion à un serveur SOLAP tel que GeoMondrian, la navigation dans des cubes avec contenu géospatial, la représentation cartographique de données et mesures statistiques sous forme de cartes thématiques statiques ou dynamiques.

Alfresco met à disposition, depuis sa version 1.4, un Framework permettant de gérer l’audit : le Framework AuditTrail. L’audit est activable et configurable via un fichier de configuration XML (à noter que par défaut il est désactivé).

Le système d’audit est basé sur des intercepteurs. Ces intercepteurs se déclenchent lorsqu’une méthode d’un service Alfresco est appelée (suivant la configuration qui a été faite de l’audit).

L’intercepteur stocke ensuite les informations sur ce qu’il s’est passé dans la base de données (par exemple : qui l’a appelée, sur quel fichier, identifiant du nœud, …).

Il faut savoir que suivant le service et/ou la méthode qui a été appelé, les informations d’audit stockées dans la base de données différent.

Un même service peut comporter plusieurs méthodes « auditables » et si on le désire, il est possible d’auditer seulement une partie d’entre elles.

Par exemple, voici une liste (non-exhaustive) des méthodes « auditables » du FileFolderService : rename, move, copy, create, delete, makeFolders, getWriter, …

Vous pouvez retrouver la liste complète des services qui sont « auditables » sur le wiki Alfresco [en].

Plus d’informations sur l’Audit en général sont également disponibles sur le wiki Alfresco [en] :

http://wiki.alfresco.com/wiki/Audit

L’audit, à quoi ça sert ?

L’audit peut notamment permettre de dresser des statistiques (ce qui est le cas de notre application AuditSurf), surveiller certaines actions, …

Ou sont stockées les données ?

Les informations d’audit sont stockées dans la base de données Alfresco et plus particulièrement dans les tables préfixées par « ALF_AUDIT ».

Les tables concernées sont : ALF_AUDIT_FACT, ALF_AUDIT_DATE et ALF_AUDIT_SOURCE.

La table ALF_AUDIT_FACT est le pilier du système d’audit d’Alfresco. C’est dans cette table que sont stockées les principales informations auditées.

A chaque action auditée correspond un service et une méthode ayant déclenché cette trace (informations stockées dans la table ALF_AUDIT_SOURCE) ainsi que la date à laquelle l’action s’est déclenchée (ALF_AUDIT_DATE).

La table ALF_AUDIT_DATE est utile seulement si l’on souhaite avoir le détail complet sur la date. Sinon, l’attribut « timestamp » de la table ALF_AUDIT_FACT est amplement suffisant.

Qu’est ce qui est audité et sous quelle forme ?

En dehors de la source (nom du service et nom de la méthode) et de la date de chaque audit, voici la liste des informations d’audit les plus pertinentes (stockées dans la table ALF_AUDIT_FACT) :

• user_id : identifiant de l’utilisateur qui a déclenché la trace d’audit
• timestamp : la date et l’heure à laquelle l’audit a eu lieu (pour avoir une date plus complète (numéro de la semaine, jour de l’année, …), il faut utiliser les champs de la table ALF_AUDIT_DATE).
• return_val : c’est la valeur retourné par la méthode auditée.
• fail : vaut 0 si l’action s’est correctement déroulée, 1 en cas d’échec.
• arg_# : les informations les plus utiles sont stockées dans les arguments (arg_1, arg_2, arg_3, arg_4 et arg_5).

  Les valeurs de ces arguments dépendent des services et des méthodes qui ont été audités.

Voici deux exemples qui permettent d’illustrer et d’analyser ce qui est audité :

• 1^er exemple : auditer les connexions des utilisateurs

@Auditable(parameters={"userName", "password"}, recordable={true, false}) 
void authenticate(java.lang.StringuserName, char[]password)

Voici ce qui est audité lors de l’appel de la méthode « authenticate » du service « AuthenticationService » :

On remarque que peut de choses sont auditées dans ce cas, on peut seulement retrouver le login de l’utilisateur, l’heure à laquelle il a essayé de s’authentifier et s’il a réussi ou non.

Il n’est pas possible pour l’instant via l’audit de connaître le moyen de connexion utilisé par l’utilisateur pour se connecter à l’Alfresco (CIFS, WebDav, FTP, navigateur Web, …).

De plus certains types accès ne laissent pas de traces d’audit (cf. section Problèmes Rencontrés).

• 2^ème exemple : auditer l’ajout de contenu.

@Auditable(key=ARG_0, parameters={"parentNodeRef", "name", "typeQName"})
FileInfo create(NodeRefparentNodeRef, java.lang.Stringname, QNametypeQName)

Lors de l’ajout (ou la création) de contenu, la méthode « create » du service « FileFolderService » est appelée. Voici les données qui sont auditées lors de l’appel de cette méthode :

Ces deux enregistrements sont le résultat d’un ajout de fichier (1ère ligne) et de la création d’un espace (2ème ligne).

L’audit, pour cette méthode (create), est assez complet : grâce au champ « return_val« , on peut récupérer plusieurs informations sur le nœud qui vient d’être créé :

• son nom
• le fait de savoir si c’est un espace ou non
• son NodeRef

Dans le cas présent, l’attribut « arg_1 » stocke le NodeRef de l’espace parent ou a été créé le fichier (ou l’espace), « arg_2 » stocke quand à lui le nom du fichier (ou de l’espace) et « arg_3 » stocke le type du contenu (QName) :

• {http://www.alfresco.org/model/content/1.0}content si c’est un fichier
• {http://www.alfresco.org/model/content/1.0}folder si c’est un espace

Cet exemple n’est plus d’actualité dans Alfresco 3.2 Entreprise. En effet, dans la dernière monture d’Alfresco, il faut s’intéresser au service « ContentService » et à sa méthode « getWriter » pour avoir des informations sur la création de contenu.

Comment activer l’audit ?

Pour activer ce service, il faut modifier le fichier XML : auditConfig.xml, qui se trouve dans le dossier : /tomcat/webapps/alfresco/WEB-INF/classes/alfresco/.

Dans ce fichier, il faut passer l’attribut « enabled » à « true » :

<Audit xmlns=« http://www.alfresco.org/model/audit/1.0″
xmlns:xsi=« http://www.w3.org/2001/XMLSchema-instance » enabled=« true » auditInternal=« false » mode=« all »>

Pour que l’audit fonctionne dans Alfresco 3.2 Entreprise (dans Alfresco 3.2r et 3.2r2 Community également), il faut rajouter ces deux lignes au fichier « alfresco-global.properties » :

• audit.enabled=true
• audit.useNewConfig=false

Il est ensuite possible de configurer plus précisément ce que l’on désire auditer ou non.

Configuration de l’audit :

Pour activer l’audit, sur un service ou une méthode, il suffit de passer son attribut mode à « all » ou de le passer à « none » pour le désactiver.

Exemples :

• Activer l’audit sur toutes les méthodes « auditables » du FileFolderService :

<Service name=« FileFolderService » mode=« all »>

</Service>

• Activer l’audit seulement sur certaines méthodes :

<!– The File/Folder Service –>

<Service name=« FileFolderService » mode=« none »>

<Method name=« create » mode=« all »/> <!– Audit Activé –>

<Method name=« delete » mode=« none »/> <!—- Audit Désactivé –>

…

</Service>

• Désactiver l’audit sur le FileFolderService :

<Service name=« FileFolderService » mode=« none »>

</Service>

La liste des services/méthodes présentes dans le fichier de configuration n’est pas exhaustive.

Par exemple, pour pouvoir compter le nombre de workflows il faut rajouter la méthode startWorkflow dans le service WorkflowService :

<Service name=« WorkflowService » auditInternal=« true »>

<Method name=« startWorkflow » mode=« all »/>

</Service>

De même, pour pouvoir compter les lectures de document, il faut rajouter la méthode getReader sur les services FileFolderService et ContentService :

<Service name=« FileFolderService » mode=« none »>

<Method name=« getReader » mode=« all »/>

</Service>

<Service name=« ContentService » mode=« none »>

<Method name=« getReader » mode=« all »/>

</Service>

http://wiki.alfresco.com/wiki/Audit_Configuration

Bon à savoir :

• Volumétrie

Si vous activez beaucoup de services et que l’utilisation de votre Alfresco est conséquente, le nombre d’informations stockées en base risque de croitre très rapidement.

• Problèmes rencontrés

L’audit ne permet pas d’auditer certaines actions suivant le type d’accès à Alfresco.

Suivant l’accès utilisé pour accéder à Alfresco, l’authentification (Service : AuthenticationService / Méthode : authenticate) peut ne pas être auditée, voici un tableau récapitulatif :

• Certaines données « à prendre avec des pincettes » :

Il semblerait que suivant le type de fichier, les audits concernant les lectures ne se fassent pas de la même manière.

Nous avons eu des problèmes, notamment avec des fichiers pdf, qui laissent en moyenne deux fois plus de traces dans les tables d’audit. Ce problème est visible sur les lectures dans le navigateur, et semble être lié au poids du fichier lu.

]]> http://blog.atolcd.com/?feed=rss2&p=217 0 http://blog.atolcd.com/?p=174 http://blog.atolcd.com/?p=174#comments Tue, 06 Oct 2009 14:31:13 +0000 Jean-Philippe Thevenoux http://blog.atolcd.com/?p=174

Présentation du besoin de départ

Au départ de ce projet, le sentiment de se poser souvent les même questions pour réaliser une application web de consultation/mise à jour de données issues d’une base de données. Quelle bibliothèque de composants utiliser, comment gérer mes formulaires, comment utiliser des tableaux évolués, comment accéder aux données, …

Ce genre d’application regroupe principalement les fonctionnalités suivantes :

• grille avec pagination pour lister les enregistrements des différentes tables,
• filtrage de ces grilles,
• formulaire d’édition des enregistrements,
• imbrication « complexe » de formulaire (e.g. : édition d’un auteur avec ses articles en même temps),
• validation par rechargement des pages (et non pas par Ajax, afin de rassurer l’utilisateur, ce qu’il voit sur la page correspond bien à ce qui est en base).

La réflexion

Symfony s’impose assez facilement comme base de développement. Il possède une gestion de routing très puissante, une DAO intégrée (Doctrine) , une gestion de formulaire complète (un élément important dans le choix de notre solution), une structure permettant le développement en parallèle sans gêne.

ExtJs est une bibliothèque javascript évoluée pour faire des applications riches. Elle possèdent des composants de haut niveau (grille, arbre, combo, …), un système d’évènement complet, différents layout offrant toutes les possibilités de mise en forme, une abstraction de l’accès au données (via les stores) …

Le but est donc de mettre en commun ces deux environnements.

Explication des choix

Les autres plugins existants

Il existe un plugin pour Symfony 1.0 et ExtJs 2.1 (sfExtjs2Plugin)

Ce plugin a pour principe de créer le code ExtJs complètement depuis symfony via un helper et des méthodes « asMethod, asVariable, … ». Au lieu d’écrire du code javascript, on écrit du php qui lui va écrire du javascript.

Ce principe est intéressant pour certaines applications, il permet de centraliser tout le code à un seul endroit.

Mais ce plugin n’est pas adapté au formulaire de symfony (version 1.2). Or c’est un des avantages que l’on voulait utiliser. Donc l’utilisation de ce plugin était dès le départ compromise.

Formulaire vers Widgets

Le besoin initial portait sur les formulaires, mais cela pouvait aussi s’appliquer à d’autres composants ExtJS, tels les tableaux, les fieldset, les panel, …

En construisant la page comme une arborescence de composants ExtJS, on peut décrire côté symfony la page comme une arborescence de widgets (panel contenant un fieldset contenant une grille), et on peut garder aussi le découplage formulaire/template.

Description de la solution

ExtJs 2 définissait un « xtype » pour quasiment tous les « composants » graphique, ExtJs 3 a poussé le concept en définissant un « xtype » sur tous les classes (store, colonne, …). Cela permet d’écrire une page complète uniquement via une description JSON.

C’est donc sur cette méthode que nous nous sommes orientés.

Une classe de base « PluginExt3Base » qui étend « sfWidgetForm » permet de gérer les attributs d’un objet, des gérer les sous-éléments, et possède des fonctions pour convertir cet objet en une description JSON.

D’autres classes, qui héritent de celle-ci, plus spécifiques, permettent une définition directe d’un type d’objet (« PluginExt3Label », « PluginExt3Panel », …) et possèdent des fonctions propre à ce type d’objet.

Un Helper a été mis en place pour automatiser l’écriture des objets dans les variables adéquates. Pour interpréter la description JSON, un fichier javascript récupère les variables écrite par le template Symfony, et crée les objets grâce à la fonction Ext.ComponentMgr.create.

Pour les formulaires

Symfony utilise un système de routing très performant et très simple en même temps. Une URL correspond à une action d’un module. Une URL est définie par son adresse mais aussi par sa méthode. Un appel en GET ou en POST peut donc être redirigé vers la même action du même module, ou bien vers 2 actions distinctes.

Les navigateurs ne permettent pas tous de gérer les 4 méthodes de HTTP (GET, POST, DELETE et PUT) donc Symfony a mis en place un système pour gérer cela. Dans une requête, si un paramètre « sf_method » est passé, alors la valeur de ce paramètre permet de définir la méthode de l’appel.

Lors de la création de l’objet spécifique formulaire, on passe en paramètre l’URL de destination ainsi que la méthode d’appel. Cela permet de gérer tous les cas possible.

Les formulaires Symfony sont composés de 2 parties, une définition des widgets (pour 1 champs, comment il est représenté) et une définition des validators (pour 1 champs, quelles sont les règles qu’il possède)

Les widgets de base de Symfony sont remplacé par les widgets ExtJs, et les validators sont gardés. Cela permet de garder toutes la puissances de traitement automatique des formulaires (validation, message d’erreur, …) tout en ayant la flexibilité de l’affichage ExtJs.

Pour d’autres pages

Dans les templates, l’organisation de la page est libre. Il est relativement facile de créer un panel qui contient 2 panels qui contiennent chacun des onglets qui eux mêmes contiennent chacun une grille …

Les templates étant des fichiers php, il est tout à fait possible d’automatiser la création de composants dans une boucle, de conditionner l’affichage, etc. Ceci autorise la création de pages relativement chargées et complexes avec très peu de code.

Quand un composant, ou un comportement est vraiment trop complexe, il est tout a fait possible de créer un nouveau composant ExtJs dans un fichier javascript, de lui attribuer un « xtype », et de créer le composant correspondant dans l’application.

Pour une application, nous avons ainsi développé un composant qui hérite d’une grille, et qui le complète avec une gestion automatique de la pagination, des filtres par colonne, des liens par ligne, et d’autres possibilités.

Une fois ce composant créé, il suffit, dans un template, d’instancier cet élément pour avoir accès à toutes ses fonctionnalités. Et comme ExtJs permet facilement de faire de l’héritage, il est encore plus facile de créer un composant possédant un comportement bien spécifique.

Exemple de code :

Définition d’un formulaire. Celui-ci permet de faire le lien entre un objet et une table de la base de donnée, de définir sous quel format apparaitrons les champs et de définir quels sont les contrôles qui seront appliqués.

lib/form/doctrineExt/usersExt3Form.php

class usersExt3Form extends PluginExt3FormDoctrine
{
  public function setup()
  {
    parent::setup();
 
    // create combobox "type user"
    $result = Doctrine::getTable('typeusers')->getAll()->execute();
    $cboUserType = PluginExt3DoctrineComboBox::fromResult($result, 'idtypeuser', 'labeltypeuser');
    $cboUserType->setAttribute('fieldLabel', 'User Type');
    $cboUserType->setAttribute('allowBlank', false);
 
    $widgets = array (
    'lname'=> new PluginExt3TextField( array ('allowBlank'=>false, 'fieldLabel'=>'Last name')),
    'fname'=> new PluginExt3TextField( array ('allowBlank'=>false, 'fieldLabel'=>'First name')),
    'codeidentification'=> new PluginExt3TextField(array('fieldLabel'=>'Identification code')),
    'login'=> new PluginExt3TextField( array ('allowBlank'=>false)),
    'email'=> new PluginExt3EmailField(),
    'idusertype'=>$cboUserType
    );
    $this->setWidgets($widgets);
 
    $validators = array (
    'lname'=>$this->getWidget('lname')->getValidator(),
    'fname'=>$this->getWidget('fname')->getValidator(),
    'codeidentification'=>$this->getWidget('codeidentification')->getValidator(),
    'login'=> $this->getWidget('login')->getValidator(),
    'email'=>$this->getWidget('email')->getValidator(),
    'idusertype'=>$this->getWidget('idusertype')->getValidator()
    );
    $this->setValidators($validators);
 
    $this->widgetSchema->setNameFormat('users[%s]');
  }
 
  public function getModelName()
  {
    return 'users';
  }
}

Le fichier d’action qui permet de créer le formulaire, de le remplir si on est en méthode « POST », de contrôler le formulaire, et enfin de sauvegarde l’objet lié au formualire

actions/actions.class.php

class sfMonAppActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->form = new usersExt3Form();
 
    if ($request->isMethod('POST'))
    {
      $this->form->bind($request->getParameter($this->form->getName()));
      if ($this->form->isValid())
      {
        $this->form->save();
        $this->getUser()->setMessage('OK', 'successful');
        $this->redirect('@home');
      }
      else
      {
        $this->getUser()->setMessage('ERROR', 'Forms contains error', $this->form->getErrorSchema());
      }
    }
  }
}

Le template permet de définir l’affichage final.
templates/indexSuccess.php

  $formPanel = new PluginExt3FormPanel('/', $form);
  $formPanel->setAttribute('title', "Hello World !");
  $ret = '<script type="text/javascript"><!--mce:0--></script>';
  echo $ret;

Côté client un fichier javascript permet d’interpréter le code final généré par le template

Quelques points précis

Validators

Les validators de Symfony sont utilisés pour contrôler les formulaires. Il existe de nombreux validators (date, e-mail, url, texte, …) et il est facile de créer de nouveaux validators, ou d’étendre un validator existant pour le spécialiser.

Côté ExtJs, des validators « simple » peuvent être utiliser pour contrôler la saisie (champs obligatoire, champ numérique).

La combinaison de ces deux types de contrôles permet d’avoir une interface riche, interactive et de minimiser les échanges avec le serveur.

Exemple :
Définition d’un formulaire, avec des propriétés de contrôle :

$widgets = array(
 'name' => new PluginExt3TextField(array('fieldLabel'=>'Nom')),
 'code' => new PluginExt3TextField(array('maxLength'=>5, 'minLength' =>5, '@maskRe' =>'/^[0-9]$/', 'allowBlank'=>false)),
 'startdate' => new PluginExt3DateField(array('fieldLabel'=>'Date de début'))
);

Code JSON généré :

{
  xtype:"textfield",
  autoCreate: {tag:"input",type:"text",size:20,autocomplete:"on"},
  name:"mydata[name]",
  value:null,
  fieldLabel:"Nom",
  invalidText:""
},{
  xtype:"textfield",
  maxLength:5,
  minLength:5,
  maskRe:/^[0-9]$/,
  autoCreate: {tag:"input",type:"text",size:20,autocomplete:"on"},
  name:"mydata[code]",
  value:null,
  fieldLabel:"Code",
  invalidText:""
},{
  xtype:"datefield",
  format:"m/d/Y",
  invalid:"Invalid date format : mm/dd/yyyy",
  altFormats:"d/m/Y|d/m/y|Y-m-d",
  allowBlank:true,
  fieldLabel:"Start date",
  autoCreate: {tag:"input",type:"text",size:20,autocomplete:"on"},
  name:"mydata[startdate]",
  value:null,
  invalidText:""
}

Visuel rendu :

Imbrication de sous-formulaires

De base, les formulaires Symfony peuvent « inclure » d’autres formulaires, et utilisent un « décorateur » pour l’inclusion.

Symfony propose de lier un formulaire à un objet (de la DAO ou autre). Cela permet de d’avoir directement au niveau du formulaire des méthodes pour mettre à jour l’objet en question et pour le sauvegarder. Cela implique d’avoir au niveau des formulaires les méthodes nécessaires. Cela permet entre autre une gestion des formulaires imbriqués (mise à jour et sauvegarde en cascade).

Pour notre application, cet aspect des formulaires est important, nos formulaires héritent donc de « sfFormDoctrine ».

Le choix de construire toute l’arborescence de la page par une hiérarchie de composants nous oblige à imbriquer nos formulaires dans des widgets qui n’ont pas une vocation de formulaire (filedset, …).

Nous avons donc développé un objet « dummyExt3FormDoctrine » qui permet de faire « comme si » le formulaire était basé sur un objet, alors que ce n’est pas le cas. Cela nous permet de garder les avantages des formulaires Doctrine avec une gestion en cascade des sous-formulaires.

Cet objet autorise donc la création de formulaire contenant des sous-formulaires avec un décorateur spécifique (fieldset, colonne, …), mais permet aussi, grâce à l’héritage, de faire des formulaires dont une partie est lié à la base de données, les ‘autres parties possédant uniquement du code métier. Toutes les imbrications sont possibles.

Et MVC dans tout ça ?

Avec cette technique, on perd un peu le découplage Vue /Contrôleur car le contrôleur va lui-même créer les formulaires et les mettre en forme.

Le modèle gère complètement tout l’accès à la base de donnée, et est relativement « indépendant » de la vue et du contrôleur. Une majorité du code métier est inclus dans cette partie (création de données dans les tables annexes par exemple).

Le contrôleur fait peu de chose. Il instancie les formulaires, appelle les fonctions sur ces formulaires (isValid, save, …), s’occupe de récupérer les données de la DAO pour les proposer à la vue. Il possède peu de code métier.

La vue s’occupe de toute la mise en forme, elle s’occupe de créer les grilles, de rendre les formulaires.

Le découplage effectué est relativement respectueux du processus MVC.

Le seul point non respectueux se produit lors de l’imbrication des formulaires par le contrôleur car c’est ce contrôleur qui va définir le décorateur à utiliser, et non la vue.

Page officiel du plugins : http://www.symfony-project.org/plugins/atolExt3WidgetPlugin
Symfony : http://www.symfony-project.org/
ExtJs : http://www.extjs.com/

Alfresco est une alternative à Sharepoint et le tutoriel d’Alfresco en français alfresco-et-sharepoint vous donnera un aperçu de la solution.

Que faire ? Mettre en place un système de SSO et CAS répond très bien à ce problème.

Principes d’authentification de Share et de CAS

Je ne vais pas revenir sur l’installation et la configuration d’un serveur CAS. Ceci n’est pas l’objet de ce billet. Nous verrons uniquement comment CASifier Share (ce qui va déjà nous occuper un petit moment).

Je vais revenir rapidement sur le principe d’authentification de Share pour bien exposer le problème :

• l’utilisateur ouvre l’application Share
• Share affiche la page de login
• l’utilisateur envoie le couple login / mot de passe
• ce couple est envoyé vers un webscript Alfresco par Share
• si Alfresco valide le couple, il renvoie un ticket
• Share utilisera ce ticket pour toutes les futures communications avec Alfresco

Ceci montre que le mot de passe donné sur la page de login de Share est ensuite envoyé à Alfresco. C’est la réponse d’Alfresco qui conditionne l’accès (ou non) à l’application Share.

Une application CASifiée utilise le principe suivant pour authentifier un utilisateur :

• connexion de l’utilisateur à l’application (il n’a pas encore de ticket CAS valide)
• l’application le renvoie vers la page de login de CAS
• l’utilisateur envoie le couple login / mot de passe à CAS
• ce couple est validé par le backend de CAS
• si le couple est valide, CAS redirige l’utilisateur vers l’application accompagné d’un ticket ST (Service cket)
• l’application valide le ticket ST auprès de CAS et récupère le login de l’utilisateur
• l’application authentifie l’utilisateur uniquement sur le login

De ces deux procédures d’authentification, on peut déjà faire ressortir le principale problème : l’application CASifiée ne voit jamais le mot de passe de l’utilisateur. Dans ce cas comment Share peut-il envoyer le couple login / mot de passe à Alfresco ?

Quelles sont les solutions ?

Une première piste serait d’utiliser notre ticket ST dans Share et l’envoyer à la place du mot de passer à Alfresco. Il faudrait réaliser des modifications côté Alfresco pour valider ce ticket ST auprès du serveur CAS. Cependant, cela ne peut fonctionner car un ticket ST est à usage unique. Il est invalidé côté CAS après la validation de Share, il ne peut donc plus être utilisé par Alfresco.

La seconde piste (qui sera la bonne) est l’utilisation d’un Proxy Ticket (PT). Le système de proxy a été introduit dans CAS 2, il faudra donc utiliser un serveur et un client supportant cette architecture.
Si on reprend la procédure d’authentification de CAS avec l’utilisation d’un PT, cela devient :

• connexion de l’utilisateur à Share (il n’a pas encore de ticket CAS valide)
• Share le renvoie vers la page de login de CAS
• l’utilisateur envoie le couple login / mot de passe à CAS
• ce couple est validé par le backend de CAS
• si le couple est valide, CAS redirige l’utilisateur vers Share accompagné d’un ticket ST (Service Ticket)
• Share valide le ticket ST auprès de CAS et demande un PGT (Proxy Granting Ticket)
• CAS renvoie le login de l’utilisateur et un PGT
• Share demande un PT (Proxy Ticket) à CAS à l’aide du PGT
• CAS renvoie le PT
• Share envoie le PT à Alfresco via un webscript
• Alfresco valide le PT via CAS et récupère le login
• Alfresco crée un ticket (un ticket Alfresco, pas un ticket CAS) et le renvoie à Share pour les futures échanges

Ouf ! C’est un peu long, mais ça fonctionne et c’est totalement transparent pour les utilisateurs.
Bon, on a un principe qui est fonctionnel, il ne nous reste plus qu’à passer au plus intéressant : la réalisation.

En pratique…

En pratique, il faut modifier Share et Alfreso. Des modifications des deux côtés sont nécessaires pour mettre en place le SSO. Les modifications se résument à quelques fichiers Java et beaucoup de XML.

Côté Share

• web.xml : ajouter les filtres pour CAS
• webscript-framework-config.xml : modification de classe d’authentification (envoie du PT à la place du mot de passe sur un nouveau webscript)
• ajouter le jar du client CAS
• ajouter deux nouvelles classes Java :
  • CasAuthenticationFilter : valide le ST, récupère le PT et authentifie l’utisateur dans Share
  • CasAlfrescoAuthenticator : envoie le PT vers un webscript Alfresco et récupère un ticket Alfresco

Côté Alfresco

• web.xml : ajouter les filtres pour CAS
• ajouter le jar du client CAS
• ajouter le webscript recevant le PT de Share
• ajouter la classe Java pour l’authentification CAS classique

Le code

• alfresco-cas.zip
• share-cas.zip

Ces deux archives contiennent tout le code et les modifications nécessaires pour mettre en place un SSO basé sur CAS entre Share et Alfresco. Avant d’utiliser ces fichiers, il faut les modifier pour correspondre à votre installation (notamment les adresses des serveurs CAS et Alfresco).

L’implémentation va encore une fois se faire par le biais d’une action Alfresco, mais utilisera la librairie PDFBox, embarquée par Alfresco.

PDFBox [en] est une librairie Java Open-Source (licence BSD) permettant de travailler avec des fichiers PDF (génération, modification et extraction de contenu). Elle comporte également plusieurs programmes utilisables en ligne de commande.

Détails de l’action

Pour cette action de protection, il va nous falloir comme paramètres :

• les mots de passe propriétaire et utilisateur du document,
• le détail des actions autorisées.

Dans PDFBox, ce type de protection est représenté par les objets ProtectionPolicy (pour la partie authentification) et AccessPermission (pour la partie détail); plus précisément nous utiliserons une StandardProtectionPolicy, une protection par mot de passe (par opposition à la PublicKeyProtectionPolicy, protection par certificat).

Notre action va donc ouvrir le document PDF, vérifier si il n’est pas déjà protégé, puis créer la protection à partir des paramètres utilisateurs et enfin l’appliquer.

package com.atolcd.repo.action.executer;
 
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.List;
 
import org.alfresco.model.ContentModel;
import org.alfresco.repo.action.ParameterDefinitionImpl;
import org.alfresco.repo.action.executer.ActionExecuterAbstractBase;
import org.alfresco.repo.content.MimetypeMap;
import org.alfresco.service.cmr.action.Action;
import org.alfresco.service.cmr.action.ParameterDefinition;
import org.alfresco.service.cmr.dictionary.DataTypeDefinition;
import org.alfresco.service.cmr.repository.ContentReader;
import org.alfresco.service.cmr.repository.ContentService;
import org.alfresco.service.cmr.repository.ContentWriter;
import org.alfresco.service.cmr.repository.NodeRef;
import org.alfresco.util.TempFileProvider;
import org.pdfbox.exceptions.COSVisitorException;
import org.pdfbox.pdmodel.PDDocument;
import org.pdfbox.pdmodel.encryption.AccessPermission;
import org.pdfbox.pdmodel.encryption.BadSecurityHandlerException;
import org.pdfbox.pdmodel.encryption.StandardProtectionPolicy;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.util.Assert;
 
public class PDFProtectActionExecuter extends ActionExecuterAbstractBase
	implements InitializingBean {
 
    public static final String NAME = "protect";
    public final static String PARAM_OWNER_PASSWORD = "owner_password";
    public final static String PARAM_USER_PASSWORD = "user_password";
    public final static String PARAM_ASSEMBLY = "assembly";
    public final static String PARAM_EXTRACT_CONTENT = "extract_content";
    public final static String PARAM_EXTRACT_ACCESSIBILITY = "extract_accessibility";
    public final static String PARAM_FILLING = "filling";
    public final static String PARAM_MODIFY = "modify";
    public final static String PARAM_MODIFY_ANNOTATIONS = "modify_annotations";
    public final static String PARAM_PRINTING = "printing";
    public final static String PARAM_DEGRADED_PRINTING = "degraded_printing";
 
    private ContentService contentService;
 
    public void afterPropertiesSet() throws Exception {
	Assert.notNull(contentService);
    }
 
    public void setContentService(ContentService contentService) {
	this.contentService = contentService;
    }
 
    @Override
    protected void executeImpl(Action action, NodeRef actionedUponNodeRef) {
	ContentReader reader = contentService.getReader(actionedUponNodeRef,
		ContentModel.PROP_CONTENT);
	if (MimetypeMap.MIMETYPE_PDF.equals(reader.getMimetype())) {
	    PDDocument doc = null;
	    try {
		File newPdf = TempFileProvider.createTempFile("tmp", "protect");
		FileOutputStream fos = new FileOutputStream(newPdf);
 
		doc = PDDocument.load(reader.getContentInputStream());
 
		if (!doc.isEncrypted()) {
		    Boolean allowAssembly = (Boolean) action
			    .getParameterValue(PARAM_ASSEMBLY);
		    Boolean allowExtraction = (Boolean) action
			    .getParameterValue(PARAM_EXTRACT_CONTENT);
		    Boolean allowExtractionAccessibility = (Boolean) action
			    .getParameterValue(PARAM_EXTRACT_ACCESSIBILITY);
		    Boolean allowFillingInForm = (Boolean) action
			    .getParameterValue(PARAM_FILLING);
		    Boolean allowModifications = (Boolean) action
			    .getParameterValue(PARAM_MODIFY);
		    Boolean allowAnnotationModification = (Boolean) action
			    .getParameterValue(PARAM_MODIFY_ANNOTATIONS);
		    Boolean allowPrinting = (Boolean) action
			    .getParameterValue(PARAM_PRINTING);
		    Boolean allowDegradedPrinting = (Boolean) action
			    .getParameterValue(PARAM_DEGRADED_PRINTING);
 
		    AccessPermission ap = new AccessPermission();
		    ap
			    .setCanAssembleDocument((allowAssembly != null && allowAssembly
				    .booleanValue()));
		    ap
			    .setCanExtractContent((allowExtraction != null && allowExtraction
				    .booleanValue()));
		    ap
			    .setCanExtractForAccessibility((allowExtractionAccessibility != null && allowExtractionAccessibility
				    .booleanValue()));
		    ap
			    .setCanFillInForm((allowFillingInForm != null && allowFillingInForm
				    .booleanValue()));
		    ap
			    .setCanModify((allowModifications != null && allowModifications
				    .booleanValue()));
		    ap
			    .setCanModifyAnnotations((allowAnnotationModification != null && allowAnnotationModification
				    .booleanValue()));
		    ap.setCanPrint((allowPrinting != null && allowPrinting
			    .booleanValue()));
		    ap
			    .setCanPrintDegraded((allowDegradedPrinting != null && allowDegradedPrinting
				    .booleanValue()));
 
		    StandardProtectionPolicy policy = new StandardProtectionPolicy(
			    (String) action
				    .getParameterValue(PARAM_OWNER_PASSWORD),
			    (String) action
				    .getParameterValue(PARAM_USER_PASSWORD), ap);
		    doc.protect(policy);
		    doc.save(fos);
		    fos.close();
		    doc.close();
 
		    ContentWriter writer = contentService.getWriter(
			    actionedUponNodeRef, ContentModel.PROP_CONTENT,
			    true);
		    writer.putContent(newPdf);
		} else {
		    doc.close();
		    throw new RuntimeException(
			    "This document is already encrypted");
		}
	    } catch (FileNotFoundException fnfe) {
		fnfe.printStackTrace();
	    } catch (BadSecurityHandlerException bshe) {
		bshe.printStackTrace();
	    } catch (COSVisitorException cosve) {
		cosve.printStackTrace();
	    } catch (IOException ioe) {
		ioe.printStackTrace();
	    }
	}
    }
 
    @Override
    protected void addParameterDefinitions(List paramList) {
	paramList.add(new ParameterDefinitionImpl(PARAM_OWNER_PASSWORD,
		DataTypeDefinition.TEXT, true,
		getParamDisplayLabel(PARAM_OWNER_PASSWORD)));
	paramList.add(new ParameterDefinitionImpl(PARAM_USER_PASSWORD,
		DataTypeDefinition.TEXT, true,
		getParamDisplayLabel(PARAM_USER_PASSWORD)));
	paramList.add(new ParameterDefinitionImpl(PARAM_ASSEMBLY,
		DataTypeDefinition.BOOLEAN, false,
		getParamDisplayLabel(PARAM_ASSEMBLY)));
	paramList.add(new ParameterDefinitionImpl(PARAM_EXTRACT_CONTENT,
		DataTypeDefinition.BOOLEAN, false,
		getParamDisplayLabel(PARAM_EXTRACT_CONTENT)));
	paramList.add(new ParameterDefinitionImpl(PARAM_EXTRACT_ACCESSIBILITY,
		DataTypeDefinition.BOOLEAN, false,
		getParamDisplayLabel(PARAM_EXTRACT_ACCESSIBILITY)));
	paramList.add(new ParameterDefinitionImpl(PARAM_FILLING,
		DataTypeDefinition.BOOLEAN, false,
		getParamDisplayLabel(PARAM_FILLING)));
	paramList.add(new ParameterDefinitionImpl(PARAM_MODIFY,
		DataTypeDefinition.BOOLEAN, false,
		getParamDisplayLabel(PARAM_MODIFY)));
	paramList.add(new ParameterDefinitionImpl(PARAM_MODIFY_ANNOTATIONS,
		DataTypeDefinition.BOOLEAN, false,
		getParamDisplayLabel(PARAM_MODIFY_ANNOTATIONS)));
	paramList.add(new ParameterDefinitionImpl(PARAM_PRINTING,
		DataTypeDefinition.BOOLEAN, false,
		getParamDisplayLabel(PARAM_PRINTING)));
	paramList.add(new ParameterDefinitionImpl(PARAM_DEGRADED_PRINTING,
		DataTypeDefinition.BOOLEAN, false,
		getParamDisplayLabel(PARAM_DEGRADED_PRINTING)));
    }
 
}

Module

Encore une fois, nous vous proposons ici l’action sous la forme d’un module Alfresco, les sources complètes étant disponibles ici.

Traduction française de la plate-forme

Atol CD a entièrement effectué la traduction de la plate-forme Pentaho 1.7 GA PCI (Pre-configured Installation).

L’ensemble des fichiers de traduction sont disponibles sur GoogleCode à cette adresse :
http://code.google.com/p/pentaho-french-translation

Un zip complet des fichiers traduits est téléchargeable dans l’onglet « Download ».

Merci à Sébastien, Nicolas et Bénédicte pour leur contribution…

Amélioration du rendu des Tableaux de bord

Depuis que nous mettons en place des dashboards et des rapports sur des projets BI avec Pentaho, nous avons souvent été frustrés par l’aspect graphique rudimentaire et « old school » proposé par JFree.

Bien heureusement, Pentaho est dans le domaine de l’Open Source, par définition on peut alors assez facilement se proposer d’enrichir l’outil.

C’est donc ce que nous avons décidé de faire en créant une nouvelle couche de restitution plus vivante et conviviale à l’aide d’un projet de rendu graphique Open Source: Open Flash Chart.

Voyons tout d’abord un exemple de tableau de bord réalisé nativement avec Pentaho (avec JFreeChart donc) :

Développement d’une couche de restitution web avec Open Flash Chart :

Puisque Pentaho est une plate-forme OSBI plutôt bien conçue, il est plutôt simple d’y ajouter un composant personnalisé (un « plugin » en quelque sorte…).

Ainsi, les graphiques OpenFlashChart que nous avons mis en place s’appellent de la même manière que les graphiques JFreeChart :

• Un fichier xaction pour ramener les données

• Un fichier xml pour décrire le graphique (le « widget »)

• Une page jsp pour l’affichage du graphique

Une nouvelle classe java « OpenFlashChartHelper » a été développée afin que les données fournies par l’xaction puissent être chargées dans les graphes en Flash.

Le code de la page JSP ressemble à ceci :

<%
	        SimpleParameterProvider parameters = new SimpleParameterProvider();
	        parameters.setParameter( "drill-url", "SibDashboardFlash?gir={gir}" );
	        parameters.setParameter( "inner-param", "gir");
	        parameters.setParameter( "image-width", "500");
        	        parameters.setParameter( "image-height", "350");
	        StringBuffer content = new StringBuffer();
	        ArrayList messages = new ArrayList();
	        OpenFlashChartHelper.doFlashChart( "samples", "formation",
 		"synthese_gir.widgetFlash.xml", parameters,
		content, userSession, messages, null, 1 );
%>
		<%= content.toString() %>

La seule chose qui change par rapport au code standard de Pentaho appelant JFreeChart est la méthode d’appel. Ainsi, l’objet et la méthode appelante est OpenFlashChartHelper.doFlashChart().

Les attributs de cette méthode sont les mêmes que pour le code de JfreeChart, à part qu’un nouvel attribut a été ajouté : il s’agit du numéro de graphe dans la page ( il est utilisé seulement pour différencier les appels à la bibliothèques Flash )

Le widget xml ressemble à ceci :

<chart> 
	 <data> 
		<data-solution>samples</data-solution> 
		<data-path>formation</data-path> 
		<data-action>synthese_gir_data.xaction</data-action> 
		<data-output>rule_result</data-output> 
		<data-name>gir</data-name> 
		<data-value>nb_patients</data-value> 
		<data-orientation>columns</data-orientation> 
	</data> 	 
	<!-- 1 ou 2 suivant la version de OFC utilisé --> 
	<OFC-render>1</OFC-render> 
	<width>500</width> 
	<height>400</height> 
	<title> 
		<text>Nombre de patients par code GIR</text> 
		<style>{font-size: 20px; color:#736AFF}</style> 
	</title> 
	<bg-colour>#C548D1</bg-colour> 
	<elements> 
		<element> <!-- autre exemple de pie chart --> 
			<type>pie</type> 
	  		<colours> 
				<colour>#d01f3c</colour> 
				<colour>#356aa0</colour> 
				<colour>#C79810</colour> 
				<colour>#65a111</colour> 
				<colour>#f121f1</colour> 
			</colours> 
			<alpha>50</alpha> 
			<border>2</border> 
			<animate>0</animate> 
			<start-angle>45</start-angle> 
			<tip>GIR=%23x_label%23&lt;br&gt;%23val%23</tip> 
			<gradient-fill>true</gradient-fill> 
			<label-colour>#0000d0</label-colour> 
			<dynamic-tips>0</dynamic-tips> 
			<dynamic-links>0</dynamic-links> 
		</element> 
	</elements> 
</chart>

Au final, le tableau de bord en Open Flash Chart ressemble à ça :

Comme souvent les vidéos sont plus parlantes que des copies d’écrans.

Voici donc celle du dashboard Pentaho natif (Jfree) :

Et celle avec le dahsboard Open Flash Chart made by atolcd :

Le cours était donné par la crème d’Alfresco : Michael « Uzi » Uzquiano (Director of WCM Products), soutenu par David « davidc » Caruana (Chief Architect) et Mike Farman (Director of ECM Products) ; et organisé par Nancy Garrity (Community Manager) en marge de la European Community Conference.

Architecture

Tout d’abord et contrairement à ce que je disais en mai dernier, Surf n’est pas une évolution des Web Scripts, mais une plate-forme de développement Web à part entière, qui tire parti des Web Scripts, mais pas uniquement (et pas même forcément). Au final, une application Surf reste globalement un ensemble de fichiers XML.

La plate-forme Surf est orientée page, composant et contenu, ce contenu pouvant provenir d’où bon vous semble : un entrepôt documentaire Alfresco bien entendu, mais là encore pas uniquement ni forcément (Alfresco Network par exemple est une application Surf qui n’utilise pas du tout Alfresco).

La notion de contenu ici est également particulière dans le sens où du contenu peut être fourni par les pages et les composants eux-même. Disons pour simplifier qu’un contenu provient d’une source de données externe à l’application. Oui oui, j’ai bien dit externe : une application Surf utilisant Alfresco –probablement le cas le plus courant– n’est pas tenue d’être déployée sur la même machine que l’entrepôt Alfresco, il y accède par des requêtes HTTP sur les Web Scripts mis à disposition et qui donnent accès à toutes les APIs disponibles en Java (ou presque), à savoir la gestion des utilisateurs, des catégories, des droits d’accès, des documents et espaces, etc. Et contrairement à ce qu’on pourrait croire, cette architecture a permis d’améliorer les performances de l’ensemble en forçant les développeurs à limiter le nombre de requêtes effectuées, et donc le nombre d’accès à la base de données et au file-system (et pour ceux qui testeraient l’application Share dans une Labs 3B, sachez que la version 3.0 Entreprise est quasi-identique en fonctionnalités mais avec de bien meilleures performances).

Les échanges avec les fournisseurs de contenus et/ou de services (endpoints) s’effectue au travers de connecteurs qui gèrent les interactions (HTTP, JDBC, SOAP, etc.) ainsi que le mode d’authentification (délégué à des authentifieurs). Des credential vaults s’occupent de gérer les différentes identités de l’utilisateur selon l’endpoint contacté, faisant office de Single-Sign On. Ainsi, même si ce n’est pas tout à fait opérationnel au moment où j’écris, Alfresco Network sert de point d’entrée unique, à authentification unique, pour les différentes applications d’Alfresco : forums, JIRA, support technique, wiki, etc.

Fonctionnement

Basiquement, dans Surf, une URL identifie une page, un type de page ou un contenu. Un type de page se résoud en une page selon le theme courant (par exemple, une page d’édition du profil utilisateur pourra être différente selon que l’utilisateur est un employé, un fournisseur ou un client). De même, un contenu se résoud en une page selon son type et les content associations (pour un contenu Alfresco, son type Alfresco : cm:content, cm:folder, etc. ce qui fait tout de suite penser au mécanisme de dispatch déjà présent dans le client JSF).

Nous avons donc une page. Celle-ci indique un niveau d’authentification requis (même principe que pour les Web Scripts) et référence un template instance. Ce template instance se contente la plupart du temps de donner le nom d’un template FreeMarker, dans lequel des directives particulières pourront être utilisées pour définir des régions dans lesquels viendront se loger les composants. Le rôle d’un template instance et de son template est de définir une présentation globale de la page (layout) et d’assembler des composants.

Chaque région est nommée et a une portée (globale, template instance ou page). C’est grâce à ces deux propriétés, complétées le cas échéant du nom du template instance ou de la page, que sont définis les component bindings, à savoir la configuration déterminant quel composant viendra se loger dans chaque région.

Le composant est la pièce maîtresse d’une application Surf, et correspond la plupart du temps simplement à un Web Script. L’API disponible pour ces Web Scripts est bien évidemment différente de celle des Web Scripts côté entrepôt Alfresco, et pour une fois est unifiée entre JavaScript et FreeMarker (et même Java d’ailleurs ; on parlera donc plutôt d’API Surf).

Enfin, il faut ajouter à cela les associations de pages qui permettent de définir de façon centralisée les liens entre les différentes pages de l’application (on construira donc les menus de navigation et autres « plan du site » de façon dynamique à partir de ces informations), les composants de chrome qui peuvent s’intercaler entre le template et le composant pour générer du code HTML complémentaire, à des fins de mise en forme principalement (dans un esprit de « thème graphique » donc), et les éléments de configuration, définissables à différents niveaux (global, composant, Web Script) et accessible par l’API Surf.

Tout ceci sans oublier les fonctionnalités nouvelles ou améliorées de dispatch sur URL (avec placeholders accessibles par l’API Surf, contrairement aux Web Scripts 2.1/2.2), internationalisation / régionalisation (I18N / L10N), négociation de contenu (voire de langue), le JavaScript d’un Web Script peut être différent selon le type de données envoyé par le client (pour les requêtes POST et PUT) avec en sus accès direct à ces données, éventuellement pré-parsées (cas de JSON ou XML par exemple), etc. et la possibilité de remplacer chaque composante du système : créateur de liens, page mapper, fabrique d’utilisateurs, etc.

Ah, j’oubliais encore : une application Surf étant un ensemble de fichiers XML, ils peuvent également être stockés dans un Alfresco, et plus particulièrement dans les AVM de WCM. Et Alfresco nous prépare un « studio » d’édition de sites WCM « à la volée » pour la version 3.1, ça promet !

Le mot de la fin

Et pour résumer tout ça, disons tout simplement que Surf est la brique qui nous manquait pour faciliter le développement d’applications métier gérant des documents : parapheur électronique, gestion de courrier, etc.