vendredi 26 août 2011

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 :




lundi 22 août 2011

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"