La Bible du développeur Alfresco : guide du développeur Alfresco (1re édition)

| Landry KOUAM (Centre de Compétences Alfresco-jBPM, KOOSSERY TECHNOLOGY) | Baké Jc. BAKENEGHE  (Software Coordinator, KOOSSERY TECHNOLOGY) |

La plateforme java ecm Alfresco est un standard pour adresser les projets ged/ecm/workflow (gestion électronique de document, gestion de contenus, workflows avancés).
Ce guide s'adresse à tous les développeurs Java qui désirent acquérir des compétences en développement AlfrescojBPM.
Les développeurs AlfrescojBPM pourront l'utiliser pour confirmer ou approfondir leurs connaissances.

Note importante: il s'agit d'un guide itératif sur plusieurs éditions. Par conséquent il se peut que certaines parties de l'édition actuelle ne soient pas encore traitées: elles le seront à l'occasion des éditions suivantes.

Dans le cadre des projets GED/Workflow/BPM que lui confient ses clients, Koossery Technology s'appuie sur les standards suivants :
- Alfresco pour ce qui concerne l'implémentation de la GED/ECM ;
- jBoss BPM pour ce qui concerne l'implémentation des workflows BPM ;
- jBoss BPEL pour ce qui concerne l'orchestration de processus ;
- et enfin l'ESB Mule ESB pour l'intégration de processus hétérogènes. Le Centre de Compétences AlfrescojBPM de Koossery Technology publie à travers ce guide la « Bible » du développeur Java Alfresco.
Ce guide va être utile à tous les développeurs Java qui désirent acquérir des compétences en développement AlfrescojBPM.
Les développeurs AlfrescojBPM pourront l'utiliser pour confirmer ou approfondir leurs connaissances.

- Titre : La Bible du développeur Alfresco : guide du développeur Alfresco (1re édition)

- Auteurs : Landry KOUAM (Centre de Compétences Alfresco-jBPM, KOOSSERY TECHNOLOGY), Baké Jc. BAKENEGHE  (Software Coordinator, KOOSSERY TECHNOLOGY)

- Parution : 26 mai 2009

- Mise à jour : 20 février 2020

- Licence :

Sommaire

- I. INTRODUCTION

- II. LES BASES TECHNIQUES GÉNÉRALES DU JCR (JAVA CONTENT REPOSITORY)

- II-A. Entity Model JCR: spécifications JSR-170

- II-B. Exercices simples de manipulation de contenu à l'aide de l'implémentation JCR Apache-Jackrabbit

- II-B-1. Projet DAO simple basée sur Jackrabbit

- II-B-2. Projet DAO avancée basée sur Jackrabbit

- II-B-3. Approfondissement de Jackrabbit

- II-C. Exercices simples de manipulation de contenu à l'aide de l'implémentation JCR Alfresco

- II-C-1. Overview du modèle de données sur lequel s'appuie Alfresco

- II-C-2. Mise sur pied de l'environnement de développement SDK-Alfresco

- II-C-3. Exercice simple de manipulation du JCR Model d'Alfresco

- III. LES MODÈLES DE CONTENU DE L'ECM ALFRESCO

- III-A. Les modèles

- III-A-1. Version Model

- III-A-2. Rule Model

- III-A-3. User Model

- III-A-4. Action Model

- III-A-5. Transformation component Model

- III-A-6. Alfresco Security Model

- III-A-7. Alfresco Audit Management Model

- III-B. Le dictionnaire de données et son extension

- IV. L'ARCHITECTURE TECHNIQUE GÉNÉRALE DU FRAMEWORK ALFRESCO

- IV-A. Overview de l'architecture technique

- V. LE BACK-END ALFRESCO: LES SERVICES OFFERTS PAR LA PARTIE SERVER DU REPOSITORY

- V-A. NodeService

- V-B. ContentStoreService

- V-C. ContentService

- V-D. FileFolderService

- V-E. DictionnaryService

- V-F. NamespaceService

- V-G. VersionService

- V-H. VersionHistoryService

- V-I. NodeArchiveService

- V-J. SearchService

- V-K. ADMSearchService

- V-L. LockService

- V-M. LuceneCategoryService

- V-N. AuditService

- V-O. ActionService

- V-P. AttributService

- V-Q. ScriptService

- V-R. RuleService

- V-S. AuthenticationService

- V-T. PermissionService

- V-U. AuthorityService

- V-V. PersonService

- V-W. CategoryService

- V-X. UsageService

- V-Y. CheckOutCheckinService

- V-Z. MimeTypeService

- V-AA. MimeTypeConfigService

- V-AB. MessageService

- V-AC. ContentFilterLanguagesService

- V-AD. WorkflowService

- V-AE. ImporterService

- V-AF. MultilingualContentService

- V-AG. EditionService

- V-AH. AdminService

- V-AI. OwnableService

- V-AJ. CopyService

- V-AK. AVMService

- V-AL. ExporterService

- V-AM. Template Service

- V-AN. TransactionService

- V-AO. DeploymentService

- V-AP. EmailService

- V-AQ. ModuleService

- V-AR. DescriptorService

- V-AS. TenantService

- V-AT. ServiceRegistry

- VI. LA GESTION DES EXCEPTIONS DANS ALFRESCO

- VI-A. Alfresco Exception Management Model

- VII. LES WORKFLOW DANS ALFRESCO

- VII-A. Workflows simples

- VII-B. Workflows avancés

- VII-B-1. jBPM : syllabus simple

- VII-B-2. jBPM : syllabus avancé

- VII-C. Le Framework des Workflows Alfresco

- VIII. LES FRAMEWORKS DU BACK-END ALFRESCO

- VIII-A. Les Actions Alfresco

- VIII-A-1. Notions d'Action Alfresco

- VIII-A-2. Exercice simple de développement d'Action Alfresco

- VIII-B. Les Aspects Alfresco

- VIII-B-1. Notions sur les Aspects Alfresco

- VIII-B-2. Exercice simple de déveppement d'Aspect Alfresco

- VIII-C. Sources et Auditeur

- VIII-C-1. Notions

- VIII-C-2. Exercice simple de développement d'auditeur d'évènement Alfresco

- IX. CONFIGURATIONS DU REPOSITORY

- X. FRONT-END WEB D'ALFRESCO: DÉVELOPPEMENTS JSF

- X-A. Généralités sur le Front-end JSF Alfresco

- X-B. Les principaux beans managés du Front-End

- X-B-1. LoginBean

- X-B-2. BrowseBean

- X-B-3. NavigationBean

- X-B-4. WorkflowBean

- X-B-5. FileUploadBean

- X-B-6. BaseActionWizard

- X-B-7. RunActionWizard

- X-B-8. BaseActionHandler

- X-B-9. ScriptHandler

- X-B-10. BaseContentWizard

- X-B-11. CreateContentWizard

- X-B-12. EditContentWizard

- X-B-13. DashboardWizard

- X-B-14. BaseDialogBean

- X-B-15. FileUploadBean

- X-B-16. SidebarBean

- X-B-17. BaseContentWizard

- X-B-18. CreateContentWizard

- X-B-19. EditContentWizard

- X-B-20. DashboardWizard

- X-B-21. ForumsBean

- X-B-22. AddUserDialog

- X-B-23. CreateGroupDialog

- X-B-24. CreateRoleWizard

- X-B-25. CreateSpaceWizard

- X-B-26. CreateSpaceDialog

- X-B-27. TrashcanDialog

- X-B-28. ContentUsersBean

- X-B-29. CreateUserWizard

- X-B-30. UserConsoleDialog

- X-B-31. UserDialog

- X-B-32. NewUserWizard

- X-B-33. BaseWizardBean

- X-B-34. ManageTaskDialog

- X-B-35. WorkflowBean

- X-B-36. WorkflowConsoleBean

- X-B-37. StartWorkflowWizard

- X-C. Les Frameworks du FE

- X-C-1. Les Dialogs Alfresco

- X-C-2. Les Wizards Alfresco

- X-D. Les API Webscript et JavaScript

- X-D-1. Alfresco : Web Scripts

- X-D-2. Alfresco : JavaScripts

- X-E. Extension du Front-End Alfresco

- XI. EXPOSITION DE SERVICES: LES MIDDLEWARE D'ALFRESCO

- XI-A. Alfresco Web Services

- XI-B. Alfresco RMI

- XII. PAQUETAGE ET DÉPLOIEMENT DES EXTENSIONS AVEC LES OUTILS D'ALFRESCO

- XIII. LES PROTOCOLES D'ACCÈS

- XIII-A. CLUSTER

- XIII-B. CIFS

- XIII-C. FTP

- XIV. REMERCIEMENTS ET COMMENTAIRES

I - INTRODUCTION

Le présent guide est issu du résultat d'un profond travail effectué par le Centre de Compétences AlfrescojBPM de Koossery Technology.
C'est un guide utile pour tout développeur Java qui voudrait acquérir (ou approfondir) des compétences en développement java ecm/ged/workflow sur la base de la plateforme AlfrescojBPM.
Il présente un ensemble de tâches, d'exercices et de tutoriels à absolument faire de façon progressive.

Dans la partie II, nous abordons les bases techniques générales du JCR (Java Content Repository)
Dans la partie III nous abordons les modèles de contenu de l'ECM Alfresco.
Dans la partie IV nous abordons l'architecture technique générale du framework Alfresco.
Dans la partie V nous abordons les services offerts par la partie Server du repository Alfresco.
Dans la partie VI nous abordons la gestion des exceptions dans Alfresco.
Dans la partie VII nous abordons le développement des workflows (simples et avancés).
Dans la partie VIII nous abordons les frameworks du repository Alfresco.
Dans la partie IX nous abordons les configurations du repository Alfresco.
Dans la partie X nous abordons les développements front-end web (JSF) d'Alfresco.
Dans la partie XI nous abordons les modes d'exposition des services d'Alfresco (les middleware d'Alfresco).
Dans la partie XII nous abordons le paquetage et déploiement des extensions avec les outils d'Alfresco.
Dans la partie XIII nous abordons les protocoles d'accès.

II - LES BASES TECHNIQUES GÉNÉRALES DU JCR (JAVA CONTENT REPOSITORY)

Le Centre de Compétences AlfrescojBPM de Koossery Technology préconise de commencer par avoir de bonnes bases sur le JCR (Java Content Repository).

II-A - Entity Model JCR: spécifications JSR-170

Dans les projets Java classiques qui manipulent les données, le stockage se fait en général dans une base de données relationnelle. L'accès à cette base se fait en général via une couche DAO basée sur un mapper O/R ou ORM (iBatis ou Hibernate par exemple).

Lorsqu'on manipule des documents ou du contenu, les bases de données relationnelles ne sont plus adaptées, car elles ne présentent pas de fonctionnalités poussées pour ce qui concerne le versionning, la recherche full-text, la catégorisation et classification du contenu, le contrôle d'accès au contenu, etc.
Pour pallier cette non-adaptation des sgbr, la norme JSR-170 apporte un ensemble de spécifications pour le stockage et la manipulation du contenu (JCR=Java Content Repository).

La norme JSR-170 est implémentée par certains outils open source notamment Apache Jackrabbit. Alfresco implémente aussi la norme JSR170.

Pour avoir un bon overview sur le JCR et la norme JSR-170, le Centre de Compétences AlfrescojBPM de Koossery Technology recommande de lire tour à tour les documents ci-dessous :

1

http://www.artima.com/lejava/articles/contentrepositoryP.html

lire les premiers paragraphes jusqu'au paragraphe « blogging with jackrabbit » exclu.

2

http://www.onjava.com/pub/a/onjava/2006/10/04/what-is-java-content-repository.html

lire la page 1: très bon overview sur le JCR !

3

http://www.ibm.com/developerworks/java/library/j-jcr/

II-B - Exercices simples de manipulation de contenu à l'aide de l'implémentation JCR Apache-Jackrabbit

Dans un projet Java, la couche DAO est la couche d'accès aux données.
Dans notre cas nous manipulons le contenu.

II-B-1 - Projet DAO simple basée sur Jackrabbit

Ici il s'agit de s'entraîner à écrire une petite DAO implémentée à base de Apache Jackrabbit pour manipuler le contenu. Le but de cet exercice est d'apprendre à manipuler les concepts vus au paragraphe II-1.
Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande de lire, comprendre et refaire soi-même les deux petits exercices exposés dans les documents ci-dessous :

1

http://www.onjava.com/pub/a/onjava/2006/10/04/what-is-java-content-repository.html

Très bon petit exercice d'une DAO Jackrabbit simple sur les pages 2 et 3 !

2

http://www.artima.com/lejava/articles/contentrepositoryP.html

II-B-2 - Projet DAO avancée basée sur Jackrabbit

Dans la suite de l'exercice de manipulation de contenu du paragraphe , il s'agit ici d'aller plus loin en s'entraînant à écrire une DAO basée sur Apache Jackrabbit en maniant les concepts avancés : introduction du versionning, utilisation des modèles de données, indexage, recherche textuelle, upload de fichier.

Le Centre de Compétences AlfrescojBPM de Koossery Technology pense que cet exercice est optionnel: nous fournirons dans une prochaine version de ce guide un zip avec un exemple de code.
Le développeur peut néanmoins faire l'exercice de la documentation ci-dessous :

1

http://www.onjava.com/pub/a/onjava/2006/10/04/what-is-java-content-repository.html

approfondir avec l'exemple de search (XPath) et l'upload de la page 4

II-B-3 - Approfondissement de Jackrabbit

Si vous voulez approfondir vos connaissances sur l'implémentation JCR Jackrabbit il faut aller sur le site Apache :

1

http://jackrabbit.apache.org

Le Centre de Compétences AlfrescojBPM de Koossery Technology pense que cet approfondissement n'est pas déterminant pour entrer dans Alfresco.

II-C - Exercices simples de manipulation de contenu à l'aide de l'implémentation JCR Alfresco

II-C-1 - Overview du modèle de données sur lequel s'appuie Alfresco

Lorsqu'on doit stocker des données dans une base de données relationnelle, on prend d'abord la peine de modéliser ces données en utilisant les concepts relatifs aux sgbdr : tables, attributs, jointures, etc.

Pour ce qui concerne un projet de gestion de contenu basé sur Alfresco, le développeur Java doit d'abord prendre la peine de modéliser le contenu manipulé en utilisant les concepts de modèles de données relatifs à Alfresco.

Le but dans ce paragraphe est d'avoir de bonnes bases sur le modèle de données sur lequel Alfresco s'appuie pour organiser le contenu.

Les principaux concepts dont :
- le dictionnary data model et les notions de modèles M1 et M2 ;
- les principaux modèles M1 : dictionaryModel, contentModel, systemModel, applicationModel.

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande de lire la documentation suivante :

1

http://wiki.alfresco.com/wiki/Data_Dictionary_Guide

II-C-2 - Mise sur pied de l'environnement de développement SDK-Alfresco

Pour pouvoir développer en utilisant le Framework Alfresco, le plus pratique est de le faire dans un environnement SDK Alfresco. Cet environnement est pré configuré avec toutes les librairies du noyau Alfresco. En tant que développeur Alfresco, vous devez monter cet environnement sur votre poste.

Pour mettre en place son environnement de développement Alfresco (SDK-Alfresco), le Centre de Compétences AlfrescojBPM de Koossery Technology recommande de s'inspirer du document suivant :

1

http://wiki.alfresco.com/wiki/Alfresco_SDK

II-C-3 - Exercice simple de manipulation du JCR Model d'Alfresco

Après avoir installé son environnement de développement (voir ), le développeur doit lire, comprendre et s'exercer sur projet « JCRSamples » du SDK Alfresco.
Pour cela, s'aider de la documentation ci-dessous :

1

http://wiki.alfresco.com/wiki/Introducing_the_Alfresco_Java_Content_Repository_API

Le Centre de Compétences AlfrescojBPM de Koossery Technology pense que cet exercice est utile. Nous fournirons dans une prochaine version de ce guide un zip avec d'autres exemples de code.

III - LES MODÈLES DE CONTENU DE L'ECM ALFRESCO

Il est question dans ce chapitre de maîtriser les différents modèles M1 d'Alfresco et leurs implémentations. Nous présenterons aussi le dictionnaire de données et son extension.

III-A - Les modèles

L'implémentation du JCR Alfresco manipule plusieurs modèles M1.

III-A-1 - Version Model

C'est le modèle sur lequel reposent la gestion des versions des documents du JCR Alfresco et son implémentation.
Ce modèle est décrit à travers le fichier « versionstoreModel.xml ».

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande non seulement la maîtrise du modèle versionstoreModel.xml, mais aussi pour une prise main du mécanisme des versions, la maîtrise des services VersionService (voir ) et VersionHistory(voir ) du package org.alfresco.service.cmr.version.

Lire la documentation ci-dessous :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

III-A-2 - Rule Model

C'est le modèle sur lequel repose l'implémentation des rules Alfresco (Règles de gestion).
Ce modèle est décrit à travers le fichier « ruleModel.xml ».

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande non seulement la maîtrise du modèle ruleModel.xml, mais aussi pour une prise main du mécanisme des règles de gestion, la maîtrise du service RuleService (voir ) du package org.alfresco.service.cmr.rule.

Lire la documentation ci-dessous :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

III-A-3 - User Model

C'est le modèle lié à la gestion des utilisateurs et son implémentation dans le noyau.
Ce modèle est décrit à travers l'entité cm:person du modèle contentModel.xml.

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande non seulement la maîtrise de l'entité cm:person du modèle contentModel.xml, mais aussi pour une prise main du mécanisme de gestion des utilisateurs, la maîtrise des API du package org.alfresco.repo.security.person et org.alfresco.repo.security.authority.

Lire la documentation ci-dessous :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

III-A-4 - Action Model

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

III-A-5 - Transformation component Model

Il s'agit de maîtriser l'implémentation des composants du noyau qui permettent la prise en compte de l'intégration des moteurs de transformation de format de fichiers.
Le développeur Alfresco doit :
- savoir comment intégrer un nouveau moteur de transformation de format de fichiers (nous fournirons dans une prochaine version de ce guide un zip avec un exemple de code) ;
- savoir comment développer un composant permettant de plugger un moteur de transformation ;
- maîtriser les services fondamentaux du noyau permettant de réaliser la transformation des documents.

Lire la documentation ci-dessous :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

III-A-6 - Alfresco Security Model

Il est question de maîtriser comment est implémenté la sécurité dans Alfresco. Ce master inclut le master de la gestion des rôles (ACL), la sécurisation des objets, l'utilisation des annuaires stockant les éléments de sécurité, la gestion des droits, les mécanismes d'authentification et d'autorisation, etc.
Le modèle de sécurité est décrit à travers le fichier securityModel.xml.

Le développeur Alfresco doit :
- savoir intégrer un annuaire du type LDAP pour la gestion des accès ;
- savoir intégrer le SSO avec NTLM ;
- savoir customiser le module de gestion des rôles et ACL ;
- savoir customiser le module de gestion des rôles et ACL.

Lire la documentation ci-dessous :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

III-A-7 - Alfresco Audit Management Model

Le but est de maîtriser l'implémentation de l'audit dans Alfresco. Des composants (interceptors) ont cette responsabilité.

Lire la documentation ci-dessous :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

III-B - Le dictionnaire de données et son extension

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

IV - L'ARCHITECTURE TECHNIQUE GÉNÉRALE DU FRAMEWORK ALFRESCO

IV-A - Overview de l'architecture technique

Alfresco est un framework open source permettant de développer des applications de gestion de contenu.
Alfresco est en architecture J2ee avec un web-tiers (JSF) et un Business-Tiers composé de services.

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande de lire la documentation ci-dessous :

1

http://wiki.alfresco.com/wiki/Alfresco_Repository_Architecture

V - LE BACK-END ALFRESCO: LES SERVICES OFFERTS PAR LA PARTIE SERVER DU REPOSITORY

Le JCR Alfresco fournit un ensemble de services simples permettant de manipuler un Repository JSR-170.
L'utilisation de ces services primitifs est assez complexe. Pour pallier ce problème, une couche de services de haut niveau encapsule toutes ces complexités. Cette couche est appelée dans le jargon d'Alfresco : Repository Foundation Services. Ces services sont spécialisés c'est-à-dire que pour chaque domaine fonctionnel de l'ECM (gestion des nœuds, gestion des versions, gestion des catégories, etc.) un service de haut niveau est dédié.
Le développeur Alfresco doit maîtriser les services du Repository Foundation Services ainsi que leurs API.

V-A - NodeService

@Package : org.alfresco.service.cmr.repository

Le Node Service permet par exemple d'effectuer les opérations suivantes :

o Obtenir la racine de l'arborescence des nodes d'un Workspace donné :

Obtenir la racine de l'arborescence des nodes d'un Workspace donné:

nodeService.getRootNode(companyHomeStore);

Cette instruction permet de rechercher et retourner une référence au node racine du Workspace contenant le node référencé par companyHomeStore (NodeRef).

o D'obtenir une propriété d'un contenu représenté par un node :

obtenir une propriété d'un contenu représenté par un node:

(NodeRef)nodeService.getProperty(person,ContentModel.PROP_HOMEFOLDER);

Cette instruction permet de retourner la propriété du node référencé par person (NodeRef) et qualifié par le QName ContentModel.PROP_HOMEFOLDER. Notons que les propriétés définies dans les modèles de données sont qualifiées par des QNames.

o Vérifier si un contenu associé à une URL existe dans le repository :

Vérifier si un contenu associé à une URL existe dans le repository:

nodeService.exists(urlRef);

Cette instruction permet de vérifier si l'URL « urlRef » est associée à un contenu dans le repository.

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous :

1

http://wiki.alfresco.com/wiki/Node_Service_API_Design

V-B - ContentStoreService

@Package: org.alfresco.repo.content

Alfresco stocke les contenus binaires sur le File System à travers un composant qui fournit les services de lecture et écriture: ContentStoreService
ContentStoreService permet d'obtenir des flux d'écriture et de lecture des contenus dans le référentiel en utilisant des URL.

ContentStoreService est un service interne, c'est-à-dire utilisé par d'autres services (Content Service par exemple) pour lire et écrire les contenus sur le système de stockage.
Alfresco range les fichiers binaires des contenus sur le système de fichiers. Tous les fichiers binaires sont conservés dans le référentiel, dans un répertoire racine nommé contentstore. Les fichiers sont rangés par année, mois, jour, heure et minute, c'est-à-dire que, à la racine de contentstore, un sous-dossier pour l'année en cours (exemple : 2008) est créé par le JCR.
Ce dossier contient des sous-dossiers de mois, de jours, ainsi de suite jusqu'à la minute. Ainsi lorsque le JCR veut sauvegarder un fichier binaire, il crée cette sous-arborescence jusqu'à la minute de création du document.

ContentStoreService est implémenté par la classe abstraite AbstractContentStore qui est la classe de base fournissant le support pour divers type de stockage de contenu.
AbstractContentStore est étendue par une implémentation du stockage de contenu dans le système de fichier : FileContentStore. FileContentStore fournit une implémentation du stockage des nodes directement dans le système de fichier (le repository).
FileContentStore utilise un contexte dans lequel toutes les informations pour le stockage, le traitement des mimetypes, etc. sont conservées et rendues accessibles via des URL de la forme store ://year/month/day/hour/minute/GUID.bin (nous en parlons dans le paragraphe ci-dessous). Les noms des fichiers doivent obéir à la convention de nommage des URL.

Lorsqu'un contenu est stocké sur le système de fichier via (FileContentStore), l'URL du document nouvellement stocké est créée et le document est accessible via cette URL. L'URL a la syntaxe suivante : store://year/month/day/hour/minute/GUID.bin
Le GUID est le nom d'identification généré par le JCR. Les fichiers importés sont renommés avec un GUID généré automatiquement. Ce GUID est unique pour chaque fichier.
Ainsi donc, le service ContentStore permet d'écrire et de lire les fichiers binaires sur le système de stockage en se basant sur des URL donc la convention est celle qui vient d'être présentée.

Un store est un Workspace dans le référentiel (repository). Un store contient les informations sur les nodes du Workspace et des références vers les contenus binaires dans contentstore. Les Workspaces sont définis dans Alfresco à partir de deux choses : un protocole et un identificateur. Par exemple, le Workspace par défaut utilisé dans Alfresco est défini par:
Protocol = workspace
Identifier = SpaceStore
d'où store=workspace://SpacesStore
Il est possible de créer d'autres stores en utilisant des identifier différents. Par exemple: store=workspace://monStore.

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous pour avoir une bonne vue sur Content Store Service :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-C - ContentService

@Package: org.alfresco.service.cmr.repository

ContentService fournit les fonctionnalités pour accéder aux contenus et les manipuler. Il utilise le service ContentStoreService pour le stockage des contenus binaires et s'appuie aussi sur le service de transformation de format afin d'exécuter les opérations de transformation de format (exemple : transformation .doc en .pdf).

Alfresco stocke les métadonnées primaires (c'est-à-dire les métadonnées extraits des documents: le titre, l'auteur, date de création, mimetype, etc.) et les métadonnées applicatives (c'est-à-dire les propriétés définies dans les modèles M2) en base de données. Le Framework ORM utilisé pour accéder à la base de données est Hibernate.
Ci-dessous quelques exemples d'utilisation de ce service:

// get the content reader
ContentReader reader = contentService.getReader(nodeRef, propertyQName); (1)
// establish mimetype
String mimetype = reader.getMimetype(); (2)
// get the content and stream directly to the response output stream
reader.getContent(res.getOutputStream());

L'instruction (1) permet de retourner un objet de type ContentReader qui permet de lire le contenu binaire propriété de type content (cm:content) sur le node référencé par le NodeRef nodeRef.
Rappelons que les entités contenant des contenus binaires (c'est-à-dire des documents importés, des documents pouvant être des images, des documents Word, Excel, PDF, etc.) doivent être de type content (cm:content) chez Alfresco.

L'instruction (2) permet d'obtenir le type mime du contenu rattaché au reader.

L'instruction (3) permet de lire les binaires du contenu du repository et l'écrire dans l'OutPutStream.

Notons que ContentService permet également d'obtenir un objet de type ContentWriter qui permet d'écrire un contenu binaire dans le repository (sur le File System). Il permet également de transformer les contenus.

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous pour avoir une bonne vue sur Content Service :

1

http://wiki.alfresco.com/wiki/Content_Service_API

V-D - FileFolderService

@Package: org.alfresco.service.cmr.model

FileFolderService fournit méthodes spécifiques pour manipuler les contenus « fichiers » et les contenus « dossiers ».
Ce service permet de rechercher des fichiers ou des dossiers d'après leur nom, de renommer un fichier ou un dossier, déplacer un fichier ou un dossier à un autre emplacement, de copier un fichier ou un dossier dans le presse-papier.

Ce service permet de créer des fichiers et des dossiers, de les supprimer (ils peuvent être archivés). Ce service utilise le service ContentService pour réaliser l'écriture et la lecture du contenu dans le système de stockage.

Ce service est implémenté par le composant FileFolderServiceImpl. Cette implémentation s'appuie :

- Le Namespace Service: afin d'utiliser les modèles enregistrés de façon unique dans la plateforme à partir de namespaces. Notons que c'est le service Namespace Service qui permet d'utiliser l'objet QName pour identifier les entités (propriétés, types, aspects, associations).
- Le Dictionnary Service : pour utiliser les entités définies dans le dictionnaire de données (c'est-à-dire les types de données définis dans les modèles comme dictionnaryModel.xml, contentModel.xml, blogModel.xml, monModel.xml, etc.).
- Le Node Service: pour manipuler les nodes grâce au NodeRef (référence des nodes chez Alfresco).
- Le Tenant Service:@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO
- Le Copy Service: pour effectuer les copies dans le presse-papier (pouvant être collé n'importe où).
- Le Search Service: pour effectuer la recherche.
- Le Content Service: pour l'écriture et lecture des contenus binaires dans le système de stockage.
- Le MimeType Service: pour la gestion des types de fichiers et pour les transformations de format.

Le Service fournit l'API pour manipuler les contenus de type folder ou héritant du type folder (c'est-à-dire que si vous définissez un type de contenu héritant du type cm:folder alors il sera manipulé comme tout autre contenu de type dossier).

Ci-dessous quelques exemples d'utilisation dans un programme :

List<FileInfo> liste = fileFolderService.list(contextNodeRef) (1)
nodeRef = fileInfo.getNodeRef(); (2)

L'instruction (1) permet lister les fichiers et dossiers dont les nœuds sont des enfants immédiats du node contexte (c'est-à-dire le nœud courant) contextNodeRef. Les informations de chaque fichier et dossier retrouvé sont rangées dans un objet de type FileInfo. Les objets de type FileInfo sont utilisés par encapsuler les informations (c'est-à-dire les propriétés) des contenus fichiers et dossiers).

L'instruction (2) montre comment il est possible d'obtenir la référence d'un nœud de contenu à partir d'un objet FileInfo fournissant les informations sur lui.

Notons également l'exemple ci-dessous :

List<FileInfo> liste fileFolderService.search(
NodeRef contextNodeRef,
String namePattern,
boolean includeSubFolders);

Cette instruction permet de rechercher tous les fichiers et dossiers dont les noms match avec le pattern namePattern et contenus dans le contexte du nœud contextNodeRef (c'est-à-dire les nœuds de dossiers et fichiers contenus dans le sous-arbre de racine contextNodeRef).

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous pour avoir une bonne vue sur FileFolder Service :

1

http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/service/cmr/model/FileFolderService.html

V-E - DictionnaryService

@Package : org.alfresco.service.cmr.dictionary

Ce service interne, c'est-à-dire utilisé par d'autres services, fournit les fonctionnalités pour manipuler les entités définies dans les modèles de base de la plateforme Alfresco et les modèles intégrés par le développeur (c'est-à-dire les modèles de données de votre domaine à vous).
Il permet de manipuler le dictionnaire de données c'est-à-dire la banque de tous les types de données enregistrés et manipulés par la plateforme. Ce service fournit les accès aux métadonnées de contenus comme les types (Type) et les descriptions des Aspects (Aspect description), les propriétés, les associations.

Le dictionnaire de données s'appuie sur les modèles de données définis dans les modèles M1 comme dictionnaryModel.xml et les modèles M2 (les modèles de base comme contentModel.xml et les modèles étendus c'est-à-dire les modèles de données définis par le développeur utilisant les modèles de base). Notons qu'un modèle est identifié par un ou plusieurs namespaces et un prefix.

Le DictionaryService permet entre autres de retrouver tous les modèles qui ont été enregistrés, de retourner un modèle d'après son nom qualificatif (QName), de retrouver tous les types de données et ceux d'un modèle donné, de retrouver tous les aspects définis dans un modèle, d'obtenir la définition de la classe d'une entité, de vérifier si une classe est sous-classe d'une autre.

DictionaryService permet d'obtenir les informations (la définition) d'une propriété d'une entité définie dans un modèle. Bref, DictionaryService permet de fournir tous les services pour manager les types de données.

Ci-dessous quelques exemples d'utilisation dans un programme :

// return the names of all models that have been registered with the Repository
Collection<QName> models = dictionaryService.getAllModels() ; (1)
ModelDefinition modelDef = dictionaryService.getModel(QName model); (2)
Collection<QName> datas = dictionaryService.getAllDataTypes(); (3)
Collection<QName> aspects = dictionaryService.getAllAspects(); (4)
ClassDefinition classDef = dictionaryService.getClass(QName name); (5
PropertyDefinition propDef = dictionaryService.getProperty(QName className, QName propertyName); (6)

L'instruction (1) retrouve tous les modèles qui ont été enregistrés dans le repository.
L'instruction (2) retrouve un modèle à partir de son nom qualificatif (QName).
L'instruction (3) retourne tous les types de données qui ont été enregistrés dans le repository.
L'instruction (4) retourne tous les aspects qui ont été enregistrés dans le repository.
L'instruction (5) permet de déterminer les informations sur la classe définissant le type de données qualifié par le nom (QName) name.
L'instruction (6) retrouve la définition d'une propriété d'une classe donnée.

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous pour avoir une bonne vue sur Dictionnary Service :

1

http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/service/cmr/dictionary/DictionaryService.html

V-F - NamespaceService

@Package: org.alfresco.service.namespace

Ce service offre des fonctionnalités permettant de manipuler les namespaces, les préfixes, etc. Par exemple pour enregistrer un prefix pour un namespace uri, on peut faire :

registerNamespace(String prefix, String uri).

Pour voir les API de ce service, le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous :

1

http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/service/namespace/NamespaceService.html

Pour avoir la liste des namespaces de base de la plateforme Alfresco, il faut lire la documentation ci-dessous :

1

http://wiki.alfresco.com/wiki/Alfresco_Namespaces

V-G - VersionService

@Package: org.alfresco.service.cmr.version

Le service VersionService fournit une API pour manipuler les versions des objets, que ce soit les versions d'un node simple (c'est un vulgaire node représentant un type de contenu de base), ou bien les versions d'une traduction d'un document, ou même les versions d'un conteneur de traduction d'un contenu. Bref la gestion des versions fait l'abstraction sur le type de l'objet dont les versions sont gérées.

Ce service fournit des API pour créer de nouvelles versions d'un node à partir de son NodeRef. Il permet d'avoir l'historique des versions d'un node à partir de son NodeRef. Il permet de restaurer un node qui a un historique de versions.

Les versions de document sont stockées dans le store lightWeightVersionStore.

Le service de gestion des versions s'appuie sur le modèle version_model.xml (@Package: org.alfresco.repo.version) de namespace: http://www.alfresco.org/model/versionstore/1.0

AbstractVersionServiceImpl est l'implémentation abstraite de base de VersionService.
Une implémentation concrète est VersionServiceImpl.
VersionServiceImpl étend l'abstract AbstractVersionServiceImpl et implémente aussi l'interface VersionModel contenant les constantes (entre autres les QName des entités du modèle des versions) utilisées pour l'implémentation.

Quelques exemples :

VersionHistory vh = versionService.getVersionHistory(NodeRef node); (1)
VersionHistory vh = versionService.getVersionHistory(NodeRef translation); (2)

L'instruction (1) permet de retrouver l'historique des versions d'un contenu associé au Node node.
L'instruction (2) est équivalente à la (1) sauf qu'elle fournit plutôt l'historique des versions d'une traduction d'un contenu.

Pour avoir une meilleure vue sur le service VersionService, le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous :

1

http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/service/cmr/version/VersionService.html

2

http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/repo/version/VersionServiceImpl.html

V-H - VersionHistoryService

@Package: org.alfresco.service.cmr.version

Ce service collecte les versions constituant l'historique des versions d'un objet. Il fournit aussi des opérations sur les historiques. Il est implémenté par le composant VersionHistoryImpl qui permet d'accéder à l'historique des versions, de naviguer entre les versions et d'ajouter des versions à l'historique des versions d'un node.

Pour avoir une meilleure vue sur le service VersionHistoryService, le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous :

1

http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/jcr/version/VersionHistoryImpl.html

2

http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/repo/version/VersionServiceImpl.html

V-I - NodeArchiveService

@Package: org.alfresco.repo.node.archive

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-J - SearchService

@Package: org.alfresco.service.cmr.search

Ce service fournit les API de recherche à travers différents mécanismes d'indexage. Ses implémentations fournissent la recherche à partir de 3 langages: XPath, lucene, et jcr-XPath.
Il permet de rechercher dans un store (Workspace) en prenant en entrée des classes encapsulant des paramètres de recherche, le langage de requêtage à utiliser (parmi les trois cités).

Diagramme de classes simplifié de Search Service

SearchService est l'interface du service de recherche (Search).

AbstractSeacherComponent est l'implémentation de base du service SearchService. Elle est abstraite.

SearcherComponent est le composant de recherche, il étend AbstractSearcherComponent.
Pour fonctionner, SearcherComponent s'appuie sur un objet de type IndexerAndSearcher (dont LuceneIndexerAndeSearcher en est une implémentation relative à l'indexage et la recherche lucene).

Indexer est l'interface du service l'indexage. IndexerComponent est une implémentation de Indexer. Pour fonctionner, IndexerComponent s'appuie sur un objet de type IndexeAndSearcher.

Ci-dessous un exemple :

List<NodeRef> refs =
searchService.selectNodes(nodeService.getRootNode(companyHomeStore),
companyHomePath,
parameters,
namespaceService,
false);

Cette instruction permet de retrouver une liste de nœuds selon des critères donnés. Ici les paramètres sont :

- nodeService.getRootNode(companyHomeStore): sous-arbre des nœuds représentant l'arborescence à partir duquel doit s'effectuer la recherche ;
- parameters : objet contenant une chaîne XPath parametrable contenant les paramètres de recherche ;
- namespaceService : le NameSpaceService ;
- Boolean: de valeur false, permet de préciser si la rechercher s'effectuer jusqu'aux feuilles du sous-arbre.

Notons que SearchService permet de faire la recherche sur les propriétés des contenus et plus encore.

Pour avoir une meilleure vue sur le service SearchService, le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-K - ADMSearchService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-L - LockService

Ce Service vital fournit une API pour verrouiller et déverrouiller des nodes afin d'éviter toute modification concurrente. Tant que le node d'un contenu est verrouillé, un autre utilisateur ne peut modifier le contenu du nœud jusqu'à ce que le node du contenu soit unlock (déverrouillé).

Quelques exemples d'utilisation :

lockService.lock(NodeRef nodeRef, LockType lockType); (1)
lockService.unlock(NodeRef nodeRef, boolean lockChildren); (2)

L'instruction (1) permet de verrouiller le contenu de node référencé par le NodeRef nodeRef.
lockType est le type de verrou utilisé, c'est un objet de type LockType.
L'instruction (2) enlève le verrou sur le contenu de node référencé par le NodeRef nodeRef et optionnellement sur ses enfants (lockChildren).

Pour avoir une meilleure vue sur le service LockService, le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-M - LuceneCategoryService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-N - AuditService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-O - ActionService

Une Action Alfresco est une unité de tâche qui peut être exécutée sur un node. Exemple: transformer le document représenté par le node, envoyer le document par email dans un fichier attaché, copier le document, lancer une opération de sauvegarde de tout le repository, etc.

Une action est une opération qu'on peut effectuer à partir d'un node. L'opération n'est toujours pas forcement appliquée sur le node courant et elle peut impacter tout ou partie des nodes du repository ou d'un Workspace.

Les Actions Alfresco sont exécutables depuis le Client Web à partir d'un gestionnaire de règles (rules) qui affiche la liste des actions exécutables. La plateforme permet ainsi au développeur de développer de nouvelles fonctionnalités et de les intégrer.
Ci-dessous le diagramme de classes simplifié :

Diagramme de classes Action Service

Le service ActionService permet de définir les actions (liste des entités sur lesquelles l'action est applicable).
Ce service permet de gérer les conditions des actions (les conditions dont la réalisation permet d'exécuter l'action).
Ce service permet de créer de nouvelles actions Alfresco, d'exécuter les actions (après avoir vérifié que les conditions associées à l'action sont réalisées) et enfin de supprimer des actions.

ActionService est implémenté par ActionServiceImpl qui fournit tout le nécessaire pour gérer les actions Alfresco.
ActionServiceImpl implémente RuntimeActionService (permet de gérer la liste des actions dans la plateforme, de les enregistrer, de les exécuter, etc.). ActionServiceImpl implémente aussi ApplicationContextAware de Spring.
Le service ActionService s'appuie sur le modèle ActionModel.

Le développement d'une Action Alfresco implique le couple (ActionCondition, ActionExecuter).
ActionCondition est une condition qui doit être réalisée afin que ActionExecuter qui est l'unité de tâche soit lancée.

V-P - AttributService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-Q - ScriptService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-R - RuleService

Ce service vital fournit une API pour manipuler les règles de gestion dans le système. Rappelons qu'une règle de gestion est un mécanisme qui permet de dicter des conduites à tenir, contrôler la réalisation de certaines conditions (faisant partie intégrante de la définition des règles) et éventuellement engager certaines opérations.
Le Framework de gestion des règles de gestion Alfresco s'appuie sur un modèle qui est vraiment interne et ne demande aucune intervention d'un développeur. Le modèle des règles est interne et n'est utilisé et compris que par les composants internes au noyau qui constituent le Framework des règles de gestion.

Donnons quelques exemples de règle pour éclaircir les idées.
On peut avoir une règle de gestion sur un dossier qui est déclenchée à chaque fois qu'un document est ajouté dans le node associé.
On peut avoir une règle qui est déclenchée quand un contenu est déplacé d'un node.
Notons aussi qu'il est très commode d'utiliser les règles de gestion pour implémenter des logiques métier basées sur des workflows (Approved, review etc.).

Quelques exemples de code :

RuleType ruleType = ruleService.getRuleType(String name); (1)
boolean hasRule = ruleService.hasRules(NodeRef nodeRef); (2)
List<Rule> liste = ruleService.getRules(NodeRef nodeRef); (3)
ruleService.removeRule(NodeRef nodeRef, Rule rule); (4)

L'instruction (1) permet de retrouver une règle d'après son nom. Notons que les objets de type RuleType permettent de définir les règles. Les règles sont identifiables par des noms. Une entité règle est définie par la classe Rule.
L'instruction (2) permet de déterminer si un node contient une règle de gestion qui lui est associée.
L'instruction (3) retrouve toutes les règles associées à un node référencé par un NodeRef y compris les règles héritées des nodes parents. Notons que les entités Rule sont retournées.
L'instruction (4) enlève une règle de gestion sur un node.

V-S - AuthenticationService

Le service d'authentification définit une API pour manager les informations d'authentification des utilisateurs. L'implémentation de base est AuthenticationComponentImpl.

AuthenticationComponentImpl s'appuie sur ACEGI security (net.sf.acegisecurity). Cette implémentation utilise aussi l'Authentication Manager et le provider AuthenticationDao d'ACEGI pour retourner un UserDetails contenant les autorisations de l'utilisateur authentifié.
Enfin AuthenticationComponentImpl utilise MD4 pour crypter les mots de passe.

AuthenticationComponentImpl utilise les services PersonService (qui gère les profiles utilisateurs), le NodeService, le TransactionService et le TenantService.
Il permet aussi de gérer les l'utilisateur invité (GUEST USER).

AuthenticationComponentImpl utilise le modèle userModel.xml définissant l'entité user.

Notons les que les implémentations concrètes ci-dessous étendent l'implémentation de base AuthenticationComponentImpl :

- JAASAuthenticationComponent : pour l'authentification à partir de JAAS
- LDAPAuthenticationComponentImpl : pour l'authentification par LDAP
- NTLMAuthenticationComponentImpl : pour l'authentification par NTLM.

Quelques exemples :

// authenticate and get a ticket
authenticationService.authenticate(username, password.toCharArray()); (1)
// get the current ticket
authenticationService.getCurrentTicket(); (2)
// Clear current security context
authenticationService.clearCurrentSecurityContext(); (3)
authenticationService.getCurrentUserName() ; (4)
// Update the login information for the user (typically called by the user)
authenticationService.updateAuthentication(String userName, char[] oldPassword, char[] newPassword); (5)

L'instruction (1) permet d'authentifier un utilisateur dans le système, de créer et charger toutes les informations relatives à l'utilisateur dans un contexte de sécurité. Un ticket est créé pour la session de l'utilisateur.
L'instruction (3) permet de vider le contexte courant de sécurité ce qui fait qu'ainsi l'utilisateur n'est plus authentifié.
L'instruction (4) permet d'obtenir le nom de l'utilisateur authentifié.
L'instruction (5) permet d'update les informations de login de l'utilisateur.

Pour avoir une meilleure vue sur le service AuthenticationService, le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous :

1

http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/service/cmr/security/AuthenticationService.html

2

http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/repo/security/authentication/AuthenticationComponent.html

3

http://wiki.alfresco.com/wiki/Security_and_Authentication

V-T - PermissionService

Ce service vital permet de gérer les permissions, de vérifier les droits, de vérifier si une entité possède un rôle lui permettant d'effectuer une certaine opération, de vérifier si un utilisateur appartient à un groupe d'utilisateur ayant des droits d'opérations sur quelque chose.

Notons qu'un modèle permet de définir de façon standard le modèle de permission d'Alfresco. Mais ce modèle est interne, c'est-à-dire utilisé par le composant interne du noyau et donc non manipulable par le développeur, à moins de vouloir changer un comportement dans le noyau.

Ci-dessous quelques exemples :

Set<AccessPermission> permissions permissionService.getPermissions(NodeRef nodeRef); (1)
AccessStatus status permissionService.hasPermission(NodeRef nodeRef, String permission); (2)

L'instruction (1) permet de fournir toutes les permissions que l'utilisateur courant authentifié (représenté par l'objet de type authentication d'ACEGI) possède sur l'objet représenté par le NodeRef nodeRef.
L'instruction (2) vérifie si l'utilisateur courant authentifié possède la permission identifiée par la String permission sur l'objet référencé par le NodeRef nodeRef.

V-U - AuthorityService

Ce Service vital fournit une API pour manager les autorisations des utilisateurs.

Quelques exemples :

Boolean isAdmin = authorityService.hasAdminAuthority(); (1)
Set<String> authorities = authorityService.getAuthorities(); (2)

L'instruction (1) vérifie si l'utilisateur courant a les autorisations d'Administrateur.
L'instruction (2) retrouve les autorisations de l'utilisateur courant (celui qui est authentifié).

V-V - PersonService

Ce Service vital permet de manager les utilisateurs et les groupes d'utilisateurs.
Notons que les types de données représentant les utilisateurs et les groupes d'utilisateurs sont matérialisés comme des contenus. Ceci veut dire qu'un utilisateur est manipulé dans le système grâce à un node. Le type de contenu représentant un utilisateur est défini dans un modèle M2. Ce modèle est extensible si vous voulez ajouter des propriétés et des comportements supplémentaires dans les gestions des utilisateurs et des groupes d'utilisateurs.
Notons également que les utilisateurs et groupes d'utilisateurs peuvent être soit entièrement manipulés dans le repository (c'est-à-dire que les informations sur les utilisateurs sont gérées par Alfresco), soit manipulés depuis une implémentation LDAP ou NTLM.

Quelques exemples :

NodeRef person = personService.getPerson(String userName); (1)
personService.setPersonProperties(String userName, Map<QName, Serializable> properties); (2)
personService.deletePerson(String userName); (3)
personService.getAllPeople(); (4)

L'instruction (1) permet de retrouver un utilisateur à partir du username. Remarquons que c'est un NodeRef (c'est-à-dire un nœud) qui est retourné. Ceci dit, le type utilisateur est manipulé comme tout type de contenu à partir de nœud.
L'instruction (2) permet de modifier ou de définir un ensemble de propriétés d'un utilisateur de username userName.
L'instruction (3) permet de supprimer l'utilisateur identifié par le username userName.
L'instruction (4) permet de retourner tous les utilisateurs connus du système.

V-W - CategoryService

Ce Service vital fournit une API pour manipuler les catégories. Rappelons que les catégories sont une façon de classifier les documents. Associer un document à une catégorie c'est signifier que ce document est de cette catégorie. Il est ainsi possible de rechercher les documents à partir d'une catégorie. On distingue les catégories et les sous-catégories. Une sous-catégorie hérite d'une autre. Ainsi, un document d'une sous catégorie est aussi de la catégorie mère de la sous-catégorie.

Alfresco vient avec des catégories de base, mais il est possible d'en créer de nouvelles à partir du Client Web.

CategoryService permet de faire des recherches et de créer des catégories de documents.

Quelques exemples :

NodeRef category = categoryService.createCategory(NodeRef parent, String name); (1)

L'instruction (1) permet de créer une catégorie dans nom « name » en dessous d'un node « parent ».

V-X - UsageService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-Y - CheckOutCheckinService

Ce Service vital fournit une API pour check-in et check-out les contenus. Rappelons que check-out un document c'est créer une copie de travail de ce document en verrouillant la copie originale (c'est-à-dire que personne d'autre ne peut plus effectuer une modification tant que le document n'est pas check-in). Check-in permet de merger les modifications de la nouvelle version du document dans la copie originale et de déverrouiller le document.

Quelques exemples :

NodeRef workingCopyRef = cicoService.checkout(NodeRef nodeRef); (1)
NodeRef newCopy = cicoService.checkin(
NodeRef workingCopyNodeRef,
Map<String, Serializable> versionProperties,
String contentUrl); (1)

L'instruction (1) permet de check-out le document de nœud référencé par le NodeRef nodeRef et de créer une copie de travail sur lequel seront effectuées les modifications avant prise en compte dans la copie originale.
L'instruction (2) permet de check-in le document. L'opération n'est pas directement exécutée, car il y'a d'abord les opérations de versionning qui sont effectuées afin de créer une nouvelle version du document d'après la modification effectuée. L'argument versionProperties spécifie les propriétés de la nouvelle version. L'argument contentUrl représente l'URL de la copie de travail: s'il est NULL, alors le contenu de la copie de travail sera copié dans la copie initiale directement.

V-Z - MimeTypeService

Ce service est très utile et intervient en combinaison avec le service ContentService.
Il permet de fournir (à travers un Map qu'il détient) le type mime associé à une extension, de fournir l'extension associée à un type mime, de fournir tous les types mime, etc.

Quelques exemples :

String mt = mimetypeService.getMimetypesByExtension().get(ext); (1)

L'instruction (1) permet de fournir le type mime associé à l'extension (exemple : .pdf, .doc, .txt) représenté par le String ext.

V-AA - MimeTypeConfigService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AB - MessageService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AC - ContentFilterLanguagesService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AD - WorkflowService

Ce Service vital fournit une API pour interagir avec les workflows et les tâches Alfresco.
WorkflowService permet de déployer des workflows définis suivant un principe dicté par la classe WorkflowDefinition.

Le manager de workflow Alfresco pilote l'infrastructure permettant à divers types de moteur de workflow de fonctionner.
L'api du service permet de spécifier un id correspondant à un moteur à utiliser (moteur qui a été au préalable enregistré dans la plateforme).
Comme moteur de workflow préenregistré dans la plateforme, nous avons jBPM (JBoss Business Process Management).

Quelques exemples :

WorkflowDeployment workflowDescriptor =
workflowService.deployDefinition(String engineId,
InputStream workflowDefinition,
String mimetype); (1)

WorkflowDeployment workflowService.deployDefinition(NodeRef workflowDefinition); (2)
List<WorkflowTask> tasksList = workflowService.getTasksForWorkflowPath(String pathId); (3)

L'instruction (1) permet de déployer un workflow défini dans l'inputStream workflowDefinition de type mime mimetype. Elle demande d'utiliser le moteur de workflow d'id engineId.

L'instruction (2) est équivalente au (1) sauf qu'elle déploie un workflow définie dans le repository Alfresco à travers le contenu de NodeRef workflowDefinition contenant la définition du workflow. Le contenu définissant le workflow doit être du type bpm:workflowdefinition défini dans le modèle des workflows jbpmModel.xml.

L'instruction (3) permet d'obtenir toutes les tâches associées au workflow dont le node est identifié par le path pathId. Remarquons que les tâches de workflow sont définies à partir de la classe WorkflowTask.

V-AE - ImporterService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AF - MultilingualContentService

Ce service fournit une API pour manipuler la traduction des contenus. Notons que ce service concerne les données de type « content » c'est-à-dire cm:content, car il s'agit de la traduction de contenu. Alfresco définit des groupes de traduction. Si un document fait partie d'un groupe de traduction alors il est traductible dans la langue du groupe.

Afin de mieux comprendre cette notion, décrivons comment sont gérées les traductions des documents. Notons que cette logique s'appuie sur les modèles de données multilinguismes décrits dans le modèle contentModel.xml.

Une traduction d'un document c'est-à-dire une copie d'un document traduit dans un langage de locale donnée est représenté par le type de contenu cm:mlDocument (qui est un aspect).
L'ensemble des traductions d'un document est contenu dans un conteneur de type ml:mlContainer qui est du type sys:container (c'est-à-dire que c'est un conteneur d'entités). Ainsi donc, les composants de multilinguisme usent de ce modèle pour gérer les traductions des documents.

Quelques exemples :

Boolean b = multilingualContentService.isTranslation(NodeRef contentNodeRef); (1)

multilingualContentService.makeTranslation(NodeRef contentNodeRef, Locale locale); (2)

Map<Locale, NodeRef> locales =  multilingualContentService.getTranslations(NodeRef translationOfNodeRef); (3)

L'instruction (1) permet de vérifier si le contenu (de type content cm:content) représenté par le node référencé par le NodeRef contentNodeRef appartient à un groupe de traduction.

L'instruction (2) permet de traduire un document dans la langue de Locale locale, ceci en lui ajoutant l'aspect cm:mlDocument (c'est une façon de greffer le comportement qui permettra de traduire en background le document dans la langue de locale spécifiée. Notons que cet aspect est un aspect de base de la plateforme Alfresco).

L'instruction (3) retrouve toutes les traductions d'un contenu.

V-AG - EditionService

Ce Service vital fournit une API pour manipuler les versions des conteneurs des traductions d'un document.

Afin de mieux comprendre cette notion, faisons un retour arrière pour décrire comment sont gérées les traductions des documents. Les traductions s'appuient sur le modèle de multilinguisme (ml:) décrit dans le modèle contentModel.xml. Une traduction d'un document c'est-à-dire une copie d'un document traduit dans un langage de locale donnée est représentée par le type de contenu cm:mlDocument (qui est un aspect). L'ensemble des traductions d'un document est contenu dans un conteneur de type ml:mlContainer qui est du type sys:container (c'est-à-dire que c'est un conteneur d'entités).

Les conteneurs ml:mlContainer sont aussi versionnables.
EditionService est un service qui permet alors de manipuler les versions des cm:mlContainer.

Quelques exemples :

VersionHistory vh = editionService.getEditions(NodeRef mlContainer); (1)

L'instruction (1) fournit l'historique des versions d'un conteneur de translations référence par le NodeRef mlContainer.

V-AH - AdminService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AI - OwnableService

Ce Service vital fournit une API permettant de manager la notion de propriété sur des entités.

Quelques exemples :

// Get the username of the owner of the given object.
String userName = ownableService.getOwner(NodeRef nodeRef); (1)
// Set the owner of the object.
ownableService.setOwner(NodeRef nodeRef, String userName); (2)

L'instruction (1) permet d'obtenir le Username du propriétaire du contenu de nœud référencé par le NodeRef NodeRef.
L'instruction (2) permet de donner la propriété du contenu de nœud référencé par le NodeRef nodeRef à l'utilisateur de Username userName.

V-AJ - CopyService

Ce Service vital fournit une API pour copier des nodes du workspace de travail et d'updater l'état d'un autre node avec celui du node copié. Le node updaté pouvant être dans le workspace de travail ou bien dans un autre workspace.

Quelques exemples :

NodeRef newNode = copyService.copy(
NodeRef sourceNodeRef,
NodeRef destinationParent,
QName destinationAssocTypeQName,
QName destinationQName,
boolean copyChildren); (1)

NodeRef newNode = copyService.copyAndRename(
NodeRef sourceNodeRef,
NodeRef destinationParent,
QName destinationAssocTypeQName,
QName destinationQName,
boolean copyChildren); (2)

L'instruction (1) copie le node source de référence sourceNodeRef vers le parent node destinationParent. destinationAssocTypeQName est le type de la nouvelle association enfant. destinationQName est le nom qualificatif de l'association entre le parent et le nouveau node. copyChildren indique si les enfants du node doivent aussi être copiés.

L'instruction (2) est identique au précédent, mais renomme le nouveau node afin d'éviter la duplication de noms.

V-AK - AVMService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AL - ExporterService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AM - Template Service

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AN - TransactionService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AO - DeploymentService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AP - EmailService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AQ - ModuleService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AR - DescriptorService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AS - TenantService

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

V-AT - ServiceRegistry

C'est le Finder c'est-à-dire que c'est le service qui permet d'accéder à l’autre service. Celui-ci met en œuvre le design pattern service Locator.

Par exemple pour accéder à un service on fait :

NodeService nodeService = serviceRegistry.getNodeService(); (1)
ContentService contentService = serviceRegistry.getContentService(); (2)
SearchService searchService = serviceRegistry.getSearchService(); (3)
...
...

L'instruction (1) permet d'obtenir le composant du NodeService. Ainsi de suite pour les autres.

VI - LA GESTION DES EXCEPTIONS DANS ALFRESCO

Le but est de maîtriser comment sont géré les exceptions dans Alfresco et de pouvoir faire des customisations.

VI-A - Alfresco Exception Management Model

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

VII - LES WORKFLOW DANS ALFRESCO

Dans Alfresco nous distinguons deux catégories de Workflow :
- Workflow de simple processus d'approbation: workflows simples
- et Workflow de management de processus métier complexe: workflows avancés

VII-A - Workflows simples

Le Workflow simple d'Alfresco est le mouvement des documents à travers les espaces (dossiers) : il est possible d'attacher un workflow simple à un document et de notifier les collaborateurs qui peuvent traiter le document. Ces collaborateurs peuvent effectuer des opérations Approval et Reject. À partir de règles de gestion, il est possible de réaliser le déplacement des documents entre espaces en fonction de l'état du document et de l'action effectuée sur le document.

L'implémentation de cette catégorie basique de workflows ne nécessite de pas de code. Il s'agit ici d'implémenter le business process à partir de la plateforme directement dans le Client Web.

VII-B - Workflows avancés

Une autre catégorie plus importante est les workflows complexes (Advanced Workflows).

Alfresco utilise le moteur jBPM (JBoss Business Process Management) dans son noyau.
Alfresco a extrêmement rendu ce moteur extensible pour le développement de workflows complexes basés sur des processus orientés tâche (délégation de tâches à des collaborateurs et des groupes de collaborateurs, avec un timing, des délais, des notifications email, etc.). Alfresco utilise le langage de workflow jPDL pour l'expression de processus métier de façon graphique ou manuel (XML) en terme de tâches, d'état d'attente, de synchronisation de la communication, de timers et d'actions automatisées.

Pour développer une extension en implémentant un workflow avancé grâce à Alfresco, il est indispensable :
- De maîtriser ce que c'est qu'un workflow Ad-hoc et tous les concepts autour du management de processus avec jBPM ;
- De savoir utiliser jBPM {JBoss jBPM from labs.jboss.com (http://labs.jboss.com/jbossjbpm/downloads/)} ;
- De savoir comment utiliser Jboss jBPM Process Designer Plugin from labs.jboss.com (http://labs.jboss.com/jbossjbpm/downloads/) ;
- De savoir écrire les définitions de processus avec jBPM et coder ;
- De savoir déployer la définition des processus depuis jBPM Process Designer directement dans un serveur (Server Deployer = /alfresco/jbpm/deployprocess) ;
- De savoir comment utiliser le modèle de base de workflow d'Alfresco pour écrire le modèle du workflow de son extension ;
- De savoir comment utiliser les packages d'Actions des workflows Alfresco, afin de développer son extension ;
- De savoir comment ajouter du comportement à la définition des processus de son extension avec Alfresco ;
- De maîtriser le process des données (Process Data) ;
- De maîtriser les jPDL Actions et Scripts pour l'invocation des business logique lors des workflows ;
- De maîtriser l'utilisation des Timers dans la définition des workflows et dans la business logique ;
- De maîtriser l'utilisation de la Workflow Console Alfresco.

Afin d'être à l'aise dans l'implémentation des workflows avancés, il est indispensable de masteriser la technologie jBPM avant de s'aventurer vers l'implémentation des Workflows dans Alfresco.
Le master jBPM consiste en deux syllabus, un syllabus introductif et un syllabus avancé.

VII-B-1 - jBPM : syllabus simple

Pour avoir une première vue sur jBPM, le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous :

1

http://www.redhat.com/developer_studio/guides/jbpm/html_single/

2

http://www.mastertheboss.com/en/jbpm/51-jbpm-tutorial-part-1.html

VII-B-2 - jBPM : syllabus avancé

À ce stade, vous disposez des armes pour entrer dans le vif du sujet. le Centre de Compétences AlfrescojBPM de Koossery Technology vous invite à présent à lire le document utilisateur officiel de jBPM ci-dessous :

1

http://docs.jboss.org/jbpm/v3/userguide/index.html

VII-C - Le Framework des Workflows Alfresco

Alfresco intègre le moteur de BPM jBPM (JBoss BPM). Il réalise une couche superficielle permettant la gestion des instances de processus, des tâches, de l'historique et des acteurs. L'implémentation de l'API Workflows d'Alfresco est bâtie sur le modèle de contenu bpmModel.xml.
Le développeur Alfresco doit :
- Maîtriser jBPM et les concepts du BPM ;
- Maîtriser les différents types de Workflows d'Alfresco ;
- Maîtriser l'outil Eclipse Design ;
- Maîtriser l'utilisation de la console Workflow d'Alfresco ;
- Maîtriser le développement et l'intégration des Workflows avancés.

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande de lire ci-dessous :

1

https://koossery-tech.developpez.com/tutoriels/java/ecm/alfrescojbpm/exemple-implementation-workflow-avance/

VIII - LES FRAMEWORKS DU BACK-END ALFRESCO

VIII-A - Les Actions Alfresco

VIII-A-1 - Notions d'Action Alfresco

Une Action Alfresco est une unité de tâche qui peut être exécutée sur un node par exemple transformer le document représenté par le node, envoyer le document représenté par email comme fichier attaché, copier le document, lancer une opération de sauvegarde de tout le Repository par exemple.

Une action est une opération qu'on peut effectuer à partir d'un node. L'opération n'est toujours pas forcement appliquée sur le node courant, elle peut impacter tout ou partie des nodes du Repository ou d'un Workspace.
Les actions Alfresco sont configurées à partir des règles de gestion des contenus.
Lorsqu'on décide d'implémenter une action Alfresco, la première des choses à faire est de décider de ce que l'action Alfresco que vous voulez développer doit permettre de faire.

Développer une Action Alfresco revient à implémenter un certain nombre de classes abstraites au niveau du Server (pour l'implémentation de l'action proprement dite) et au niveau du Front-End web JSF (dans le cas où l'action nécessite l'interaction de l'utilisateur). Nous allons nous intéresser à un cas de figure d'une Action n'ayant aucune interaction avec l'utilisateur, c'est-à-dire n'ayant aucun fichier JSP pour l'entrée de données.

Au niveau du Server on doit implémenter l'interface org.alfresco.repo.action.executer.ActionExecutor du noyau. La classe résultante qui est l'implémentation de votre action Alfresco est appelée dans le jargon d'Alfresco un « Action Executer ». L' « Action Executer » contient l'implémentation d'une Action. C'est dans cette classe qu'on doit écrire le code qui va permettre d'effectuer des opérations sur le node.

Interface ActionExecuter

public interface ActionExecuter
{
/**
* Get the action definition for the action
*
* @return  the action definition
*/
public ActionDefinition getActionDefinition();

/**
* Execute the action executer
*
* @param action:    the action
* @param actionedUponNodeRef:    the actioned upon node reference
*/
public void execute(
Action action,
NodeRef actionedUponNodeRef);
}

Deux méthodes de l'interface ActionExecuter doivent être implémentées : getActionDefinition() et execute().

getActionDefinition(): permet de fournir un objet définissant votre action. Celui-ci donne les détails du nom de l'action (très important : en fait chaque Action Alfresco enregistrée dans la plateforme doit avoir un nom qualificatif différent des autres) et les détails sur les paramètres attendus.

execute(): fournit la méthode d'exécution. Celle-ci prendra une instance de l'action et le node sur lequel l'appliquer et exécutera les opérations spécifiées.

L'interface ActionExecuter peut être implémentée directement, mais le Centre de Compétences AlfrescojBPM de Koossery Technology conseille au développeur de plutôt étendre la classe de base des Actions ActionExecuterAbstractBase afin de bénéficier par défaut de l'implémentation de certaines méthodes basiques.

ActionExecuterAbstractBase fournit toutes les opérations additionnelles requises par la plateforme et un couple de méthodes abstraites à implémenter de façon à rendre les choses plus faciles pour un développeur. En étendant cette classe, les deux méthodes abstraites qui restent à implémenter sont: executeImpl (relative à execute() de l'interface) et addParameterDefinitions (relative à getActionDefinition de l'interface).

Classe de base ActionExecuterAbstractBase des Actions Alfresco

public class AddAspectActionExecuter extends ActionExecuterAbstractBase
{
/**
* @see org.alfresco.repo.action.executer.ActionExecuterAbstractBase#executeImpl(Action, NodeRef)
*/
@Override
public void executeImpl(Action action, NodeRef actionedUponNodeRef)
{
// TODO fill in implementation
}

/**
* @see org.alfresco.repo.action.ParameterizedItemAbstractBase#addParameterDefinitions(java.util.List)
*/
@Override
protected void addParameterDefinitions(List<ParameterDefinition> paramList)
{
// TODO fill in action parameter definitions
}
}

Dans la figure ci-dessus le développeur crée une classe AddAspectActionExecuter ( son « Action Executer ») qui implémente la classe de base ActionExecuterAbstractBase.
Les « Actions Executors » (pluriel de « Action Executer ») doivent être configurées via Spring en injectant au besoin tous les services du repository dont vous aurez besoin dans l'implémentation. Ainsi le développeur devra juste écrire les méthodes setters relatives aux services, méthodes qui seront utilisées par Spring pour injecter les services requis.

Lors de l'implémentation de l' « Action Executer », la première chose à faire c'est de paramétrer l'action afin d'avoir tous les détails nécessaires pour l'exécution. La définition des paramètres requis se fait en ajoutant dans la méthode addParameterDefintions une instruction du genre :

Exemple d'implémentation de addParameterDefinitions

public static final String NAME = "add-aspect";
public static final String PARAM_ASPECT_NAME = "aspect-name";

@Override
protected void addParameterDefinitions(List<ParameterDefinition> paramList)
{
// Add definitions for action parameters
paramList.add(
// Create a new parameter defintion to add to the list
new ParameterDefinitionImpl(
// The name used to identify the parameter
PARAM_ASPECT_NAME,
// The parameter value type
DataTypeDefinition.QNAME,
// Indicates whether the parameter is mandatory
true,
// The parameters display label
getParamDisplayLabel(PARAM_ASPECT_NAME)));         }

new ParameterDefinitionImpl() crée la définition d'un nouveau paramètre à ajouter à la liste.

Le premier paramètre de ParameterDefinitionImpl (exemple : la constante PARAM_ASPECT_NAME) est le nom qui sera utilisé pour identifier le paramètre. Notons que la méthode addParameterDefitions sera appelée en premier lieu par le Framework des Actions lorsqu'une action sera invoquée depuis le client web. Les paramètres dont on fait allusion ici sont soit les paramètres provenant du client web (nous verrons dans le chapitre sur le Front-End comment les paramètres de l'action sont gérés dans la partie Front-End des Actions Alfresco), soit des objets construits par le Framework par exemple à partir des modèles (exemple : le cas d'une action qui ajoute un aspect à un node, il s'agira d'un paramètre définissant le QName de l'aspect).

Le deuxième paramètre précise le type du paramètre (exemple : DataTypeDefinition.QNAME, ça aurait pu être DataTypeDefinition.TEXT dans le cas d'un String).

Le troisième paramètre précise si le paramètre est obligatoire ou pas. Et enfin le quatrième paramètre est le label (affichable dans le Client Web).

Ainsi lorsqu'une action est invoquée, le Framework des Actions identifie l' « Action Executer » correspondant (l' « action executer » que vous avez développée et installée dans la plateforme), puis il appelle la méthode interne getActionDefinition de la classe de base (ActionExecuterAbstractBase) qui, à l'aide de la méthode addParameterDefinitions, utilisera la liste paramList (paramètre interne) pour retourner une classe définissant l'action et contenant les définitions des paramètres.

L'objet de type Action retourné à l'aide de la méthode getActionDefinition va donc être utilisé par le Framework pour invoquer la méthode executeImpl() afin d'exécuter les opérations de l'action. Intéressons-nous à l'implémentation de la méthode executeImpl().

Notons que le corps de la méthode est essentiellement ce que vous souhaitez faire. Donc aucune règle n'est prescrite à ce niveau. Par contre ce que nous pouvons dire c'est que la méthode doit obligatoirement avoir la signature

signature de la méthode executeImpl

public void executeImpl(Action action, NodeRef actionedUponNodeRef)

Cette méthode est invoquée par le conteneur Alfresco (le Framework des Actions). Dans l'implémentation, l'argument « action » doit servir à récupérer les paramètres de l'action. Voici un exemple de récupération d'un paramètre de l'action dans l'implémentation de la méthode executeImpl :

QName aspectQName = (QName)action.getParameterValue(PARAM_ASPECT_NAME);

L'argument actionedUponNodeRef de type NodeRef est la référence (NodeRef) du node sur lequel l'action est appliquée. Cet argument, tout comme l'autre, est passé par le Framework lors de l'invocation de la méthode executeImpl.

Chaque Action doit avoir un titre et une description.
Pour ce qui concerne le nom et la description de l'action, on doit avoir les entrées :
- « action-class-name ».title ;
- « action-class-name ».description ;
- « action-class-name ».display-label ;
dans un bundle chargé.

Dans l'exemple illustratif que nous utilisons, l' « Action Executer » est nommée :

public static final String NAME = "add-aspect";

Ainsi on doit avoir ceci dans le fichier bundle :

# Custom action messages

add-aspect.title=Add aspect to item
add-aspect.description=This will add an aspect to the matched item.

Chaque paramètre de l'Action doit avoir un titre affichable (les labels des paramètres sont ajoutés à travers la méthode getParamDisplayLabel). Tous ces éléments affichables sont retrouvés à partir des bundles I18N permettant ainsi l'internationalisation (I18N) de l'action.

On doit avoir pour chaque paramètre l'entrée suivante dans le bundle :
- « action-class-name ».« param_name ». display-label.

Un exemple :

add-aspect.aspect-name.display-label=The name of the aspect to apply to the node.

Afin de rendre la nouvelle action disponible dans la plateforme, on a besoin de configurer l'action comme un Bean Spring. Ceci est possible en ajoutant cette configuration dans le fichier action-services-context.xml dans le noyau d'Alfresco. Mais dans le but de ne pas modifier les fichiers de base du noyau, il faut le faire dans un fichier nommé « action-class-name »-action-context.xml et le placer dans un package alfresco.extension. Ou bien, créer plutôt un fichier custom-action-services-context.xml et le placer toujours dans un package alfresco.extension. Ce dernier devant overrider le fichier de base action-service-context.xml.

Rappelons que tous ces fichiers (*-context.xml) sont chargés dynamiquement et automatiquement par la plateforme Alfresco. Donc, pas besoin de créer un contexte Spring dans le code.
Le contenu du fichier doit ressembler à ceci :

<bean id="add-aspect"   class="org.alfresco.repo.action.executer.AddAspectActionExecuter" parent="action-executer">
<property name="nodeService">
<ref bean="nodeService" />
</property>
</bean>

<bean id="add-aspect-messages"   class="org.alfresco.i18n.ResourceBundleBootstrapComponent">
<property name="resourceBundles">
<list>
<value>org.alfresco.sample.add-aspect-messages<value/>
</list>
</property>
</bean>

On peut voir la configuration de deux Beans. Le Bean de l'action executer montre bien que c'est une classe de type « Action-Executer ». On peut voir la configuration du bundle de l'action.
Il est possible réaliser une classe de test Junit pour tester son Action Executer. Vous devrez à chaque fois rédiger une classe de test Junit de votre Action Executer.

Il reste à développer la partie Front-End (web JSF) de l'action afin d'écrire les JSP qui permettront à l'utilisateur de saisir les paramètres. L'exemple illustratif que nous utilisons ne nécessite pas de partie Front-End c'est-à-dire ne nécessite pas de données d'entrée et d'interaction avec l'utilisateur. Nous verrons dans la section correspondante du chapitre sur le Front-End Alfresco comment développer un projet Action complet comportant un Front-End et un Back-Eend.

Le Centre de Compétences AlfrescojBPM de Koossery Technology recommande la documentation ci-dessous :

1

http://wiki.alfresco.com/wiki/Custom_Actions

VIII-A-2 - Exercice simple de développement d'Action Alfresco

Il faut s'exercer sur les projets CustomAction et TaggingSample du SDK Alfresco et lire les documentations :

1

http://wiki.alfresco.com/wiki/Custom_Actions

2

http://wiki.alfresco.com/wiki/Custom_Action_UI

3

http://ecmarchitect.com/images/articles/alfrescoactions/actions-article.pdf

VIII-B - Les Aspects Alfresco

VIII-B-1 - Notions sur les Aspects Alfresco

Le Framework Alfresco Aspect est un ensemble de composants qui permettent d'ajouter de façon programmatique et en utilisant les modèles M2, des propriétés supplémentaires ainsi que du comportement aux nœuds (exemple: comme récupérer automatiquement les courriers électroniques sur un serveur distant et les enregistrer dans le nœud courant, ou bien lancer des batch à intervalle de temps régulier pour faire n'importe quoi).

Nous allons voir comment développer un projet permettant d'ajouter non seulement des propriétés à un node, mais aussi du comportement.

L'exemple sur lequel nous allons nous appuyer est le sample « CustomAspect » du SDK Alfresco qui est notre environnement de développement des extensions.
Cet exemple est un projet qui défini un modèle d'aspect qu'on peut greffer aux nodes afin de pouvoir savoir combien de fois le contenu du node a été lu, combien de fois il a été modifié et quand est-ce que le comptage a débuté. Cet aspect ajoute dont 3 propriétés aux propriétés primaires des nodes :
- Une propriété pour le nombre de fois que le contenu a été modifié ;
- Une propriété pour le nombre de fois qu'il a été lu ;
- Et une pour la date de début du comptage, c'est-à-dire la date à laquelle l'aspect a été ajouté au node.

En plus de l'ajout des propriétés, il faut développer du comportement implémentant les opérations pour incrémenter les deux propriétés suivantes: celle concernant le nombre de lectures quand le document est lu et celle concernant le nombre de modifications quand le document est modifié.

À présent nous devons définir le modèle de notre aspect. Définir le modèle de l'aspect revient à définir le type de contenu qui représentera l'aspect et aussi définir les propriétés que cet aspect apportera en plus aux nodes. Le comportement (implémentation de l'aspect) utilisera les propriétés de l'aspect lors de la réalisation les opérations associées (initialisation de la date de début des comptes, incrémentation du compteur du nombre de modifications, incrémentation du compteur du nombre de consultations).
Le modèle est défini dans le fichier contentHitsModel.xml. Ci-dessous un extrait :

Modèle de l'entité aspect du projet CustomAspect

<aspects>

<!-- Definition of new Content Aspects: Content Hits -->
<aspect name="ch:contentHits">
<title>Content Hits</title>
<properties>
<property name="ch:countStartedDate">
<type>d:date</type>
<mandatory>true</mandatory>
</property>
<property name="ch:updateCount">
<type>d:int</type>
<default>0</default>
</property>
<property name="ch:readCount">
<type>d:int</type>
<default>0</default>
</property>
</properties>
</aspect>

</aspects>

On peut voir trois propriétés. Ce sont les propriétés qui seront ajoutées aux propriétés des nodes sur lesquels cet aspect sera greffé. La propriété ch:countStartedDate représente la date de début de comptage, ch:updateCount représente le compteur du nombre de modifications du contenu et ch:readCount le compteur du nombre de consultations du contenu.

Ceci est une représentation du modèle de l'aspect du projet sous forme de diagramme UML. Mais il est à noter que ceci n'est fait que dans un but illustratif. En réalité la plateforme ne crée pas de classes pour les entités définies dans les modèles M2. Les diagrammes de classes UML sont utilisés pour présenter les modèles M2 juste pour des buts d'illustration: ne surtout pas croire qu'une classe ContentHits sera créée pour ce modèle. Les modèles de données définis dans les fichiers modèles M2 sont juste les définitions de types de contenu de propriétés manipulées par le NamespaceService et le DictionaryService afin de construire une représentation dans le repository.

On pourrait maintenant se poser la question de savoir comment est-ce que cet aspect va être enregistré dans la plateforme afin qu'il soit possible de l'utiliser et de le greffer sur des nodes. Et bien cela sera fait par configuration XML à travers le mécanisme de chargement dynamique et automatique des configurations des extensions Alfresco qui demande que le fichier de configuration Spring du projet soit créé dans un package alfresco.extension avec un nom se terminant par « -context ». Ainsi notre aspect est configuré dans le fichier « content-hits-context.xml » créé dans un package alfresco.extension du projet. Les modèles sont chargés à partir du bean dictionaryModelBootstrap qui dépend lui-même du bean dictionaryBootstrap.

Enregistrement du modèle du projet CustomAspect

<!-- Registration of new models -->
<bean id="contentHits.dictionaryBootstrap" parent="dictionaryModelBootstrap" depends-on="dictionaryBootstrap">
<property name="models">
<list>
<value>org/alfresco/sample/contentHitsModel.xml</value>
</list>
</property>
</bean>

À ce stade c'est suffisant pour l'intégration du nouveau type de contenu aspect de notre projet.
Maintenant il reste l'implémentation du comportement associé, c'est-à-dire les opérations qui vont créer la date de début de compte dès que l'aspect sera ajouté à un node, et les opérations qui réaliseront les incrémentations.

On pourrait se poser la question de savoir quelle interface (ou classe abstraite de base) doit être implémentée (ou étendue) pour réaliser la classe behavior (comportement) de l'aspect. À ce stade du master nous répondons en disant que pour notre projet, rien !! (Pour l'instant). En fait, la classe qui réalise l'implémentation du comportement de notre projet n'implémente aucune interface ou n'étend aucune classe abstraite relative au concept des Aspect Alfresco. Mais ça ne veut pour autant pas dire que notre classe n'implémente aucune interface du tout, ou bien aucune classe abstraite du tout !!! En fait elle implémente même 3 interfaces. Afin de vous dire quelles interfaces, nous allons essayer de répondre aux questions :
- Comment est-ce que la plateforme fait pour savoir qu'un aspect (l'aspect que nous avons défini dans notre modèle et qui est enregistré et disponible dans le dictionnaire de données) est en train d'être greffé à un node donné ? Ceci afin de créer un objet de type Date (new Date()) et enrichir la propriété ch:countStartedDate qui vient d'être ajoutée par l'aspect.

- Comment fait-il pour détecter une modification de nœud ? Ceci afin d'incrémenter sa propriété ch:updateCount.

- Comment fait-il pour détecter une lecture du nœud ? Ceci afin d'incrémenter sa propriété ch:readCount.

La réponse à ces questions est le mécanisme de source - auditeur du Framework Alfresco. En fait, la plateforme Alfresco dispose d'un Framework de source - auditeur. Ce Framework, qui va être étudié dans une section plus bas, permet de développer des auditeurs à des évènements. En gros voici comment ça marche : le Framework possède un certain nombre d'évènements qu'il peut écouter (exemple : lecture de node, suppression d'un node, ajout d'un aspect à un node, ajout d'une association à un node etc. la liste est longue). Ainsi un auditeur de type OnContentReadPolicy sera invoqué par la plateforme lors de la lecture d'un node, un autre de type OnMoveNodePolicy sera invoqué lors du déplacement d'un node. La plateforme permet donc d'implémenter des auditeurs de ces divers types qui seront invoqués lors d'évènement associé afin de réaliser ce que vous voulez du node concerné. Pour chaque type d'auditeur, une interface est fournie pour être implémentée.

Pour revenir à notre projet, en s'appuyant sur le framework Source-Auditeur, la classe de notre comportement doit implémenter trois interfaces représentant les trois types d'auditeurs : OnContentReadPolicy, OnContentUpdatePolicy, OnAddAspectPolicy

Déclaration de la classe implémentant le comportement de l'aspect du projet CustomAspect

public class ContentHitsAspect implement
ContentServicePolicies.OnContentReadPolicy,
ContentServicePolicies.OnContentUpdatePolicy,
NodeServicePolicies.OnAddAspectPolicy

Notre classe tri-auditeur sera enregistrée dans la liste des auditeurs de type ContentReadPolicy, elle sera ajoutée dans la liste des auditeurs de type ContentUpdatePolicy et dans la liste des auditeurs de type AddAspectPolicy et sera managée par le Framework des sources - auditeurs.
La configuration de notre comportement se fait dans le fichier contexte « content-hits-context.xml » dans le package alfresco.extension

<!-- ContentHits Aspect Behaviour Bean -->
<bean id="contentHitsAspect" class="org.alfresco.sample.ContentHitsAspect" init-method="initialise">
<property name="nodeService">
<ref bean="nodeService"/>
</property>
<property name="policyComponent">
<ref bean="policyComponent"/>
</property>
<property name="policyFilter">
<ref bean="policyBehaviourFilter"/>
</property>
<property name="transactionService">
<ref bean="transactionService"/>
</property>
<property name="threadExecuter">
<ref bean="threadPoolExecutor"/>
</property>
</bean>

La méthode initialise() permet d'enregistrer les auditeurs implémentant les comportements.

/**
* Spring initilaise method used to register the policy behaviours
*/
public void initialise()
{
// Register the policy behaviours
this.policyComponent.bindClassBehaviour(
QName.createQName(NamespaceService.ALFRESCO_URI, "onAddAspect"),
ASPECT_CONTENT_HITS,
new JavaBehaviour(this, "onAddAspect", NotificationFrequency.FIRST_EVENT));
this.policyComponent.bindClassBehaviour(
ContentServicePolicies.ON_CONTENT_READ,
ASPECT_CONTENT_HITS,
new JavaBehaviour(this, "onContentRead", NotificationFrequency.TRANSACTION_COMMIT));
this.policyComponent.bindClassBehaviour(
ContentServicePolicies.ON_CONTENT_UPDATE,
ASPECT_CONTENT_HITS,
new JavaBehaviour(this, "onContentUpdate", NotificationFrequency.TRANSACTION_COMMIT));
}

La première instruction réalise le binding de notre comportement avec l'évènement d'ajout de notre aspect à un node. L'auditeur sera invoqué uniquement la première fois que l'évènement d'ajout de l'aspect se réalisera sur un node.

La deuxième instruction réalise le binding de notre comportement avec l'évènement de lecture d'un contenu. L'auditeur sera invoqué lorsque la transaction sera commit.

La troisième et dernière instruction réalise le binding de notre comportement avec l'évènement de modification d'un contenu. L'auditeur sera invoqué lorsque la transaction sera commit.

Une question plane. Puisque notre classe (l'implémentation du comportement de l'aspect) est à la fois auditeur des trois types, quelle méthode sera invoquée à chaque fois qu'il y'aura un évènement de type parmi les trois types traités. La question semble évidente n'est-ce pas ? En fait chaque interface d'auditeur impose l'implémentation d'une méthode bien précise. C'est cette méthode qui sera invoquée par la plateforme suite à un évènement.

Pour l'ajout d'un aspect c'est-à-dire le behaviour onAddAspect, la méthode à implémenter est onAddAspect(NodeRef nodeRef, QName aspectTypeQName). L'argument NodeRef est le NodeRef du node sur lequel l'aspect est greffé tandis que l'argument aspectTypeQName est le QName (qualificatif) de l'aspect greffé (c'est-à-dire l'aspect de notre projet).
Notre implémentation de cette méthode se limite à juste ajouter au node une propriété countStartedDate (le QName de cette propriété a été défini dans le modèle de notre aspect) avec une valeur égale à la date de l'instant présent.

- Pour la modification d'un contenu c'est-à-dire le behaviour onContentUpdate la méthode à implémenter est void onContentUpdate(NodeRef nodeRef, boolean newContent)
Comme on peut déjà l'imaginer, l'implémentation de cette méthode permet d'incrémenter le compteur du nombre de modifications du contenu du node.

- Pour la lecture d'un contenu c'est-à-dire le behaviour onContentRead la méthode à implémenter est void onContentRead(NodeRef nodeRef)
Comme on peut déjà l'imaginer, l'implémentation de cette méthode permet d'incrémenté le compteur du nombre de consultations du contenu du node.

@Note: Nous n'insisterons pas assez sur le Framework de gestion des behaviour (comportement) et des sources - auditeurs avec le composant PolicyComponent dans cette section, car il sera vu en détail dans une section plus en bas et s'argumentera d'un syllabus associé.

Notons qu'un Aspect Alfresco n'est rien dans la plateforme sans une Action Alfresco pour le greffer aux nodes. Ceci dit, il est important de développer une Alfresco Action qui permettrait de greffer votre aspect aux nodes. Ainsi si l'on veut greffer l'aspect que nous venons d'illustrer, il nous suffira de juste lancer l'action en question.

Mais étant donné que nous sommes en environnement de programmation, une bonne classe de test Junit nous permettrait de tester notre aspect. Nous vous invitons à explorer la classe de test Junit qui est fourni avec ce projet. Exécutez le test et voyez de vos yeux l'aspect en action.

VIII-B-2 - Exercice simple de déveppement d'Aspect Alfresco

Il s'agit de s'intéresser au projet CustomAspect du SDK Alfresco, au projet emailistener disponible sur la forge d'Alfresco. Lire les documentations :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

VIII-C - Sources et Auditeur

VIII-C-1 - Notions

La plateforme Alfresco dispose d'un Framework de « source - auditeur ». Ce Framework permet de développer des auditeurs qui sont à l'écoute des évènements. En gros voici comment ça marche : le Framework possède un certain nombre d'évènements qu'il peut écouter (exemple : lecture de node, suppression d'un node, ajout d'un aspect à un node, ajout d'une association à un node etc. la liste est longue). Par exemple un auditeur de type OnContentReadPolicy sera invoqué par la plateforme lors de la lecture d'un node, un autre de type OnMoveNodePolicy sera invoqué lors du déplacement d'un node. La plateforme permet donc d'implémenter des auditeurs de ces divers types qui seront invoqués lors d'évènements associés. Pour chaque type d'auditeur, une interface est fournie.

Le tableau ci-dessous dresse une liste exhaustive d'interfaces d'auditeurs fournies par Alfresco et utilisable pour développer des auditeurs :

En mettant en œuvre le design pattern « observer », les auditeurs sont invoqués sur la base de notifications fréquentielles. Le tableau suivant dresse une liste de notifications fréquentielles :

En récapitulatif si je veux créer un comportement, la première des choses est que je dois décider ce que mon comportement doit faire. Après il faut que je sache à quel évènement mon comportement est lié. Et finalement suivant quelle fréquence mon comportement doit être exécuté.
Ainsi quand ces trois points sont clarifiés, j'implémente mon auditeur. Puis je l'encapsule dans un objet de type JavaBehaviour en spécifiant la fréquence de notification.

policyComponent.bindClassBehaviour(
ContentServicePolicies.ON_CONTENT_UPDATE,
monQName,
new JavaBehaviour(monAuditeur, "onContentUpdate",
NotificationFrequency.TRANSACTION_COMMIT));

Cette instruction permet de placer mon comportement dans une file transactionnelle de comportements à exécuter, ceci en spécifiant le type d'évènement et la fréquence de notification. Dans cette instruction monQName représente le QName de l'entité qui est manipulée, « onContentUpdate » est le nom de la méthode implémentée par l'auditeur et qui sera exécutée par le Framework, ContentServicePolicies.ON_CONTENT_UPDATE représente l'évènement comme on peut le voir et en même temps, il représente le type d'auditeur.

VIII-C-2 - Exercice simple de développement d'auditeur d'évènement Alfresco

Le projet « CustomAspect » du SDK Alfresco est un excellent exemple de projet utilisant des auditeurs. Le Centre de Compétences AlfrescojBPM de Koossery Technology vous recommande de vous exercer dessus. De plus lire les documentations :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

IX - CONFIGURATIONS DU REPOSITORY

Il s'agit de maîtriser les différentes options de configuration du noyau Alfresco. Le développeur Alfresco devra connaître :
- Les options de configuration du stockage des documents ;
- Les options de configuration de la base de données ;
- Les options de configuration du cache ;
- Les options de configuration des composants du Repository.

Lire les documentations :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X - FRONT-END WEB D'ALFRESCO: DÉVELOPPEMENTS JSF

X-A - Généralités sur le Front-end JSF Alfresco

La couche présentation d'Alfresco est bâtie sur une technologie JSF avec l'implémentation standard Apache MyFaces.

La couche présentation d'Alfresco est développée dans les règles de l'art et sa compréhension demande un certain niveau de maîtrise du développement d'application web JSF.

La couche présentation fournit plusieurs mécanismes et frameworks facilitant sa customisation, le développement de nouveaux composants et l'implémentation d'interfaces d'interaction avec le Back-end. Nous allons dans ce chapitre présenter les différentes briques internes du Front-end en commençant par faire une description brève des différents backed-beans.

X-B - Les principaux beans managés du Front-End

X-B-1 - LoginBean

C'est le backed-bean de la vue « login.jsp ». Cette vue fournit le formulaire à utiliser pour saisir les données de login de l'utilisateur. LoginBean contient des méthodes pour valider les données du formulaire, ainsi que des méthodes qui agissent en tant que « listener » sur l'évènement déclenché (ici c'est actionEvent) quand le bouton de login est pressé. L'action exécutée lorsque le bouton est pressé est la méthode login(). Cette méthode procède à l'authentification de l'utilisateur grâce au service AuthentificationService du Backend.

<tr>
<td colspan=2 align=right>
<h:commandButton id="submit"
action="#{LoginBean.login}"
value="#{msg.login}" />
</td>
</tr>

Il est possible de customiser ce Bean afin d'ajouter des traitements dans le processus de login. Un excellent exemple utilisant ce Bean est l'exemple CustomLogin disponible dans le SDK Alfresco.

X-B-2 - BrowseBean

Ce backed-Bean fournit les propriétés et comportements utiles pour la vue de navigation dans les dossiers et fichiers et dans les vues de recherche. Parmi les vues de navigation, c'est-à-dire celles qui permettent de visualiser l'arborescence des dossiers et fichiers, nous pouvons citer : « browse.jsp », « category-browse.jsp » et « dashboard.jsp ». Les vues de recherches sont : « advanced-search.jsp », « edit-search.jsp », « save-search.jsp ».

Les propriétés fournies pas le backed-Bean sont :
- Le document courant : il s'agit du document en cours de traitement ou de consultation ;
- Des propriétés utilisées pour la disposition des composants sur la vue ;
- Les nœuds parents du nœud courant ;
- Les nœuds en cours de traitement ;

Comme traitement, on peut citer :
- Faire une recherche simple ;
- Mettre à jour l'apparence de la vue d'affichage ;
- Exécuter des actions et des actions de suppression ;

En général il n'est pas nécessaire de customiser ce Bean.

X-B-3 - NavigationBean

Les habitués de JSF savent que le flow des requêtes est orchestré par un composant de navigation de base JSF. Il est possible de customiser ce composant afin d'implémenter une logique de navigation entre les vues conforme à son problème.

Le NavigationBean fournit l'accès et le management de la navigation entre les vues. Entre autres, il permet d'indiquer le nœud courant sur lequel la navigation est réalisée, il permet d'obtenir la localisation de l'exploration (path de la localisation), il permet d'obtenir un pointeur vers des nœuds principaux comme les nœuds représentants l'espace de l'entreprise, l'espace invité. Il fournit l'ensemble des OUTCOME de navigation usuelle.

En général il n'est pas nécessaire de customiser ce Bean.

X-B-4 - WorkflowBean

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-5 - FileUploadBean

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-6 - BaseActionWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-7 - RunActionWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-8 - BaseActionHandler

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-9 - ScriptHandler

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-10 - BaseContentWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-11 - CreateContentWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-12 - EditContentWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-13 - DashboardWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-14 - BaseDialogBean

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-15 - FileUploadBean

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-16 - SidebarBean

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-17 - BaseContentWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-18 - CreateContentWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-19 - EditContentWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-20 - DashboardWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-21 - ForumsBean

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-22 - AddUserDialog

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-23 - CreateGroupDialog

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-24 - CreateRoleWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-25 - CreateSpaceWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-26 - CreateSpaceDialog

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-27 - TrashcanDialog

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-28 - ContentUsersBean

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-29 - CreateUserWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-30 - UserConsoleDialog

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-31 - UserDialog

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-32 - NewUserWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-33 - BaseWizardBean

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-34 - ManageTaskDialog

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-35 - WorkflowBean

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-36 - WorkflowConsoleBean

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-B-37 - StartWorkflowWizard

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-C - Les Frameworks du FE

X-C-1 - Les Dialogs Alfresco

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-C-2 - Les Wizards Alfresco

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-D - Les API Webscript et JavaScript

La couche présentation du FE Alfresco intègre plusieurs API notamment l'API Web Script, JavaScript (qui est interprété coté serveur par le moteur Rhino).

X-D-1 - Alfresco : Web Scripts

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-D-2 - Alfresco : JavaScripts

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

X-E - Extension du Front-End Alfresco

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

XI - EXPOSITION DE SERVICES: LES MIDDLEWARE D'ALFRESCO

Il existe plusieurs modes d'exposition des services : Local, WebServices, RMI.

XI-A - Alfresco Web Services

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

XI-B - Alfresco RMI

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

XII - PAQUETAGE ET DÉPLOIEMENT DES EXTENSIONS AVEC LES OUTILS D'ALFRESCO

L'objectif est de maîtriser les techniques de paquetage des nouveaux modules et de savoir comment utiliser le moteur de déploiement (MMT) d'Alfresco pour les déployer.

Le Centre de Compétences AlfrescojBPM de Koossery Technology vous recommande de la documentation :

1

http://wiki.alfresco.com/wiki/Developing_an_Alfresco_Module

2

http://wiki.alfresco.com/wiki/Module_Management_Tool

XIII - LES PROTOCOLES D'ACCÈS

XIII-A - CLUSTER

Le but est de maîtriser la réalisation de clusters de serveurs Alfresco. De maîtriser la mise en œuvre de réplication.

Le Centre de Compétences AlfrescojBPM de Koossery Technology vous recommande de la documentation :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

XIII-B - CIFS

Le but de maîtriser comment utiliser le serveur CIFS implémenté dans le noyau d'Alfresco pour permettre l'accès au repository à partir de voisinages réseaux. Le but est aussi de masteriser son implémentation dans le noyau.

Le Centre de Compétences AlfrescojBPM de Koossery Technology vous recommande de la documentation :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

XIII-C - FTP

Le but est de maîtriser comment accéder au repository Alfresco à partir du protocole FTP. Le but est aussi de maitriser l'implémentation du serveur FTP d'Alfresco dans son noyau.

Le Centre de Compétences AlfrescojBPM de Koossery Technology vous recommande de la documentation :

1

@COMING SOON DANS LA PROCHAINE VERSION DE LA BIBLE DU DEVELOPPEUR ALFRESCO

XIV - REMERCIEMENTS ET COMMENTAIRES

Tous nos remerciements au comité de relecture developpez.com

Nous remercions également tous les membres du Centre de Compétences AlfrescojBPM de Koossery Technology ainsi que les autres pool techniques (notamment le Centre de Compétences koosseryADempiere ERP) pour l'esprit de curiosité et de partage des connaissances. Leurs multiples questions et critiques nous ont été grandement bénéfiques.

N'hésitez pas à réagir par l'intermédiaire de ce fil : Commentez