Category Archives: Blog

Article de blog

17Mai/19

[Infographie] Domaines d’expertise de bluexml

Cliquez ci-dessous sur le domaine qui vous intéresse pour en savoir plus.

Cette infographie présente nos domaines d’expertise ainsi qu’un focus sur les outils et partenaires avec lesquels nous collaborons.

 





Si vous souhaitez d’autres informations ou si vous êtes intéressé par l’un de ses outils, nous vous invitons à nous contacter via le formulaire ci-dessous :

 

14Mai/19

Bluexml et la supervision  : Supervizing Alfresco

Description

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-05-06 à 16.49.17.png

Supervizing Alfresco fournit des indicateurs fonctionnels aux responsables de sites et aux administrateurs de la plateforme, pour faciliter le suivi et l’animation des sites collaboratifs, et des indicateurs techniques pour contrôler le fonctionnement des services Alfresco. Selon leur rôle dans l’organisation, les agents ont différents besoins :

  • Les cadres ont besoin d’informations sur l’utilisation du système, son évolution dans le temps, par typologie et sur tous différents axes possibles (volume de stockage, nombre de documents) pour justifier d’éventuels investissements qui contribueront à améliorer l’efficacité du système pour répondre aux besoins de l’organisation ;
  • Les agents en charge de l’administration fonctionnelle et du support aux utilisateurs de l’application de dématérialisation ont besoin d’informations leur permettant de mieux comprendre les problèmes, leur typologie, leur origine afin de justifier d’éventuels développements pour faciliter leur tâche et améliorer l’expérience utilisateur ;
  • Les agents en charge de l’exploitation du système ont besoin d’informations leur permettant de diagnostiquer certains problèmes techniques et de faciliter la communication avec les équipes de TMA.

Supervizing Alfresco vous fournit ainsi différents tableaux de bord en fonction de vos droits :

  • Indicateurs fonctionnels : nombre et volume de stockage des documents métiers (cf figure 1), nombre des documents en cours de dématérialisation – qualifiés et non classés (cf figure 2) ;
  • Indicateurs d’administration fonctionnelle : nombre d’erreurs (cf figure 3), d’anomalies ;
  • Indicateurs techniques d’exploitation : quantité de ressources utilisées – mémoire, CPU (cf figure 4), logs.

Ces indicateurs peuvent être déclinés par service, dans le temps… afin d’affiner l’analyse et identifier les problèmes, leur origine. En outre, en centralisant les logs issus des différents éléments de l’architecture, le diagnostic des problèmes est facilité, contribuant à fournir un service plus efficace.

Indicateurs fonctionnels

Une image contenant capture d’écran, moniteur, intérieur, mur Description générée automatiquement

Figure 1  : Activité des documents “finance”

Une image contenant capture d’écran, moniteur, intérieur, mur Description générée automatiquement

Figure 2  : Nombre de documents en cours de dématérialisation (qualifiés et non classés)

Indicateurs fonctionnels d’administration

Une image contenant moniteur, capture d’écran, intérieur, ordinateur Description générée automatiquement

Figure 3  : Documents en erreur

Indicateurs techniques

Une image contenant moniteur, intérieur, mur, horloge Description générée automatiquement

Figure 4  : Ressources du serveur d’application

Fonctionnalités

STATISTIQUES FONCTIONNELLES

FONC_1 – NOMBRE DE DOCUMENTS EXISTANTS

STATISTIQUES D’ADMINISTRATION

ANOMALIES

ANO_1 – NOMBRE DE DOCUMENTS EN ATTENTE DE CLASSEMENT

ANO_2 – NOMBRE DE DOCUMENTS EN ERREUR

PROCESSUS

PROCESS_1 – DEMAT – DOCS ENTRANTS

PROCESS_2 – DEMAT – DOCS QUALIFIES

PROCESS_3 – DEMAT – DOCS CLASSES

PROCESS_4 – DEMAT – DOCS NON CLASSES

PROCESS_5 – FINANCE – SUIVI DES FACT.

PROCESS_6 – RH – NOMBRE DE DOCS.

RECHERCHE

RECHERCHE_1 – RECHERCHES

STATISTIQUES D’EXPLOITATION

PLATEFORMES ALFRESCO

EXP_SRV_1 – CHARGE PROCESSEUR.

EXP_SRV_2 – CHARGE MEMOIRE.

EXP_SRV_3 – CHARGE DISQUE.

EXP_SRV_4 – ESPACE DISQUE DISPONIBLES.

SERVEUR D’APPLICATION

EXP_APP_1 – CHARGE PROCESSEUR.

EXP_APP_2 – CHARGE MEMOIRE.

EXP_APP_3 – AJP – DISPONIBILITES.

EXP_APP_4 – AJP – TEMPS DE TRAITEMENTS.

EXP_APP_5 – TEMPS DE DISPONIBILITE.

EXP_APP_6 – SUIVI DES JOURNAUX.

EXP_APP_7 – NB DE SESSIONS OUVERTES.

EXP_APP_8 – DUREE MOY. DES SESSIONS.

SERVEUR BASE DE DONNEES

EXP_BDD_1 – CHARGE PROCESSEUR.

EXP_BDD_2 – CHARGE MEMOIRE.

EXP_BDD_3 – ESPACE DISQUE DISPONIBLE.

30Avr/19

(3/3) Analyse d’une politique documentaire : cas client

Etude fonctionnelle : Politique documentaire

A partir des éléments injectés dans ELK, on peut également obtenir un export csv répondant à la requête. On peut ainsi reconstruire pour chaque source un fichier csv avec la liste des 3 premiers niveaux d’arborescence et extraire automatiquement une carte cognitive. Cette dernière facilite la communication et permet une analyse “a priori” puis un travail de reconstruction avec un spécialiste métier.

On a ainsi les images Avant/Après facilitant la conduite du changement et la mise en oeuvre d’un plan d’actions.

L’étude porte ainsi sur les éléments suivants :

  • M: Lecteur réseau organisationnel : contient des répertoires pour chaque service de l’organisation ;
  • N: Lecteur réseau commun : contient des répertoires pour chaque projet ou élément commun à l’organisation ;
  • O: Serveur Alfresco : contient les répertoires pour chaque nouveau projet ou chaque nouvel élément commun qui est basculé sur le serveur Alfresco. Les éléments organisationnels sont aussi peu à peu basculés sur Alfresco.

M: Lecteur Organisationnel

Les premiers niveaux d’arborescence sur un serveur réseau “organisationnel” correspondent généralement aux niveaux suivants :

  • Direction
  • Département
  • Service…

Arborescence

On peut extraire ce genre de carte :

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-09 à 11.33.21.png

Eléments communs

On trouve normalement des éléments liés à l’organisation de la direction/service/cellule, à la gestion opérationnelle des personnels associés (RH, formation, règlement intérieur…) :

  • Plannings
  • Congés
  • Compte-rendus
  • Modèles
  • Outils
  • Processus

Conclusion

A la lecture des plans de classement, on constate souvent des anomalies de ce type :

  • Trop d’éléments, rendant la compréhension difficile ;
  • Des références à des personnes (via leur nom, leur prénom) empêchant un stockage mutualisé des informations ;
  • Des références à des événements précis (via la date d’une journée), empêchant le stockage d’éléments ultérieurs ;
  • Des noms mêlant une information et une année, empêchant une déclinaison naturelle sur plusieurs années
  • Des noms correspondants à des types de fichiers, obligeant à parcourir le répertoire pour connaître son contenu

N: Lecteur commun

Désolé, cette section est n’est pas reproduite car les éléments issus d’une réelle étude client sont trop nombreux pour être anonymisés correctement.

O : Serveur Alfresco

Arborescence

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-09 à 11.35.07.png

L’arborescence ci-dessus a été construite en regroupant manuellement les éléments. En effet, le concept de site ne supporte pas les hiérarchies qu’on reproduit généralement à l’aide de conventions de nommage.

Bonnes pratiques : les préconisations

On reprend les anomalies précédentes et on liste les solutions possibles :

Trop d’éléments gêne la visibilité

Afin de permettre une navigation fluide et pertinente, il faut respecter les règles suivantes la compréhension, la mémorisation :

  • Eviter plus de 20 éléments par répertoire
  • Créer des sous-répertoires pour regrouper les éléments par thèmes/sous-thèmes
Eviter les références aux éléments susceptibles de changer

Ce sont les personnes qui changent le plus dans les organisations. Ainsi, il faut éviter les noms et/ou prénoms dans les noms de répertoires (Michel, Stéphanie…) car lorsque la personne s’en va, il est difficile de savoir si les données sont privées, quels sont les thèmes concernés, ce qu’il faut garder, jeter… C’est le genre de répertoire qu’on retrouve plusieurs années après le départ de la personne…

Isoler les années

Il faut éviter de nommer un répertoire en ajoutant une année, caractéristique des événements, car cela bloque les regroupements automatiques. Si l’événement est amené à se reproduire, alors faire un répertoire du nom de l’événement puis un répertoire avec les années. Le fait d’isoler l’année permettra de consolider les données au niveau tranverse.

Ne pas utiliser de répertoires explicitant le type des fichiers

Cette information peut être obtenue automatiquement par la GED en se basant (en partie) sur le suffixe du fichier, il n’est donc pas nécessaire de l’expliciter et lui préférer un répertoire porteur de sens.

Donner du sens

Il est plus facile de mémoriser une arborescence porteuse d’une logique métier, que l’utilisateur manipule tous les jours de manière implicite, plutôt qu’une succession de tâches qui peuvent être très variées. L’arborescence devient du coup dure à comprendre et à suivre avec le risque que des répertoires redondants soient créés.

Conclusions

Revoir les PDC en fonction des règles ci-dessus et faire des préconisations pour chaque service département, service, mission, projet… Attention, le traitement de répertoires correspondant à des unités organisationnelles complexes (avec plusieurs centaines de milliers de fichiers) sera plus long que les répertoires d’une simple unité organisationnelle (avec quelques centaines voire milliers de fichiers au maximum).

Conclusion

L’utilisation d’un système d’indexation est fondamentale pour vous aider à connaître votre système documentaire, pour l’améliorer et vous aider à la conduite du changement en identifiant les sources de gaspillage et les pistes d’amélioration.

Afin d’avoir un véritable système outil de supervision et de pilotage de votre SI documentaire, il est nécessaire de mettre en place une collecte continue des informations seul moyen qui permettra d’obtenir un outil de supervision en temps réel de votre SI documentaire.

 

Suivez bluexml sur les réseaux sociaux

24Avr/19

(2/3) Analyse d’une politique documentaire : cas client

Etude technique : indicateurs

Généralement, les indicateurs attendus sont les suivants :

  • Répartition et évolution des documents en nombre et volume
  • Comprendre les pics de création de documents
  • Répartition des documents en fonction de l’organisation (DGA/Pôle/Département ou Service…)
  • Répartition des documents par type de fichiers (extension)

L’indicateur supplémentaire suivant, plus complexe à calculer, est souvent attendu :

  • Recherche de doublons

Phase1 : répartition et évolution

Evolution du nombre total de documents et de leur volume par serveur

Le stockage est actuellement réalisé sur 3 composants :

  • Lecteur réseau M : (Organisationnel)
  • Lecteur réseau N : (Commun)
  • Lecteur 0 : (Serveur Alfresco)

Le nombre de documents augmente constamment sur chaque composant alors qu’on pourrait s’attendre à voir diminuer ce nombre sur les serveurs réseaux au profit du serveur Alfresco. Au contraire, on constate même que le nombre de documents augmente plus vite sur le lecteur réseau « Organisationnel ».

Alfresco est vraisemblablement utilisé pour répondre à d’autres besoins, notamment des besoins collaboratifs.

Répartition des documents en nombre et en volume entre les différents serveurs

Evolution mensuelle du nombre de création de documents et de leur taille moyenne quelle que soit l’origine des documents

En cliquant sur un point précis, on peut avoir l’explication de sa valeur avec le détail des éléments ayant permis son calcul, comme la liste des documents comptabilités. On s’aperçoit ainsi que les pics de création de documents correspondent à des imports en grand nombre d’éléments de taille importante venant par exemple de la direction technique ou de la communication.

Répartition du nombre de documents par Niv1 (DGA) x Niv2 (Pôle) x Niv3 (Direction…)

Répartition des documents en fonction du nombre et du volume selon leur extension

 

Phase 2 : Recherche des doublons

Plusieurs solutions sont possibles :

  • lister les fichiers avec le même nom et regarder par la suite si les documents sont identiques (même taille et même md5). Le hash md5 peut être long à calculer sur des millions de fichiers, cette approche n’est pas toujours envisagée ;
  • lister les fichiers avec le même nom et la même taille en une seule passe et vérifier par la suite s’ils ont la même taille.

Cette seconde approche est souvent plus simple et plus rapide à mettre en oeuvre.

Script

La requête suivante sur ELK permet de récupérer tous les fichiers de plus de 10K dont le nom et la taille sont identiques. Pour garantir qu’il s’agit de doublons, il faudrait utiliser un hash md5 mais à défaut de celui-ci cela permet d’avoir une forte présomption de doublon.

 

Sur cette base, on peut obtenir un fichier json, qui peut être converti en csv, avec finalement les résultats suivants :

  • Nombre de fichiers > 10 Ko étudiés avec le même nom et la même taille : 10 000 fichiers
  • Nombre de résultats : 309 173
  • Nombre de répétitions : 16 à 2432 (situation.xls)
  • Place occupée : 1 835 Mo
  • Place optimale : 115 Mo

La taille est multipliée par 15, le nombre de fichiers par 35, ce qui entraîne un gaspillage de ressources, de temps et de maintenance et risque de se traduire par la conservation ‘ad vitam’ de centaines de milliers (pour ne pas dire plusieurs millions) de fichiers redondants…

Les 25 plus grandes répétitions quelle que soit la source

Dans notre cas d’utilisation, on ne connaît que les noms de fichiers, mais pas la source. Pour cela, il faudrait faire une requête supplémentaire sur chaque nom afin de savoir comment il se répartit sur chaque racine.

Le nom des fichiers répétés permet de se faire une idée des fichiers redondants.

Les 25 plus grands gaspillages

Conclusion

L’analyse des doublons est un peu “laborieuse” (données à nettoyer). Un indicateur intéressant serait de calculer la répartition des doublons d’un même fichier sur différentes sources afin de mieux comprendre le mécanisme de propagation et mettre en place des actions pour modifier les comportements.

 

Suivez bluexml sur les réseaux sociaux

 

16Avr/19

(1/3) Analyse d’une politique documentaire : cas client

Préambule

Ce billet de blog vous présente le travail réalisé pour un client institutionnel dans le cadre d’une mission d’analyse de leur politique documentaire.

Ce billet se décompose en 3 parties :

  • Présentation de l’objectif, du contexte et de la démarche
  • Présentation de l’étude technique avec une partie des indicateurs obtenus
  • Présentation de l’étude fonctionnelle avec une partie des arborescences

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-09 à 11.49.26.png

 

Introduction

L’objectif de l’audit est de réaliser une analyse des contenus stockés dans leur fonds documentaire dans leur totalité (environ 20 To) :

  • un serveur de fichiers Windows, organisationnel (avec les contenus de chaque direction) ;
  • un serveur de fichiers Windows, communs (avec les contenus transverses) ;
  • un serveur de GED Alfresco (avec les contenus collaboratifs).

Cette analyse s’effectue généralement en collaboration avec la DSI et se décompose en 2 parties :

  • une étude technique des contenus stockés sur les différents composants ;
  • une étude fonctionnelle de ces contenus.

Démarche

L’objectif est de lister tous les fichiers contenus dans les systèmes ci-dessus, en récupérant les métadonnées disponibles dans un fichier au format csv. Le nombre de fichiers étant considérable, cette collecte est découpée en plusieurs sous-ensembles afin de ne pas surcharger le système lors de la récupération de ce listing. En outre, afin de pouvoir analyser les contenus extrêmement nombreux (plusieurs millions de ligne), un tableur n’est pas suffisant, il est ainsi prévu d’indexer et rechercher les contenus à l’aide de l’outil spécialisé Elasticsearch (ELK) de la société éponyme.

 

Listing au format csv

Liste des fichiers

Deux scripts ont été écrits en powershell 2 afin de permettre la récupération de ces éléments sur Windows :

  1. Un premier script liste les éléments principaux de premier niveau (c’est à dire les sous-répertoires) du répertoire passé en paramètre et appelle un deuxième script pour chacun des sous-répertoires principaux identifiés ;
  2. Le deuxième script liste tous les fichiers contenus dans le répertoire principal ou un de ses sous-répertoires.

Le premier script pilote le deuxième script. Le premier script a été lancé à la main à des moments propices (soirée, veille de we) pour éviter de trop surcharger le système pendant l’exploitation quotidienne.

Le fichier csv ressemble à ceci :

En parallèle du lancement des scripts de comptage, il faut également lancer la fonction de Windows permettant de compter le nombre et le volume des fichiers et répertoires pour un répertoire donné.

Erreurs

Certaines erreurs apparaissent :

  • répertoires inaccessibles, pour des raisons de droits ;
  • répertoires ou fichiers avec un nom trop long ;
  • répertoires ou fichiers avec des caractères interdits.

Dans l’absolu, il faudrait traiter ces erreurs. Cependant, un comptage a été fait en parallèle par le système Windows et comparé au nombre de répertoires et fichiers trouvés via les scripts ci-dessus. La différence n’est pas significative et on peut simplement ignorer ces erreur.

 

Injection dans le système d’indexation ELK

Le système d’indexation ELK facilite le comptage et le regroupement des données en fonction des indicateurs souhaités afin de faciliter le calcul des éléments techniques mais aussi l’étude du fonds documentaire.

ELK est un système d’indexation de contenus basé sur 3 composants :

  • Logstash pour la récupération et l’analyse des données en amont, en l’occurrence les fichiers csv générés par les scripts précédents ;
  • Elasticsearch, pour l’indexation des données ;
  • Kibana, pour la navigation dans les données.

Traitement et import des données

Logstash permet le traitement et l’import des données afin d’extraire toutes les informations souhaitées. Par exemple, l’extraction de la source de données (Lecteur M: dans notre cas) ou la conversion de la taille des documents en Ko afin de faciliter la lecture. Attention à bien conserver toutes les données afin de pouvoir les réutiliser si nécessaire.

Requête et comptage

Elasticsearch permet la création de requêtes pour extraire et compter le nombre de fichiers comme par exemple compter le nombre de documents par source ou leur taille.

La requête suivante permet par exemple de ne compter que les documents respectant certaines contraintes :

 

Tableaux de bord

Kibana permet la création de tableaux de bords, notamment avec la fonctionnalité TimeLion permettant de calculer et afficher des indicateurs sur le même graphique afin, par exemple, de comparer l’évolution du nombre de documents dans le temps en fonction de leur source.

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-08 à 16.48.56.png

 

Comptages des répertoires et fichiers par source

Lorsque tous les éléments ont été injectés dans le moteur d’indexation, on compare alors les éléments obtenus entre le comptage Windows et le comptage ELK afin de vérifier que les erreurs ne sont pas significatives.

 

M:\Organisationnel

Les comptages sont les suivants :

Répertoire principal Nb de répertoires Nb de fichiers Volume
Total comptage listing via le calcul de Windows 1 309 910 10 798 669 16,1 To
Total comptage index 1 305 950 10 171 949 17,1 To

 

N:\Commun

Les comptages sont les suivants :

Répertoire principal Nb de répertoires Nb de fichiers Volume
Total comptage listing via le calcul de Windows 581 770 3 402 133 3,45 To
Total comptage index 564 576 3 089 141 3,64 To

O:\Alfresco

Un lecteur réseau a été monté sur le serveur Alfresco afin de pouvoir lister les fichiers stockés à la racine et dans les sites. Dans notre étude de cas, du fait du faible stockage et du faible nombre des éléments stockés en dehors des sites, qui représentent à peine 10 Go et quelques milliers de fichiers, ils n’ont pas été importés et ont été ignorés dans l’analyse.

Répertoire principal Nb de répertoires Nb de fichiers Volume Remarques
Total comptage index 50 113 295 702 781 Go 115 sites

 

 

Suivez bluexml sur les réseaux sociaux

19Oct/18

Pourquoi Alfresco abandonne Alfresco Share au profit d’ADF ?

ADF ou Alfresco/Application Development Framework est le nouvel outil d’interface mis à disposition par Alfresco. Il vise, à terme, à remplacer la solution d’interface “Alfresco Share”, actuellement distribuée avec Alfresco, qui est en cours d’abandon. Les cycles de vie des produits Alfresco et Alfresco Share ayant été dissociés, Alfresco Share sera quand même disponible sur les prochaines versions d’Alfresco mais n’évoluera plus.

Alfresco Share est un outil générique de gestion documentaire, avec de nombreuses fonctionnalités pas toujours utiles aux utilisateurs. Il peut être jugé, à raison, complexe et ne facilite pas la conduite du changement. En outre, basé sur des technologies “maison” telles que Surf ou abandonnées telles que Y!UI (Yahoo) et Dojo (un vieux projet IBM), il est difficile de trouver des compétences pour l’adapter.

A la lumière de tous ces éléments, Alfresco a choisi d’adapter sa stratégie et propose ainsi un nouveau framework basé sur Angular, technologie récente, supportée par un géant de l’internet, assurant une disponibilité importante de compétences. En outre, ce framework est constitué d’un ensemble de composants fonctionnels, qu’il est possible d’assembler en fonction des besoins des utilisateurs.

ADF permet de développer des outils qui s’adaptent aux besoins des utilisateurs et non l’inverse. La conduite du changement sera ainsi facilitée.

ADF se base sur le framework Angular 5, qui lui apporte beaucoup de flexibilité au niveau des fonctionnalités ainsi qu’une bonne adaptabilité par rapport au support de visualisation (PC, tablette ou téléphone).

ADF est un projet open-source et profite d’une communauté très active sur internet.

 

06Juil/18

Créons une application métier avec Flowable

1 – Préambule

Flowable est un outil de BPM, acronyme de Business Process Management, c’est à dire la Gestion des Processus Métiers, ce qui parle tout de suite plus 😉
De manière schématique, c’est une palette d’outils destinés à des utilisateurs métier (spécialistes fonctionnels) pour qu’ils décrivent leurs processus métier, qui peuvent être aussi simples et usuels qu’une demande de congés que complexes et uniques comme un diagnostic de panne pour un avion. A partir de la modélisation réalisée, selon les outils, on obtient automatiquement une application de gestion des tâches permettant de saisir des données dans des formulaires pour démarrer un processus, visualiser le processus et son état d’avancement, réaliser une tâche… Des outils complémentaires permettent généralement d’analyser les processus et de produire des statistiques fonctionnelles, techniques, d’exploitation afin de les suivre, les auditer, de mieux comprendre leur fonctionnement et de les optimiser dans une approche itérative d’amélioration progressive continue.

Flowable est un fork d’Activiti et présente le même périmètre fonctionnel que Bonita, Intalio, W4 qui sont ses principaux concurrentes… Les grands éditeurs comme IBM, Microsoft… ont également leur outil.
La quasi-totalité des logiciels qui appartiennent au domaine du BPM travaillent sur le standard de formalisation BPMNv2 (BPM Notation). Ces logiciels permettent de créer, éditer, importer, exporter des processus au format BPMNv2, c’est à dire respectant une notation standardisée permettant d’échanger les éléments entre les outils. Comme nous le verrons, un processus est également constitué de formulaires, tables de décision… qui ne font pas obligatoirement partie de la notation BPMNv2 et qui feront que, dans la pratique, on ne récupère qu’une partie des éléments constituant un projet.

2 – Introduction

Notre objectif est de créer un premier processus de gestion de demande de congés dans le cadre de l’informatisation du périmètre fonctionnel RH. Nous créerons par la suite d’autres processus RH qui viendront s’ajouter à notre bibliothèque.

Les outils de BPM permettent généralement de définir les éléments suivants :

  • Le(s) processus proprement dit permettant d’exprimer la circulation des informations, données et documents ;
  • Le(s) formulaire(s), permettant de saisir et afficher des données, joindre des documents ;
  • La(es) table(s) de décision permettant à partir de critères basées sur des valeurs issues du processus, de formulaires, de référentiels externes de calculer une conclusion….
  • L’application, donnant accès, en fonction de vos droits, aux processus accessibles dans le cadre d’un module ainsi qu’aux tâches à réaliser pour l’utilisateur connecté.

A l’issue de ce tutoriel, vous serez capable de créer un processus et l’utiliser avec d’autres acteurs, indépendamment de tout autre élément logiciel. Un BPM peut généralement fonctionner de manière totalement autonome. Il n’a pas besoin d’une GED par exemple.

Il est cependant clair qu’associé à une GED, un outil de BPM permet de construire une solution très puissante puisqu’on bénéficie alors des fonctionnalités d’indexation, de recherche, de transformation documentaire, de partage particulièrement bien développées dans les GED.

On a bien ainsi :

1 (GED) + 1 (BPM) = 3

Bien sûr, je pars du principe que Flowable est installé et initialisé. L’installation et l’initialisation ont fait l’objet d’un autre tutoriel.

3 – Demande de gestion de congés

3.1 -Analyse

L’analyse consiste à réaliser les étapes suivantes :

  • étude de l’existant
  • rédaction des spécifications

3.1.1 -Existant

J’ai la demande de congés suivante :

Elle est basée sur un fichier Excel et permet simplement de saisir les dates de début/fin et le type de congés souhaité.

Le processus de validation consiste à l’envoyer par mail à l’adresse rh@xxx.com qui s’occupe alors de la traiter et de renvoyer la réponse au demandeur initial.

3.1.2 -Spécifications

La demande de congés est initialisée par le demandeur. L’objectif est de réaliser la gestion de cette demande de manière complètement dématérialisée en la passant d’acteurs en acteurs, chacun réalisant les tâches qui lui incombent à travers une application spécialisée.

Cette approche pilotée par les processus pourrait dans un second temps être rematérialisée afin de faciliter la consultation, le partage, l’archivage…

De manière très succincte :

  • l’initiateur remplit un formulaire de demande ;
  • il saisit son service, les dates de début et de fin, le type de congés… ;
  • lorsqu’il valide sa demande, le responsable destinataire est automatiquement déduit en fonction de son service d’appartenance ;
  • ce responsable approuve ou rejette la demande ;
    • si elle est rejetée, un commentaire doit être ajouté et la demande est renvoyée à l’initiateur qui la corrige ;
    • si elle est approuvée, elle doit passer alors par le responsable RH ;
  • la demande suit alors le même circuit que précédemment :
    • si elle est rejetée, un commentaire doit être ajouté et la demande est renvoyée à l’initiateur qui la corrige ;
    • si elle est approuvée, un mail est envoyé à l’initiateur tandis que le service RH enregistre la demande.

3.1.3 -Roadmap

L’objectif est d’avoir une première version le plus rapidement possible en utilisant les fonctionnalités par défaut de Flowable. Ainsi, la roadmap est la suivante :

  • v1, le processus est piloté par Flowable ;
  • v2, les informations précédemment saisies sont déterminées automatiquement à partir de l’utilisateur et d’un référentiel externe ;
  • v3, le processus est rematérialisé sous la forme d’un document PDF stocké et classé automatiquement dans Alfresco afin de permettre la constitution d’un dossier agent ;
  • v4, le processus peut être piloté par la GED.

3.2 – Réalisation

La réalisation suit les étapes suivantes :

  • Modélisation du processus
  • Définition des formulaires
  • Définition des tables de décisions
  • Finalisation du processus
  • Configuration de l’application

3.2.1 -Modélisation du processus

Nous allons créer plusieurs versions de ce processus dans le cadre d’une suite de tutoriels afin de montrer la démarche de modélisation.

Connectez-vous sur http://localhost:8080/flowable-modeler/ avec un compte utilisateur qui a les privilèges de « modeleurs ».

Cliquez sur Créer un processus et reproduisez le processus suivant :

Rien ne vaut une bonne séance d’essais/erreurs, vous verrez que ça vient vite 😉

Ce travail correspond à une démarche de modélisation et s’appuie sur les étapes suivantes :

  • Circulation de l’information ;
  • Formulaire de saisie des informations ;
  • Tables explicitant les critères de décision et les déductions à faire.
3.2.1.1 -Circulation de l’information

Cette étape de modélisation consiste à dessiner le circuit que l’information doit suivre pour passer d’une étape à l’autre.

Le risque n°1 est de sur-modéliser : tout excité par la possession d’un nouvel outil qui semble vous permettre de tout faire, vous risquez de modéliser des cas qui n’arriveront que rarement. Jouez plutôt la carte de la simplicité en vous concentrant sur les 80 % de fonctions que vous pouvez atteindre avec 20 % de l’effort.

Pensez en outre que si vous êtes dans une démarche de dématérialisation, vous n’avez vraisemblablement rien pour le moment, donc toute réalisation est déjà un plus . Soyez donc raisonnable et ne visez pas trop haut au risque de vous retrouver dans un tunnel très rapidement…

Ceci étant dit, je vous invite à suivre les étapes suivantes :

  • Cliquez sur l’événement de démarrage (start event) et donnez-lui un nom correspondant à sa fonction : Demande initiale de congés
  • Cliquez et déplacez l’événement de fin (end event)
  • Cliquez, déplacez puis déposez les activités correspondantes à des actions faites par les utilisateurs :
    • Validation N+1
    • Correction demande de congés
    • Validation N+2
  • Cliquez, déplacez puis déposez les « exclusive gateways » (pour les conditions) permettant d’avoir une ou plusieurs transitions en sortie d’une activité :
    • Une gateway après Validation N+1
    • Une gateway après Validation N+2

3.2.2 -Formulaires

Cette étape de modélisation consiste à dessiner les formulaires de saisie que les utilisateurs vont devoir remplir en fonction de l’avancement du processus.

On retrouve un formulaire pour l’étape de démarrage ainsi qu’un formulaire pour chaque activité humaine ci-dessus :

  • Un formulaire pour la demande de congés initiale : FORM_CREATION ;
  • Un formulaire pour la validation N+1, permettant de valider la demande par le N+1 en fonction du service d’origine du demandeur. Le formulaire permet de consulter les données saisies précédemment mais pas de les modifier. En revanche, un champ de commentaires est disponible afin de pouvoir indiquer le problème éventuel : FORM_VALIDATION ;
  • Un formulaire pour la correction, permettant à l’initiateur du processus de modifier sa demande. Les champs sont donc à nouveau en écriture mais le champ commentaire saisi par l’approbateur est en lecture seule : FORM_CORRECTION ;
  • Un formulaire pour la validation, permettant de valider la demande par le N+2 en fonction du type de la demande. C’est exactement le même formulaire que pour l’étape de validation N+1.

Comme vous pouvez le constater, les formulaires suivent des conventions de nommage pour faciliter la communication, la maintenance… Il est prépondérant d’être cohérent !

3.2.2.1 -FORM_CREATION

Le champ Direction contient les valeurs suivantes :

  • Commercial
  • Communication
  • Informatique

Le champ Motif contient les valeurs suivantes :

  • Congés payés
  • RTT

Pour les listes déroulantes, le premier élément sera considéré comme neutre (c’est celui qui fera office de titre pour les choix possibles). Veillez donc à ne pas mettre une des valeur de la liste comme un choix possible sous peine de ne pas pourvoir le sélectionner lors du déroulement du processus.

A l’issue de sa demande, l’initiateur peut simplement envoyer sa demande. Seul le bouton « OK » est disponible :

  • Cliquez sur l’onglet Résultats ;
  • Cliquez sur « Utiliser des résultats personnalisés pour ce formulaire » ;
  • Saisissez « OK » ;
  • Ne cliquez pas sur « Ajouter un résultat » mais sur Enregistrer (icône de disquette en haut à gauche… qui ne doit pas beaucoup parler aux jeunes générations 😀 )
3.2.2.2 -FORM_VALIDATION

Pour le formulaire « form_validation », inutile de ré-inventer la roue. Faites simplement une copie de « form_creation ».

Ce formulaire permet de valider la demande. La philosophie est de pouvoir consulter toutes les informations préalablement saisies afin de vérifier la demande tout en empêchant leur modification. Ces informations sont donc en lecture seule.

Un champ Commentaires a été ajouté pour permettre à l’approbateur d’indiquer la raison du refus pour faciliter la correction de la demande par l’initiateur.

En outre, le valideur peut :

  • soit accepter et appuyer sur OK
  • soit refuser la demande et appuyer sur Corriger

Il faut donc créer ces 2 boutons :

  • Cliquez sur l’onglet Résultats ;
  • Cliquez sur « Utiliser des résultats personnalisés pour ce formulaire » ;
  • Saisissez « OK » puis cliquez sur « Ajouter un résultat » ;
  • Saisissez « Corriger » ;
  • Ne cliquez pas sur « Ajouter un résultat » cette fois mais sur Enregistrer.

3.2.2.3 -FORM_CORRECTION

De même pour « form_corection », une copie de « form_validation » vos donnera toutes les bases pour votre nouveau formulaire.
Le champ Commentaires a été saisi par le valideur N+1 pour indiquer la raison de la correction afin que le demandeur puisse modifier sa demande. Le champ Commentaires est en lecture seule.

A l’issue de la correction, seul le bouton « OK » est disponible pour l’initiateur de la demande, n’oubliez pas de l’ajouter !

3.2.3 -Tables de décision

Une table de décision est un outil permettant de formaliser, à partir d’un ou plusieurs critères d’entrée, le ou les résultats souhaités.

Dans notre application de gestion de demande de congés, les tables de décision permettent de :

  • sélectionner le groupe d’approbation N + 1 (par exemple les chefs de service) en fonction du service auquel l’utilisateur appartient pour vérifier que cela ne nuit pas au bon fonctionnement de celui-ci ;
  • sélectionner le groupe d’approbation N + 2 pour valider la demande au niveau RH.

Une bonne pratique consiste généralement à assigner une tâche à un groupe plutôt qu’à un utilisateur afin de faciliter la gestion de l’organisation et pallier aux absences, aux réorganisations, aux départs…

3.2.3.1 -Sélection N+1 en fonction du service du demandeur

Techniquement, cette table de décision sera traduite en une succession de si/alors/sinon successifs :

SI direction est vide

ALORS le groupe d’approbation est la direction RH

SINON SI direction = Commercial

ALORS le groupe d’approbation est la direction Commerciale

SINON SI direction = Communication

ALORS le groupe d’approbation est la direction Communication

SINON SI …

Vous pouvez ajouter de nouveaux critères en fonction des informations saisies au niveau du formulaire ou disponibles à partir de sources externes. Dans ce dernier cas, cela nécessite de pouvoir accéder à un référentiel externe, ce qui dépasse le cadre de ce tutorial et fera l’objet d’un tutorial dans le futur.

Vous pouvez également ajouter un nouveau résultat qui vous permettra de répondre à des situations plus complexes.

3.2.3.1.1 -Ajout d’un nouveau critère

En cliquant sur l’icône représentant un crayon ou sur le bouton Editeur de table de décision, vous accédez à l’écran suivant :

Les colonnes à gauche où apparaissent les conditions sont appelées les colonnes d’entrée. Dans la capture d’écran ci-dessus, la première colonne est une colonne d’entrée.
Les colonnes à droite où apparaissent les résultats (ou les conclusions) sont appelées les colonnes de sortie. Dans la capture d’écran ci-dessus, la colonne de droite est une colonne de sortie.
L’icône située à droite en haut d’une colonne d’entrée permet d’ajouter un critère de condition :

Les informations à saisir sont les suivantes :

  • Libellé de colonne : Nom d’affichage du critère ;
  • Nom de variable : Nom de la variable, généralement issu du formulaire ;
  • Type de variable : Indique si la variable est une chaine de caractères, un nombre, une date, un booléen (oui/non) ;
  • Valeurs autorisée : Liste les valeurs possibles.

L’icône située à droite en haut de la deuxième colonne permet d’ajouter un nouveau résultat (on dit aussi une nouvelle conclusion) :

Les informations à saisir sont les suivantes :

  • Libellé de colonne : Nom d’affichage du critère ;
  • Nom de variable : Nom de la variable, généralement issu du formulaire ;
  • Type de variable : Indique si la variable est une chaîne de caractères, un nombre, une date, un booléen (oui/non) ;
  • Valeurs autorisée : Liste les valeurs possibles.
3.2.3.2 -Sélection N+2, N+3…

On peut facilement imaginer d’autres tables de décision pour exprimer des situations de plus en plus complexes. Attention à ne pas construire d’usine à gaz. En outre, la modélisation peut devenir difficile à maintenir, voir à comprendre.
Restez simple !
Il serait également possible d’imaginer une table de décision unique rassemblant des critères de condition et des résultats multiples. Ces résultats pourraient par la suite être testés sur chaque transition.

3.2.4 -Finalisation de la configuration du processus

Revenez au processus. Il faut finaliser la configuration :

  • associer les formulaires aux activités
  • configurer les conditions sur les transitions
  • configurer les assignations pour indiquer qui doit réaliser chaque tâche. Généralement, l’acteur sera défini via une table de décision.
3.2.4.1 -Association des formulaires

Pour associer un formulaire déjà existant à une activité, effectuez les étapes suivantes :

  • Sélectionner par exemple l’étape de lancement du processus correspondant à l’étape de départ
  • La valeur du champ Form Reference est normalement vide

  • Cliquer sur cette valeur : une fenêtre contenant les formulaires disponibles s’ouvre

  • Sélectionner celui qui vous intéresse puis cliquer sur Sauver
  • Le nom du formulaire correspondant à cette étape apparaît

3.2.4.2 -Configuration des conditions

Dans notre exemple, les conditions servent à contrôler le nom des boutons cliqués sur les formulaires et à suivre les chemins (transitions) correspondants. Ainsi, sans surprise :

SI le bouton cliqué sur formulaire de Création est « Corriger »
ALORS on suit la transition Corriger
SINON on suit la transition par défaut

En fait, la configuration se fait sur chaque transition en exprimant une condition (aussi appelée garde) pour qu’elle se réalise. Pour mettre en place cette approche avec notre outil de BPM, il faut ainsi configurer une condition pour chaque transition. Effectuez les opérations suivantes :

  • Sélectionner par exemple la transition OK à l’issue de l’étape de validation N+1 qui amène sur « Sélection Valideur N+2 »

  • Cocher la boite Default flow : cette transition est la transition par défaut, il n’y a donc pas de condition à configurer dessus ;
  • Sélectionner la transition à l’issue de l’étape de « Validation N+1 » qui amène sur « Notification d’un problème »

  • Cliquer sur Flow condition et saisir la condition « ${form_FORM_VALIDATION_outcome == “Corriger”} »

  • Cliquer sur Sauvegarder
3.2.4.3 -Assignations

Les activités humaines (ou tâches utilisateurs – User task) sont généralement assignées à des groupes, afin de faciliter la réalisation de celles-ci lors de l’absence d’un ou plusieurs acteurs. Ce peut être vu comme une sorte de délégation de fait (dans la réalité, une délégation est plus complexe, basée sur une date de début et de fin…).

Dans notre exemple, les tables de décision permettent de calculer les groupes auxquels seront assignés les tâches de validation N+1 et N+2. Ainsi, comme décrit plus haut, la table de décision Sélection valideur N+1 calcule le groupe auquel sera assigné la tâche de validation N+1 en fonction du service d’appartenance du demandeur. Ce groupe une fois calculé est stocké dans la variable « validator ».

Pour configurer cette assignation, effectuez les assignations suivantes :

  • Sélectionner la tâche

  • Cliquer sur Assignments, en bas de la fenêtre de propriétés
  • Cliquer sur Valeur fixées
  • Cliquer dans Groupes candidats
  • Saisir ${validator}

  • A l’exécution, cette variable sera remplacée par sa valeur correspondant dans notre exemple à la conclusion de la table de décision précédente ;
  • Cliquer sur Sauvegarder.

Cette opération est à répéter également pour le formulaire N+2.

Pour le formulaire Correction demande de congés, il doit être assigné à l’initiateur de la demande :

  • Cliquer sur la tâche Correction demande de congés
  • Cliquer sur Assignments
  • Cliquer sur Identity Store
  • Sélectionner Assigné à l’initiateur de processus

3.2.4.4 -Déploiement de l’application

A chaque fois que vous effectuez quelques étapes de configuration, je vous suggère de les tester en effectuant un déploiement de test de votre processus. En cas d’erreur, vous saurez ainsi que vos dernières étapes de configuration posent problème.

3.2.4.4.1 -Création de l’application

3.2.4.4.2 -Configuration de l’application
  • Cliquer sur l’icône représentant un crayon

  • Saisir le nom, le titre et la description de votre application/module ;
  • Cliquer sur Sauvegarder.

Cliquer ensuite sur

  • Indiquer éventuellement les utilisateurs et les groupes ayant accès à cette application. Attention, il faut indiquer « id » des utilisateurs et des groupes. Si vous n’indiquez rien alors elle sera accessible à tout le monde ;
  • Cliquer sur Editeur les modèles ;
  • Sélectionner les modèles de processus auxquels vos utilisateurs devront pouvoir accéder.

3.2.5 -Applications

Les outils de BPM permettent de générer automatiquement les applications de gestion des processus. Ceux-ci sont généralement rassemblés en modules. Dans le cadre de notre exemple, nous aurons ainsi un module de gestion RH, dans lequel on trouvera la gestion de demande de congés. On peut bien sûr avoir d’autres processus pour ce même module et on peut avoir d’autres modules.

4 – Conclusions

Travailler avec des listes déroulantes dont on rentre les éléments à la main devient vite fastidieux. Dans la vraie vie, on a intérêt à s’interconnecter avec des référentiels externes où ces éléments existent déjà. L’intérêt de pouvoir les insérer à la main est de mettre le doigt là où la valeur ajoutée de votre service informatique ou de votre prestataire sera maximale. En lui demandant de s’interfacer simplement avec votre référentiel, vous décuplerez l’intérêt de votre BPM tout en limitant strictement les manipulations du service informatique à une couche technique : vous gardez totalement le contrôle sur les aspects fonctionnels.

5 – Ressources

https://en.wikipedia.org/wiki/Comparison_of_Business_Process_Modeling_Notation_tools

03Juil/18

Intégrer CMIS avec Ruby

Installation

Pour jouer cette même requête avec ruby, et l’intégrer par exemple dans un développement basé sur RoR, il faut installer une  librairie cmis, par exemple :

  • https://github.com/UP-nxt/cmis-ruby.git

Configuration

Après installation, il faut saisir les informations correspondantes à votre GED, en l’occurrence Alfresco, dans spec/config.yml :

server:
  service_url: http://localhost:8080/alfresco/api/-default-/public/cmis/versions/1.1/browser
  username: admin
  password: admin
repository: -default-

Lancez alors les tests avec la commande suivante :

rake

Récupération d’une liste de documents

Pour vous aider à faire vos premiers pas avec cette librairie, vous pouvez tester le script suivant adapté depuis le readme du projet :

[code language=”ruby”] $LOAD_PATH.unshift ‘lib’
require ‘cmis’

# get the repository object
server = CMIS::Server.new(service_url: ‘http://localhost:8080/alfresco/api/-default-/public/cmis/versions/1.1/browser’,
username: ‘admin’, password: ‘admin’)
repository = server.repository(‘-default-‘)

# query for first 50 documents where the property ‘cmis:name’ is ‘%DAT%’
# and stored in sites/test directory
cmisq = <<eos
select * from cmis:document
where cmis:name like ‘%DAT%’
and contains (‘PATH:\”//app:company_home/st:sites/cm:test//*\”‘)
eos

#query = repository.query(“select * from cmis:document where cmis:name like ‘GED%'”)
query = repository.query(cmisq)

query.each_result(limit: 50) { |document|
puts “-New item ——————————”
puts “Name: ” + document.name
puts “CMIS ObjectId: ” + document.cmis_object_id
puts “Mime-Type: ” + document.content_stream_mime_type
puts “Last Modification Date: ” + document.last_modification_date.to_s
}
[/code]

En exécutant ce code, on obtient la sortie suivante :

Conclusion

Pour étudier les autres possibilités de la librairie, je vous invite à consulter les fichiers de tests dans le répertoire spec/cmis-ruby, et plus particulièrement :

  • document_spec.rb : pour la création/lecture/mise à jour/suppression de document
  • folder_spec.rb : pour la création/lecture/mise à jour/suppression de dossier
01Juil/18

Introduction à CMIS

CMIS est le langage de choix pour requêter une gestion documentaire. En effet, ce langage, proche de SQL, utilise les concepts proches des bases de données. CMIS est un standard mais, bien sûr, chacun a développé un sous-ensemble de fonctions supplémentaires en dehors du standard. Cependant, c’est mieux que rien…

Ainsi, pour récupérer la liste des documents dont le nom contient la chaine DAT et qui sont stockés dans la sous arborescence “sites/test”, il faudra taper la requête suivante :

select * from cmis:document
where cmis:name like '%DAT%'
  and contains ('PATH:"//app:company_home/st:sites/cm:test//*"')

Navigateur de noeuds

Les habitués d’Alfresco auront remarqué que le chemin fait référence à un répertoire stocké dans un site…

Dans mon cas, en tapant la requête dans le navigateur de noeuds d’Alfresco j’obtiens le résultat suivant :

CMIS Workbench

Afin de découvrir Alfresco d’un point de vue CMIS (nom des propriétés notamment), je vous invite à télécharger CMIS Workbench. Il vous permettra de mieux comprendre le fonctionnement de CMIS :

  • Navigation dans le repository et découverte des propriétés CMIS
  • Exécution d’une requête CMIS depuis une fenêtre de console

CMIS Workbench est disponible à l’adresse suivante :

Navigation dans le repository et découverte des propriétés

Exécution d’une requête CMIS

Conclusion

Un standard riche, simple à utiliser de par sa proximité avec le SQL, une fois qu’on a, comme d’habitude, intégré quelques subtilités (notamment les D: et P: pour spécifier les types et aspects… 😉

Bon tests !

18Mai/18

Ouvrez simplement votre entrepôt Alfresco au grand public

Module de consultation externe simplifié par profil

Blue Search

Introduction

BlueSearch est une application de consultation simplifiée qui permet d’effectuer des recherches « à la google » sur un repository Alfresco. Les recherches effectuées sans authentification sont limitées à des documents « publics » et ne ramènent que des documents accessibles par l’utilisateur « public ».

Les recherches peuvent également être réalisées avec authentification ; elles sont alors réalisées sur l’ensemble des documents accessibles par l’utilisateur authentifié.

Suite à la recherche, les résultats peuvent être affinés grâce la sélection de facettes. Les documents peuvent être prévisualisés, téléchargés, étudiés dans le détail et partagés via un lien par mail ou sur les réseaux sociaux quels qu’ils soient (twitter, pinterest, facebook…).

Les principaux écrans de cette application peuvent être facilement personnalisés via des fichiers css directement accessibles par l’administrateur de l’application ou par un prestataire d’une agence de communication.

Application de consultation

Spécifications fonctionnelles

Cas d’utilisation

@TODO

Rôles

L’application est composée de 2 modules :

  1. l’application de consultation simplifiée ;
  2. l’application de configuration.

Elle peut être accédée par 3 rôles :

  • un rôle public : une authentification automatique et transparente est réalisée par l’application. Les utilisateurs n’ont généralement que des droits de lecture, de consultation et de téléchargement ;
  • un rôle authentifié : l’utilisateur s’authentifie à l’aide de son identifiant et de son mot de passe. Il a les droits correspondant à son degré d’habilitation quelle que soit l’application utilisée ; il accède généralement à l’application de consultation simplifiée mais il peut également accéder à l’application Alfresco Share native s’il a besoin de l’ensemble des fonctionnalités disponibles ;
  • un rôle d’administrateur fonctionnel : l’utilisateur s’authentifie à l’aide de son identifiant et de son mot de passe. Il a les droits correspondants à son degré d’habilitation. Il accède à l’application uniquement via Alfreco Share natif.

Plateformes de consultation

Les plateformes de consultation se divisent en :

  • Ordinateurs de bureau ;
  • Tablettes ;
  • Smartphones.

Cette application de consultation a été développée pour les ordinateurs de bureau. Elle peut être consultée sur une tablette et un smartphone mais son ergonomie n’a clairement pas été pensée pour ces derniers.

Il serait intéressant de développer un module pour tablette et smartphone.

Architecture

Diagramme d’architeture

L’architecture de la solution est la suivante :

@TODO

Fonctionnalités techniques

Les fonctionnalités suivantes sont implémentées :

  • Interface d’administration de l’application
  • Authentification automatique
  • Pages personnalisables
    • Pages html statiques
    • Fichiers css statiques
    • Personnalisation des informations à afficher

Interface d’administration de l’application

Une IHM spécifique est disponible. Elle correspond à l’application Alfresco Share native. Elle permet de :

  • créer le compte public
  • modifier les pages personnalisables

Authentification automatique

L’accès à quelque page que ce soit au niveau de l’application Alfresco nécessite obligatoirement une authentification. BlueSearch authentifie automatiquement l’utilisateur sans saisie d’aucun mot de passe. Les documents qui peuvent être recherchés ou accédés sont limités par les droits de l’utilisateur choisi pour l’authentification automatique.

Ce mécanisme pourrait être étendu très simplement afin de s’authentifer avec diffférents utilisateurs selon divers critères (son adresse IP – interne/externe, l’heure, le temps qu’il fait… :-).

Pages personnalisables

L’application peut être personnalisée au niveau des pages html statiques suivantes :

  • formulaire de recherche : construction totale de la page ;
  • mentions légales : construction totale de la page ;
  • contact : construction totale de la page.

L’application peut également être personnalisée au niveau des fichiers css statiques qui permettent d’adapter la présentation des pages dynamiques :

  • home.css : pour personnaliser la présentation globale des pages statiques ;
  • delib.css : pour personnaliser la présentation de la page détail.

Fonctionnalités

L’application est constituée des pages suivantes :

  • Page de recherche à la google
  • Page de liste de résultats
  • Page de recherche avancée
  • Page de détails

Page de recherche à la google

Cette page permet de rechercher le repository à partir d’un ensemble de mots-clés comme sur Google, Bing, Yahoo…

Page de liste de résultats

Cette page s’affiche suite à une recherche « à la google » ou suite à une recherche avancée.

Par défaut, seuls 20 documents sont affichés. Il est possible de « scroller » en bas de page pour afficher 20 nouveaux résultats… Dans la pratique, l’utilisateur sélectionne souvent une facette afin d’affiner sa recherche.

Téléchargement d’un ou plusieurs documents

L’utilisateur peut télécharger un document avec les actions suivantes :

  • Cliquer sur Actions ;
  • Cliquer sur Télécharger.

L’utilisateur peut aussi télécharger un ou plusieurs documents :

  • Sélectionner plusieurs documents ;
  • Cliquer sur Documents sélectionnés ;
  • Cliquer sur Télécharger un .zip.

Navigation par facettes

Sélection de facettes métier

En cliquant sur une facette métier, la liste des résultats s’affine et se met à jour. Il est possible de sélectionner une autre facette ou de désélectionner une facette.

Prévisualisation du document

En cliquant sur l’icône de « document », la page suivante s’affiche :

Page de recherche avancée

Une page de recherche avancée est disponible. Elle permet de sélectionner plusieurs critères en même temps sur un ou plusieurs champs. Elle renvoie sur la liste de résultats ci-dessus.

Page de détails du document

Partage d’un document

Des actions de partage par mail sont disponibles. Elles créent un message en mode édition dans votre outil de messagerie que l’utilisateur peut personnaliser :

Visualisation des métadonnées

Les métadonnées sont présentées à l’utilisateur sur la page de détails. Ces détails peuvent être cachés/affichés via le fichier css personnalisable delib.css.

Conclusion

BlueSearch permet de valoriser très simplement le contenu public d’un repository Alfresco et d’augmenter très simple votre retour sur investissement.

Pour voir le système en production, je vous invite à consulter le site public suivant :