@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é:

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:

(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:

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 Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous :

@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 urls.

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ée 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 Urls.

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 urls 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 Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous pour avoir une bonne vue sur Content Store Service:

@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éta-donné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èle M2) en base de donnée. 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 Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous pour avoir une bonne vue sur Content Service:

@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éfinis 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 noeuds sont des enfants immédiats du node contexte (c'est-à-dire le noeud 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 noeud 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 noeud contextNodeRef (c'est-à-dire les noeuds de dossiers et fichiers contenus dans le sous-arbre de racine contextNodeRef).

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

@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éfini 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 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 autre 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 Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous pour avoir une bonne vue sur Dictionnary Service:

@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 Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous:

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

@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 Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous:

@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 Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous:

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

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

@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, la langage de requêtage à utiliser (parmi les 3 cités).

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 noeuds selon des critères donnés. Ici les paramètres sont:

-  nodeService.getRootNode(companyHomeStore): sous-arbre des noeuds 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 Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous:

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

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 noeud 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 Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous:

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

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

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é :

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'appuit 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.

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

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

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étiers 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.

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 tous les informations relatives à l'utilisateur dans un contexte de sécurité. Un ticket est crée 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 Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous:

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évéloppeur, à 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.

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é).

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é 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 noeud) qui est retourné. Ceci dit, le type utilisateur est manipulé comme tout type de contenu à partir de noeud.
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.

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".

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

Ce Service vital fournit une API pour check-in et check-out les contenus. Rappelons que check-out un document c'est créer un 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 noeud 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.

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.

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

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

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

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éenrégistré dans la plate-forme, 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 tous 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.

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

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.

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.

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

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 noeud référencé par le NodeRef NodeRef.
L'instruction (2) permet de donner la propriété du contenu de noeud référencé par le NodeRef nodeRef à l'utilisateur de Username userName.

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.

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

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

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

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

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

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

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

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

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

C'est le Finder c'est-à-dire que c'est le service qui permet d'accéder au autre service. Celui-ci met en oeuvre 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.