Intialisation d'un scope

    L’import d’un scope se fait sur la base d’un template servant de modèle à la création d’un nouveau scope. Cette notion de template permet d’initialiser différents scopes basés sur un même template.

    L’emplacement des templates peut être défini en fournissant le paramètre --data.dir=<chemin vers les templates>.


    Un template est un ensemble de fichiers XML dans un répertoire dont le nom est l’identifiant du template. Sa structure s’appuie sur les dossiers suivants :

    → acls

    → classes

    • tag
    • document
    • folder
    • task
    • virtualFolder

    → documents

    → conf

    → folders

    → tasks

    → tagCategories

    → reports

    → virtualFolders

    → workflows

    → facts

    → scope.xml

    Nota : Le dossier conf permet d’isoler les documents techniques (type configuration du LDAP, CSS…)

    Cet outil permet d’interagir avec Flower en ligne de commande. Il offre des fonctionalités :

    • d’import
    • d’export
    • de merge de plusieurs modules
    • d’administration


    Téléchargement :

    CLM
    (Version : 2.4.2.5)

    Nota : Dans cette partie, le dossier d’extraction est appelé ${CLM_HOME}

    Exécution

    Le CLM est un JAR exécutable est peut donc être exécuté avec une commande du type :

    java -jar flower-docs-clm-<span class="version">2.4.2.5</span>-bundle.jar
    

    Pour interagir avec Flower, il est nécessaire de définir l’URL d’accès aux web services ainsi que des identifiants de connexion :

    java -jar flower-docs-clm-<span class="version">2.4.2.5</span>-bundle.jar --ws.url=http://<serveur>:<port>/<contexte>/services	--password=<password>
    

    Par défaut le nom d’utilisateur est system, il peut être modifié en ajoutant le paramètre --USER=<user>.


    Nota : Dans les parties suivantes <clm> désigne la commande permettant d’exécuter le CLM en ligne de commande.

    Jobs

    Le CLM est basé sur une liste de jobs afin de lui indiquer les instructions à exécuter. Ces jobs sont à fournir après la commande d’exécution Flower :

    <clm> job1 job2
    

    Les jobs possibles sont listés dans les parties suivantes.

    Créer un scope

    Le CLM permet la création d’un scope à partir d’un template à l’aide du job create :

    <clm> create --template=<template> --scope=<scope> --admin=<admin>
    


    Paramètres :

    Paramètre Description
    template Identifiant du template (nom du dossier dans lequel il est situé)
    scope Identifiant du scope à créer
    admin Nom de l’utilisateur propriétaire du nouveau scope

    Supprimer d’un scope

    Pour supprimer un scope, il est possible d’utiliser le job delete tel que :

    <clm> delete --scope=<scope>
    

    Ré-initialiser un scope

    Les jobs peuvent être combinés, la ré-initialisation d’un scope peut donc s’effectuer des jobs delete et create :

    <clm> delete create --template=<template> --scope=<scope>
    

    Mettre à jour un scope

    Le job update permet de mettre à jour un scope existant.

    • Les composants présents dans le template et absents du scope initial seront ajoutés.
    • Les composants différents du scope initial seront mis à jour.
    • Les documents présent dans le scope initial et absents du template ne seront pas supprimés.

    Ce job permet par exemple de mettre à jour la configuration d’un scope sans supprimer les documents existants.


    Exemple : Mise à jour du scope RH

    <clm> update --template=simple --scope=RH
    

    Exporter un scope

    L’export d’un scope est possible grâce au job export. Ce job permet la création d’un template à partir d’un scope existant.

    <clm> export --scope=<scope> --template=<template>
    


    Paramètres :

    Paramètre Description
    scope Identifiant du scope à exporter
    template Identifiant du template à créer (nom du dossier dans lequel il est situé)

    Par défaut, le scope sera exporté dans un dossier data du répertoire d’exécution.

    Pour modifier le répertoire où sera stocké l’export, ajouter le paramètre --data.dir=<chemin> à la commande <clm>

    Liste des jobs

    Il est possible d’exécuter seulement une partie des opérations. Ci-dessous la liste complète des opérations possibles :

    Import Export Merge
    scope-import scope-export scope-merge
    tag-category-import tag-category-export tag-category-merge
    tag-class-import tag-class-export tag-class-merge
    document-class-import document-class-export document-class-merge
    folder-class-import folder-class-export folder-class-merge
    task-class-import task-class-export task-class-merge
    workflow-import workflow-export workflow-merge
    virtual-folder-class-import virtual-folder-class-export virtual-folder-class-merge
    acl-import acl-export acl-merge
    technical-document-import technical-document-export technical-document-merge
    document-import document-export document-merge
    folder-import folder-export folder-merge
    virtual-folder-import virtual-folder-export virtual-folder-merge
    task-import task-export task-merge
    facts-import facts-merge
    report-import report-export report-merge

    En plus de ces opérations, il existe une opération purge-cache pour purger les caches de la partie core.


    Exemple : Import de classes de tag uniquement

    <clm> tag-class-import --scope=RH
    


    Le paramètre force permet de déterminer le comportement à adopter en cas de conflits entre les éléments de plusieurs modules :

    • true : les éléments présents dans un module écrasent les éléments du scope initial
    • false (par défaut) : les éléments présents dans un module sont ignorés s’ils sont présents dans le scope initial

    L’ordre suivi est l’ordre passé en entrée du CLM.

    Exécution

    Le CLM offre la possibilité de merger plusieurs scopes.

    <clm> merge --template=<template> --modules=<module1>,<module2>
    


    Paramètres :

    Propriété Obligatoire Description
    template Oui Identifiant du template à construire (nom du dossier de sortie)
    modules Oui Nom des templates à merger séparés par des virgules
    force Non true ou false (par défaut : false)

    Règles de merge

    D’une manière générale le merge suit les règles suivantes :

    • Si un élément est présent dans un scope et absent dans un autre, il sera présent dans le scope mergé
    • Si un élément est présent dans plusieurs scopes : ** Certains sous-éléments sont mergés (cf règles détaillées ci-dessous) ** Les autre propriétés sont soit ignorées soit écrasées si définies, suivant la valeur du paramètre force

    Scope

    Merge des données présentes dans le fichier scope.xml.

    Le merge est effectuée comme suit :

    • Si un profil est présent dans plusieurs modules, la liste des identités et des propriétés est mergée
    • 2 propriétés avec le même nom mais des valeurs différentes sont vues commes des objets différents

    ACLs

    • La liste des entries est mergée
    • Dans le cas des ACLs proxy : la liste des ACLs proxy est mergée. Si une ACL proxy est présente dans plusieurs modules, elle est ignorée ou écrasée suivant la valeur du paramètre force

    Classes de composant

    • La liste des références de tag et des catégories de tag sont mergée
    • Si une référence de tag est présente pour une même classe dans plusieurs modules, elle est ignorée ou écrasée suivant la valeur du paramètre force

    Classes de tâches

    • La liste des pièces jointes et des réponses sont mergées
    • Si une pièce jointe est présente pour une classe dans plusieurs modules, elle est ignorée ou écrasée suivant la valeur du paramètre force
    • Si une réponse est présente pour une classe dans plusieurs modules, elle est ignorée ou écrasée suivant la valeur du paramètre force

    Classes de dossier

    • La liste des pièces jointes est mergée
    • Si une pièce jointe est présente pour une classe dans plusieurs modules, elle est ignorée ou écrasée suivant la valeur du paramètre force

    Classes de dossiers virtuels

    • La liste des recherches est mergée
    • Si une recherche est présente pour une classe dans plusieurs modules, elle est ignorée ou écrasée suivant la valeur du paramètre force

    Classes de tags

    • Si une classe de tags de type “Liste de choix” est présente dans plusieurs modules, les listes de valeurs sont mergées
    • Les listes de valeurs conditionnelles ne sont pas mergées.

    Composants

    • La liste de tags est mergée
    • Si un tag est présent pour un même composant dans plusieurs modules, sa valeur est ignorée ou écrasée suivant la valeur du paramètre force

    Documents

    • Si un document est présent dans plusieurs modules, son contenu est ignoré ou écrasé suivant la valeur du paramètre force

    Dossiers

    • Si un dossier est présent dans plusieurs modules, la liste des pièces jointes est mergée

    Tâches

    • Si une tâche est présente dans plusieurs modules, Les listes des pièces jointes et des participants sont mergées

    Catégories de tag

    • Si une catégorie est présente dans plusieurs modules, la liste des tags est mergée

    Processus

    • Si un processus est présent dans plusieurs modules, la liste des classes est mergée
    • Les autres propriétés du processus, notamment la première étape, sont ignorées ou écrasées suivant la valeur du paramètre force

    Rapports

    • La liste des rapports est mergée
    • Si un rapport est présent dans plusieurs modules, il est ignoré ou écrasé suivant la valeur du paramètre force

    Faits

    • La liste des faits est mergée
    • Si un fait est présent dans plusieurs modules, il est ignoré ou écrasé suivant la valeur du paramètre force

    Exemple

    Le scope GEC contient une classe de tâche CourrierATraiter avec une pièce jointe de type Courrier entrant. La propriété icone est définie à icone_A.

    Le scope CourrierSortant contient une classe de tâche CourrierATraiter avec une pièce jointe de type Courrier sortant. La propriété icone est définie à icone_B.


    Le merge est effectué dans l’ordre GEC-CourrierSortant.


    Dans tous les cas, en sortie du merge, la classe CourrierATraiter aura en pièce jointe Courrier entrant et Courrier sortant, car la liste des pièces jointes est mergée.

    Si le paramètre force est false, l’icone sera définie à icone_A

    Si le paramètre force est true, l’icone sera définie à icone_B

    Synthèse

    Objet Propriétés surchargées / ignorées Sous-élément mergés
    Scope Data
    Description
    Libellés
    Langages
    Unité organisationnelle
    Fichier de règles
    Profils (cf ligne “Profils”)
    Profils Description
    Nom
    Identités
    propriétés
    ACLs Description
    Nom
    Entrées
    Toute classe de composant Data
    Actif
    Technique
    Desciptions
    Libellés
    Durée de rétention
    Référence de tags
    Catégories de tag
    Classes de tache Icône
    processus
    Réponses
    Pièces jointes
    Classes de dossier Pièces jointes
    Classes de dossier virtuel Recherches
    Classes de tag Data
    Libellés
    Pattern
    Recherchable
    Type
    Listes de valeurs
    Tout composant Data
    Nom
    Tags
    Dossiers Pièces jointes
    Taches Assigné à
    Réponse
    Processus
    Pièces jointes
    Participants
    Documents Contenu
    Version
    Libellé de version
    Id de version
    Type mime
    id parent
    Catégories de tag Libellés
    Description
    Icône
    Replié
    Aligné
    Visible
    Tags
    Processus Libellés
    Description
    Première étape
    Style
    Classes
    Rapports Toutes
    Faits Toutes

    Prérequis Projet Git

    • accès à un projet Git avec une authentification par login/mot de passe
    • le projet contient un ou plusieurs dossiers contenant des templates de scope ayant la structure indiquée ci-dessus

    Démarrer Flower Manager

    • Récupérer le JAR
    • Ouvrir un terminal et tapper la commande :

      java -jar flower-docs-manager-<span class="version">2.4.2.5</span>.jar
      
    • Ouvrir un navigateur et se rendre sur http://localhost:2503/flower-manager/

    Définition d’un projet GIT

    • Cliquer sur Ajouter un projet Git
    • Renseigner l’URL permettant l’accès, grâce au protocole HTTPS, au projet Git stockant le template
    • Branche : branche Git à cloner

    Clone du projet

    • Cliquer sur Projets
    • Cliquer sur Cloner sur la ligne du projet à cloner
    • Renseigner l’utilisateur et le mot de passe permettant de cloner le projet
    • Cliquer sur Cloner
    • Si le projet a bien été cloné, les templates associés sont visible dans l’onglet Templates

    Définition d’un environnement

    • Cliquer sur Ajouter un environnement
    • Nom : Nommer l’environnement
    • URL:
      • Renseigner une URL permettant d’accéder au socle de Web Services Flower
      • exemple : https://flowerdocs.com/core/services

    Déploiement d’un scope

    • Cliquer sur Déployer
    • Nom du scope à créer
    • Sélectionner un template qui servira de modèle au scope à créer
    • Sélectionner un environnement sur lequel créer le nouveau scope
    • Mot de passe du compte administrateur FlowerDocs
    • Case à cocher Créer : Si cochée, le scope est supprimé si existant puis recréé. Si décochée, le scope est mis à jour.