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
    • kibana
      • dashboards
      • searches
      • visualizations
    • scope.xml


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

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

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


    Téléchargement :

    CLM
    (Version : 2.5.0)

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

    Exécution

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

    java -jar flower-docs-clm-2.5.0-bundle.jar

    Pour interagir avec FlowerDocs, 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-2.5.0-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>.


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

    Jobs

    Une liste de jobs est à fournir au CLM afin de lui indiquer les instructions à exécuter. Ces jobs sont à fournir après la commande d’exécution du CLM :

    <clm> job1 job2

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

    Création

    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

    Suppression

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

    <clm> delete --scope=<scope>

    Ré-initialisation

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

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

    Mise à jour

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

    Export

    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, ajoutez 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
    kibana-index-pattern-import
    kibana-search-import kibana-search-merge
    kibana-visualization-import kibana-visualization-merge
    kibana-dashboard-import kibana-dashboard-merge

    En plus de ces opérations, il existe un job permettant de purger les caches de la partie FlowerDocs Core nommé purge-cache.


    Exemple : Import de classes de tags uniquement

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


    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 :

    Paramètre 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 autres 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é 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 entrées est mergée
    • Dans le cas des ACLs proxy : la liste des ACLs proxy est mergée. Si un ACL proxy est présent dans plusieurs modules, il est ignoré ou écrasé suivant la valeur du paramètre force

    Classes de composants

    • La liste des références de tag et des catégories de tag sont mergées
    • 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 dossiers

    • 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

    Kibana

    • La liste des fichiers Kibana est mergée pour chaque type (Dashboard/Recherche/Visualisation)
    • Si un fichier Kibana 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âches 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âches 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éments 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 composants Data
    Actif
    Technique
    Desciptions
    Libellés
    Durée de rétention    		 Référence de tags
    Catégories de tag
    Classes de taches Icône
    processus    		 Réponses
    Pièces jointes
    Classes de dossiers Pièces jointes
    Classes de dossiers virtuels Recherches
    Classes de tags 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 ici

    Démarrer FlowerDocs Manager

    Définition d’un projet GIT

    • Cliquez sur Ajouter un projet Git
    • Renseignez l’URL permettant l’accès au projet Git stockant le template en utilisant le protocole HTTPS
    • Branche : branche Git à cloner

    Clone du projet

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

    Définition d’un environnement

    • Cliquez sur Ajouter un environnement
    • Nom : Nommez l’environnement
    • URL:
      • Renseignez une URL permettant d’accéder au socle de Web Services FlowerDocs
      • exemple : https://flowerdocs.com/core/services

    Déploiement d’un scope

    • Cliquez sur Déployer
    • Nom du scope à créer
    • Sélectionnez un template qui servira de modèle au scope à créer
    • Sélectionnez un environnement sur lequel créer le nouveau scope
    • Mot de passe du compte administrateur FlowerDocs
    • Case à cocher Créer : Si la case est cochée et que le scope existe, il est supprimé puis recréé. Si décochée, le scope est mis à jour.