Services de transfert et réplication

Les services de Transfert et de réplication sont apparus respectivement en version 3.3 et 3.4 d'Alfresco. Ces services ont pour but l'envoi et la réception d'information d'un repository Alfresco à un autre. Cet article est un résumé des fonctionnalités offertes par ces deux services.

1. Transfer Service

Tout d'abord, quelques généralités sur le Transfer Service, apparu en version 3.3. Il Permet de pousser des noeuds d'un repository à un autre. Sans rentrer dans les détails d'implémentation, les propriétés des noeuds transférées sont envoyées séparément des contenus binaires associés à ces noeuds, ces derniers étant groupés pour minimiser les aller/retours entre les entrepôts.

Un cas d'utilisation classique : une entreprise dont le siège transfère des portions d'arborescence a des entrepôts Alfresco situés dans des filiales géographiquement distantes, pour leur fournir un accès localisé et donc plus rapide aux contenus les concernant. Quelques points à noter sur ce service :

• Les transferts peuvent utiliser HTTP ou HTTPS
• sur le repository cible, les noeuds de destination sont "enrichis" par des aspects (ex trx:transferred) afin de conserver la provenance des noeuds transferés
• Les transferts donnent lieu à l'écriture de rapports XML sur la source et sur la cible, faisant état du statut du transfert, ainsi que référençant, entre autre, les différents noeuds transferés
• Transferts synchrones ou asynchrones
• Attention : le transfert doit se faire à modèle de données équivalent : on ne peut transférer des noeuds possédant par exemple un aspect qui n'est pas défini sur le repository cible
• Permet le transfert chainé. Voir graphique ci-dessous :

Un transfert donné nécessite la définition de :

• transfer targets (nodes possédant des métadonnées décrivant les identifiants de connexion, l'url , le port, ... du repository de destination). La création de celles-ci se fait en créant un folder dans le dossier "Transferts/Groupes de cibles de transfert/Groupe par défaut" du Dictionnaire de données

• transfer definitions ( les nodes qui doivent être transférés). Le transfer service ne possède pas d'UI pour sélectionner des nodes, mais une API assez riche permettant de sélectionner/filtrer des nodes en fonction de différents critères (voir les interfaces NodeCrawler, NodeFilter, NodeFinder). Le replication service (voir ci-dessous) possède quant à lui une UI associée.

2. Replication Service

Ce service est apparu en version 3.4. Il s'appuie sur le transfer service décrit ci-dessus. Quelques points à noter sur ce service :

• S'ajoute aux cibles (ou ?) et définition de transfert (quoi ?), les "travaux de réplication (replication jobs) (quand ?). Ceux-ci permettent de définir un planning de réplication (ou bien de les déclencher à la demande). Un suivi graphique des travaux, ainsi que des rapports en fin de job sont également disponibles.
• Une page de la console d'administration permet de gérer, programmer, déclencher et suivre, et annuler ces jobs. Celle-ci s'appuie sur l'API ReST exposée par le replication service. Celle-ci est implémentée par des Web Scripts écrits en Java.

• A noter : les noeuds transférés sont par défaut en lecture seule, car il n'y a pas de synchronisation bidirectionnelle. Le mode lecture seule ou non est toutefois configurable dans les propriétés du subsystem de Replication (propriété replication.transfer.readonly).

3. A venir

Diverses améliorations sur ces services sont envisagées. Voir les liens ci-dessous pour les évolutions. La prochaine version d'Alfresco, prévue pour la fin de l'année, devrait notamment permettre de transférer du contenu vers un filesystem physique, plutôt qu'exclusivement vers

d'autres entrepôts Alfresco.

4. Liens

Pour plus de détails sur ces deux services, consultez les pages wiki suivantes :

• http://wiki.alfresco.com/wiki/Transfer_Service
• http://wiki.alfresco.com/wiki/Replication_Service
• http://wiki.alfresco.com/wiki/Replication_REST_API

Tutoriel Dashlet spécifique People Statuses (1/3)

Cet article constitue le premier élément d'une série de quelques tutoriaux sur le développement spécifique sous l'interface Alfresco Share.

Nous avions déjà abordé, sur ce blog, les fondamentaux à travers la conception de dashlets très simplistes "Hello World".
Ici, il s'agit d'aller une étape plus loin, en créant un "vrai" nouveau dashlet un peu plus utile qu'un simple "Hello World". L'objectif est de créer un dashlet qui affiche la liste des statuts des utilisateurs.

Pourquoi ce tutorial ?

Je sais qu’il peut être difficile de se lancer dans le développement spécifique sur l’interface Share, ce fut d’ailleurs mon cas. En effet, les premières barrières que j’ai rencontrées sont :
1/ Les patterns de conception : j’avais plutôt une bonne expérience du développement de webscripts Alfresco, mais j’avais du mal avec leur implémentation dans l’interface Share
2/ Le développement sous YUI

Ainsi, ce tutorial vise simplement à vous permettre de mettre un pied dans le développement spécifique Share. Bien sûr, si vous ne maitrisez aucunement YUI (ce qui était mon cas), ce sera toujours un peu difficile, il faudra lourdement s’appuyer sur la doc officielle, et procéder à tâtons. Néanmoins, vous allez voir que le degré de complexité du développement de ce dashlet spécifique est vraiment minimal …

Le tutoriel en lui-même figure dans le fichier PDF attaché, et le code source dans l'archive zip.

N'hésitez pas à nous faire des retours sur le contenu de l'article, ou sur le code source lui-même !


Ressources :

Pour accéder directement au document, c'est ici :
Voir le document dans Google docs

Pour accèder au code source:
Voir le code source dans Google docs

Notez que vous pouvez télécharger le document PDF et le code source dans Google docs en cliquant sur le menu "Fichier", puis "Télécharger l'original"

Catégories et Tags

S’il est un besoin inhérent à toute mise en place d’un projet GED / ECM, c’est bien la classification des différents contenus (documents, répertoires, discussions, etc …).
Alfresco propose différents outils de « classification » :
- Le plan de classement
- Les métadonnées
- Les catégories
- Les tags

Le plan de classement et les métadonnées sont des concepts plutôt bien connus.

Le premier désigne l’arborescence de dossiers et sous-dossiers dans laquelle on peut archiver les contenus, permettant une navigation que l’on pourrait qualifier de « hiérarchique » ou « verticale ». C’est la navigation intuitive à laquelle on est habitué lorsqu’on utilise un ordinateur personnel, recherchant et déplaçant les fichiers entre les différents répertoires.

Les métadonnées sont parfois décrites comme une « fiche d’informations » d’un contenu. Elles sont en effet un ensemble d’informations décrivant un contenu, comme « l’auteur », la « date de modification », ou encore le « statut ».

Cependant, les concepts de catégories et de tags sont parfois moins bien compris.
Certes, dans les deux cas, il s’agit de la possibilité d’accoler une ou plusieurs « étiquettes » (ou encore « mots-clés ») à un objet (document, espace, feuille wiki, réponse à une discussion, etc …). En outre, tags et catégories permettent aux utilisateurs de naviguer au sein de l’entrepôt de manière « sémantique ».

Les catégories

Les catégories forment un vocabulaire hiérarchique de mots-clés, et défini par un administrateur fonctionnel. Elles permettent de classifier les contenus selon une taxinomie. Elles sont très utilisées notamment dans les projets d’archivage ou de « gestion de documents référentiels ».
Dans Alfresco, un contenu peut « recevoir » une ou plusieurs catégories (s’il dispose de l’aspect « Catégorisable »). Enfin, un filtre de navigation « Catégories » permet d’afficher les contenus étiquetés avec la catégorie sélectionnée.















Les tags

A l’inverse des catégories, les tags sont des mots-clés non-organisés, qui sont librement créés par les utilisateurs finaux. Les tags permettent de classifier les contenus selon une folksonomie.
Les tags sont régulièrement mis en oeuvre dans les projets collaboratifs, et les projets de capitalisation de connaissance (KM).
En effet, les tags ont l’avantage de recueillir un investissement important des utilisateurs, ceux-ci ressentant parfois une certaine frustration face au système plus rigide des catégories figées.

Dans Alfresco, tout contenu peut « recevoir » un ou plusieurs tags, déjà existants dans l’application, ou nouvellement créés à la saisie. Enfin, un filtre de navigation « Tags » permet d’afficher les contenus étiquetés avec le tag sélectionné.

On remarque également qu’une sorte de « loi darwinienne » s’applique dans l’affichage des tags dans cette entrée de navigation. En effet, les tags sont triés par ordre d’utilisation (le nombre entre parenthèses indique d’ailleurs le nombre de contenus associés au tag).
Cet ordonnancement naturel permet de pallier naturellement à l’éventuel problème de profusion de tags obscurs, mal orthographiés, ou encore inutiles.














Si vous avez des retours sur cet article, n'hésitez pas à nous en faire part !

Espace racine des protocoles FTP, CIFS ...

Vous savez sans doute déjà que l’entrepôt Alfresco est accessible par différents protocoles, notamment FTP, CIFS, NFS …

Mais savez-vous qu’il est possible de n’exposer qu’une partie de votre entrepôt via ces interfaces d’accès ?

Pour cela, il vous faut surcharger la configuration par défaut du subsystem File Servers.

Qu’est ce qu’un subsystem ? Réponse ici.

Comment configurer un subsystem ? Réponse là.

Quelques infos supplémentaires sur le FileServer Subsystem ? Voici la page wiki dédiée.

En l’occurrence, dans le cas décrit ici, il faudra adopter la 3^ème méthode de configuration du subsystem, puisque l’on va devoir modifier la définition d’un bean Spring appelé « filesystemsContext ».

En effet, il suffit de modifier la valeur de la propriété "rootPath", comme suit :

<property name="rootPath">

<!-- <value>/${spaces.company_home.childname}</value> -->

<value>/app:company_home/st:sites</value>

</property>

Dans cet exemple, nous décidons de configurer la racine des accès des interfaces de type « File Server » comme « Accueil / Sites ». Ainsi, tout utilisateur se connectant en FTP, CIFS ou NFS à l’entrepôt ne pourra voir que la liste des sites collaboratifs.

Enfin, sachez qu’en observant de près les 2 fichiers de configuration du subsystem FileServers, vous découvrirez sans doute d’autre astuces de configuration (changer le nom de l’espace racine, modifier uniquement le répertoire racine pour FTP, …)