Alfresco

Installer & Configurer votre instance FlowerDocs

Le connecteur Alfresco pour FlowerDocs permet de disposer des fonctionnalités FlowerDocs pour des contenus stockés dans Alfresco 5.2.2.


Cette documentation s’appuie sur le dossier ${FD_HOME} contenant les fichiers de configuration des applications.

FlowerDocs Core

L’ensemble des propriétés permettant de configurer FlowerDocs Core doivent être ajoutées dans un fichier core.properties.
Ce fichier est chargé au démarrage de la JVM, les modifications ne sont donc prises en compte qu’après redémarrage du serveur d’application.

file.dir=C:\\FlowerDocs\\Files\\	

######## Alfresco Configuration #####################################################
alfresco.url=http://<alfresco host>:<alfresco port>/alfresco
core.services.dao=alfresco

componentclass.prefix.allowed=fd:,fdg:
tag.prefix.allowed=fd:,fdg:


Les propriétés propres à Alfresco sont :

Propriété Description
alfresco.url Définition de l’url Alfresco.
core.services.dao=alfresco Définition du connecteur à utiliser. La notion de connecteur est portée par l’implémentation de l’API DAO

Les différents timeout du client HTTP utilisé par ce connecteur sont configurables de la façon suivante :

Propriété Valeur par défaut (ms) Description
alfresco.http.client.connection.timeout 30000 Timeout de connection
alfresco.http.client.read.timeout 120000 Timeout de lecture
alfresco.http.client.write.timeout 120000 Timeout d’écriture

Lors de la récupération des groupes auxquels appartient un utilisateur ou bien les membres d’un groupe, Alfresco remonte uniquement les 100 premiers. Ces paramètres sont configurables :

Propriété Valeur par défaut Description
alfresco.max.group.members 100 Nombre de membres d’un groupe
alfresco.max.user.groups 100 Nombre de groupes d’un utilisateur

FlowerDocs GUI

L’ensemble des propriétés permettant de configurer l’application FlowerDocs GUI doivent être ajoutées dans le fichier gui.properties situé dans le répertoire ${FD_HOME}.
Ce fichier est chargé au démarrage de la JVM, les modifications ne sont donc prises en compte qu’après redémarrage de l’application.

ws.url=http://<flower host>:<flower port>/<flower context path>/services
arender.rendition.nodes=http(s)://rendition-host:8761

Le mécanisme de classement automatique s’appuie sur des règles composées chacune d’un sélecteur et d’un dossier cible. La règle la plus précise s’applique pour définir le dossier cible dans lequel sera classé le composant.

Le classement automatique est (re)calculé lors de :

  • la création d’un composant
  • lors de sa mise à jour

Chaque règle est définie comme une propriété dans le fichier core.properties tel que : <sélecteur>=<dossier cible>

Sélecteur

Sélecteur de classe

Les composants, concernés par une règle de classement automatique, peuvent être sélectionnés par leur classe. Le sélecteur doit ainsi prendre en compte l’alias de la classe ou l’identifiant complet de la classe (avec la combinaison d’aspects) (par exemple : alfresco.auto.classify.paths[fdg\:Claim]).

Note : Les identifiants de classe pouvant contenir des :, il est nécessaire de les protéger par des \ et de les encapsuler dans des crochets [].

Sélecteur de catégorie

Les composants, concernés par une règle de classement automatique, peuvent être sélectionnés par leur catégorie avec les sélecteurs suivants :

  • alfresco.auto.classify.paths[DOCUMENT]
  • alfresco.auto.classify.paths[VIRTUAL_FOLDER]
  • alfresco.auto.classify.paths[FOLDER]
  • alfresco.auto.classify.paths[TASK]

Dossier cible

Dossier par défaut

Les noeuds Alfresco devant impérativement être classés dans un dossier sont par défaut stockés dans /FlowerDocs/<Année>/<Mois>/<Jour>. Ce dossier par défaut est configurable en définissant la propriété alfresco.auto.classify.defaultPath.

Variables

Les règles définies acceptent plusieurs variables permettant la définition des règles de classement automatique : Le dossier cible d’une règle de classement automatique peut être défini à l’aide de variable. Ces variables sont résolues à partir du composant concerné.

Les variables qui peuvent être utilisées sont listées ci-dessous :

Expression Valeur de remplacement
%(tagId) Première valeur du tag tagId
%(classid) Identifiant de la classe du composant
%(YEAR) Année de la date de création du composant
%(MONTH) Mois de la date de création du composant (01 pour janvier)
%(DAY) Jour de la date de création du composant (01 pour le premier jour du mois)

alfresco.auto.classify.paths[fdg\:Claim]=%(RH_Famille)/%(YEAR)

Stockage dans un site

Il est recommandé de stocker ces documents dans des sites afin de cloisonner les données. Actuellement, la création du site est un prérequis. La création de l’arborescence utilise uniquement la création de noeuds de type Folder et non le service dédié au site.

Pour classer les documents de type fdg:Claim dans un site sample-flower-docs, ajouter la propriété suivante :

alfresco.auto.classify.paths[fdg\:Claim]=/Sites/sample-flower-docs/documentLibrary/Claim/%(YEAR)/%(MONTH)/%(DAY)

Les types, aspects et propriétés doivent être définis préalablement dans Alfresco.

Classes de tags

Les classes de tags à surcharger dans FlowerDocs sont les tags de type USER, TEXT, CHOICELIST et CONDITIONAL. Pour les autres classes de tags, la définition des propriétés Alfresco est suffisante.

L’ajout du libellé d’un tag se paramètre dans la partie définition de propriétés d’Alfresco.

Pour les tags de type liste de choix et conditionnel, le nom symbolique FlowerDocs doit correspondre à la valeur d’une contrainte Alfresco qui doit être définie préalablement dans Alfresco.

Les notions de tag obligatoire et de valeur par défaut dans le document se paramètrent directement dans Alfresco au niveau de la définition de propriété. De plus, si le tag est noté comme obligatoire il le sera pour toutes les classes de composants. Si besoin, les notions de tag obligatoire et de valeur par défaut peuvent être gérées en fonction de la classe des composants à l’aide d’un développement spécifique en utilisant un script Javascript.

Classes de composants

Pour chaque type Alfresco, créez la propriété alfresco.aspects[nom_du_type] en listant les aspects présents dans ce type séparés par une virgule. Note : Les identifiants de classe pouvant contenir des :, il est nécessaire de les protéger par des \ et de les encapsuler dans des crochets [].

alfresco.aspects.n[fd\:Claim]=fd:aspect1|fd:aspect2|fd:aspect3

Un même type peut avoir plusieurs combinaisons d’aspects, dans ce cas il faut séparer chaque combinaison par un pipe | :

alfresco.aspects.n[fd\:Claim]=fd:aspect1|fd:aspect2|fd:aspect3|fd:aspect1|fd:aspect4|fd:aspect5

Ces propriétés vont faire le lien entre les types Alfresco et les classes de composants FlowerDocs (documents, dossiers virtuels, tâches). Chaque combinaison va générer un identifiant de classe FlowerDocs (classid).

Les tâches et pièces jointes

Les liens entre une tâche et ses pièces jointes est assuré par la notion de Secondary association où :

  • le type d’association est l’identifiant de la pièce jointe
  • le noeud fils référencé est l’identifiant du composant attaché

La définition d’une pièce jointe est réalisé dans un modèle tel que :

<aspect name="rh:hasCV">
	<associations>
		<child-association name="rh:cv">
			<source>
				<mandatory>false</mandatory>
				<many>true</many>
			</source>
			<target>
				<class>cm:content</class>
				<mandatory>false</mandatory>
				<many>true</many>
			</target>
			<duplicate>false</duplicate>
			<propagateTimestamps>true</propagateTimestamps>
		</child-association>
	</associations>
</aspect>

Les alias

Le concept d’alias permet d’associer des identifiants référençants des identifiants Alfresco.

Un alias peut être défini pour l’identifant de :

  • une classe de composants
  • une classe de tags
  • une pièce jointe de tâche

Un alias est configuré grâce au fichier core.properties en ajoutant une propriété telle que :

alfresco.alias.<name>=<id>

Il est possible de positionner des ACLs différentes en fonction des tags d’un composant. Ces règles peuvent être définies en fonction de la classe du composant.

Note : Les identifiants de classes pouvant contenir des :, il est nécessaire de les protéger par des \ et de les encapsuler dans des crochets [].

Exemple : ACL en fonction des valeurs de tags fdg:categorie et fdg:sousCategorie

alfresco.acl.strategies[fdg\:Claim]=ACL_%(fdg:categorie)_%(fdg:sousCategorie)

Pour chaque identifiant d’ACL généré / possible, il est nécessaire de définir l’ACL correspondante (fichier XML dans Data Dictionary/FlowerDocs/SecurityObjects).

FlowerDocs fournit un module Alfresco permettant de générer une arborescence de dossier en positionnant des permissions (couples rôle / autorité) sur les dossiers. L’arborescence à générer doit être décrite dans un fichier XML flower-conf-directories.xml situé dans Data Dictionary / FlowerDocs / DirectoriesConfiguration.

Exemple de configuration d’arborescence :

<?xml version="1.0" encoding="UTF-8"?>
<flowerDirectories>
    <rootDirectory name="flower" isInheritanceEnabled="false" enableReadForAuthority="GROUP_EVERYONE">
        <directory name="cat1">
            <directory name="scat1-1">
                <directory name="sscat1-1-1">
                    <permissions isInheritanceEnabled="false">
                        <ace authority="GROUP_FLOWER_LECTEURS" permission="Consumer" accessStatus="ALLOWED"/>
                        <ace authority="GROUP_FLOWER_COLLABORATEURS" permission="Collaborator" accessStatus="ALLOWED"/>
                    </permissions>
                </directory>
                <directory name="sscat1-1-2">
                    <permissions isInheritanceEnabled="false">
                        <ace authority="GROUP_FLOWER_LECTEURS" permission="Consumer" accessStatus="ALLOWED"/>
                        <ace authority="GROUP_FLOWER_COLLABORATEURS" permission="Collaborator" accessStatus="ALLOWED"/>
                    </permissions>
                </directory>
            </directory>
            <directory name="scat1-2">
                <permissions isInheritanceEnabled="false">
                    <ace authority="GROUP_FLOWER_LECTEURS" permission="Consumer" accessStatus="ALLOWED"/>
                    <ace authority="GROUP_FLOWER_COLLABORATEURS" permission="Collaborator" accessStatus="ALLOWED"/>
                </permissions>
            </directory>
        </directory>
        <directory name="cat2">
            <directory name="scat2-1">
                <directory name="sscat2-1-1">
                    <permissions isInheritanceEnabled="false">
                        <ace authority="GROUP_FLOWER_LECTEURS" permission="Consumer" accessStatus="ALLOWED"/>
                        <ace authority="GROUP_FLOWER_COLLABORATEURS" permission="Collaborator" accessStatus="ALLOWED"/>
                    </permissions>
                </directory>
            </directory>
        </directory>
    </rootDirectory>
</flowerDirectories>

Afin de générer l’arborescence à partir du fichier XML déposé dans Alfresco, il suffit d’effectuer l’appel suivant :

GET /alfresco/s/flower/directory-manager

Il est également possible d’exécuter ce WebScript à partir de la console d’admin /alfresco/s/index/family/FlowerDocs.

Le mécanisme d’écriture en Y permet, lors d’une création ou d’une mise à jour de composant, d’écrire les données à la fois dans Alfresco et dans Elasticsearch.

Ce processus est réalisé de manière séquentielle :

  1. 1. écriture dans Alfresco
  2. 2. écriture dans Elasticsearch si la première écriture a abouti

Objectifs

L’objectif direct de l’écriture en Y est de pouvoir stocker, en double, les données dans le moteur de recherche Elasticsearch. Les données stockées dans Elasticsearch peuvent ainsi être utilisées pour :

  1. 1. alimenter des tableaux de bord Kibana
  2. 2. changer le moteur de recherche utilisé (c’est-à-dire remplacer Solr)

Mise en place

De l’écriture en Y

Afin de mettre en place l’écriture en Y, il est nécessaire :

Des recherches Elasticsearch

L’utilisation d’Elasticsearch est facilement activable en ajoutant la propriété core.dao.multi.search.es=true.

Ce mode doit toutefois être activé avec précaution. En effet, la sécurité portée par Alfresco ne peut être directement reflétée dans Elasticsearch. Afin que les résultats de recherche tiennent compte des permissions de lecture, au moins une des propositions suivantes doit être vraie :

  • les ACLs portées par les composants stockées dans Elasticsearch doivent refléter les autorisations de lecture
  • les groupes autorisés en lecture sur un noeud Alfresco doivent être reportés sur le composant stocké dans Elasticsearch et être utilisés comme filtre de recherche


Lorsque l’utilisation d’Elasticsearch est activée pour les recherches, toutes les recherches de composants sont concernées sauf les recherches :

  • utilisées pour déterminer les annotations d’un document
  • comportant un contexte language égal à cmis

Sécurisation par ACL

La sécurisation des résultats de recherche à l’aide du mécanisme natif d’évaluation des ACLs est désactivée par défaut avec l’utilisation du connecteur Alfresco. En effet avec les APIs Alfresco, les résultats de recherche retournés tiennent compte des politiques de sécurités définies. Ce mécanisme n’est donc pas nécessaire.

Pour activer ce mécanisme, la propriété component.search.secure=true doit être ajoutée.

Sécurisation par groupes autorisés

Ce type de sécurisation s’appuie sur les politiques de sécurité définies dans Alfresco. Lors de la création ou de la modification d’un noeud, les groupes autorisés en lecture sont récupérés et ajoutés comme tag durant la deuxième phase d’écriture dans Elasticsearch.


component.tag.cleanup=authorizedGroups
alfresco.node.fieldToTag.authorizedGroup=authorizedGroups


Les changements de sécurité ou modifications apportés directement auprès d’Alfresco doivent être répercutés dans Elasticsearch.

Afin d’identifier les composants concernés par des modifications apportées directement auprès d’Alfresco, il peut être utile de reporter également le chemin de classement des noeuds dans Elasticsearch. Pour cela, la configuration suivante peut être ajoutée :


component.tag.cleanup=authorizedGroups,path
alfresco.node.fieldToTag.path=path