Concepts

Prise en main des concepts


    Prenez en main les concepts liés au modèle de données Flower conçu dans le but de faciliter :

    • la compréhension
    • la ré-utilisabilité des objets définis
    • l’administration de la solution

    Cette section décrit brièvement les concepts nécessaires à la mise en place d’une solution basée sur Flower.



    Vos documents sont encore au format papier ?

    Contactez nous pour en connaître plus sur notre expertise concernant la dématérialisation et mettre en place une chaîne de dématérialisation afin d’alimenter votre solution Flower.


    Les scopes permettent d’isoler les données entre différents clients / métiers tout en utilisant une même plateforme.

    Un scope définit un silot applicatif en isolant ses données et sa configuration. A ce titre, il définit :

    • les équipes d’utilisateurs
    • les utilisateurs pouvant accéder à celui-ci
    • les langues utilisées


    Afin de se connecter à un scope, il est nécessaire de renseigner son identifiant comme paramètre d’URL (par exemple : http://flowerdocs.com/gui?scope=GEC.

    Si le paramètre n’est pas renseigné, le scope par défaut défini dans le fichier de configuration scope.default est utilisé.


    L’autorisation de l’accès à un scope est déterminé par la permission de lecture sur la liste de contrôle d’accès déinie au niveau du scope. Plus de détails sur ce mécanisme peuvent être consultés ici.


    L’interface et moteur Flower ont été conçus afin d’exploiter au maximum les capacités de recherche.

    Les capacités de Flower en terme de recherche permettent d’exploiter au maximum le fond documentaire tout en conservant l’ergonomie requise par les utilisateurs finaux.


    Les fonctionnalités classiques de recherche d’une GED sont exposées dont :

    • la sélection des champs à afficher
    • des filtres de recherches
    • tris sur les métadonnées
    • la pagination des résultats
    • etc…

    Plus de détails peuvent être consultés sur la documentation techhnique


    En sus de ces capacités, des fonctionnalités additionnelles ont été intégrées dès la conception du produit :

    • Aggrégations & bucket : classification des composants en fonction de leurs tags
    • Formulaires de recherche : des formulaires riches pouvant être entièrement personnalisés en fonction des besoins utilisateurs (cf. documentation)

    Une réservation permet de s’approprier temporairement l’accès en écriture d’un composant dans l’interface graphique afin d’éviter les modifications concurrentes.

    Un composant est réservé lorsqu’il est ouvert en lecture / écriture par un utilisateur de l’interface graphique. Si un composant réservé est ouvert par un autre utilisateur, le formulaire est affiché en lecture seule.

    Les réservations sont automatiquement supprimées lorsque :

    • l’utilisateur quitte l’écran depuis lequel le composant a été réservé (via une action ou la fermeture de son navigateur)
    • sa session expire
    • l’utilisateur se déconnecte

    Depuis l’interface graphique, les réservations de l’utilisateur courant peuvent être consultés grâce à :

    GET /rest/session/reservations


    La produit Flower repose sur une architecture classique en 3-Tiers :

    • Présentation
    • Services
    • Données


    Flower s’appuie sur la visionneuse universelle de document ARender.

    Couche de présentation

    Flower

    Flower est composée de deux applications web Java distinctes pour la couche de présentation :

    • Flower GUI : l’Interface Utilisateur principale développée en GWT et extensible via des personnalisations Javascript.
    • ARender HMI : l’Interface Utilisateur pour la visionneuse ARender, développée également en GWT.


    Elles sont déployées dans un conteneur de servlet Apache Tomcat et sont accessibles via le protocole HTTP(S).

    Kibana

    Kibana est une application Web en NodeJS développée par Elastic. Elle s’interface avec le moteur de recherche Elasticsearch et permet de produire des tableaux de bord personnalisés basés sur les données dans Elasticsearch, pour réaliser du suivi opérationnel ou du reporting. Kibana communique avec Elasticsearch via les API HTTP RESTful de ce dernier.

    Ces rapports sont intégrés directement par Flower GUI. Les échanges se font donc via le protocole HTTP(S).

    Couche de services

    Flower Core

    Flower Core est le moteur de GED. C’est une application Web Java déployée dans un conteneur de servlet Tomcat. Elle permet de gérer de très grandes quantités de documents (ajout, suppression, mise à jour de documents, recherche, dossiers dynamiques etc.). Elle expose des Web Services SOAP qui sont consommés par les clients, que ce soit l’Interface Web native Flower GUI, des applications tierces type Kofax ou potentiellement des éléments du Système d’Informations. Le protocole de communication est HTTP(S).

    Pour la persistance des données, Elasticsearch est utilisé pour la partie métadonnées et un espace de stockage pour la partie contenus de documents. La communication avec Elasticsearch est réalisée via l’ES Transport qui est un protocole propre à Elasticsearch. Le stockage des contenus des documents est réalisé en fonction des besoins et le protocole d’échange dépend de la technologie étudiée (cf. chapitre sur le stockage des contenus).

    L’authentification des utilisateurs est déléguée un annuaire d’entreprise. Des requêtes LDAP sont effectuées avec des filtres sur les attributs pour rechercher des utilisateurs dans l’annuaire. Ces opérations sont réalisées via LDAP(S).

    ARender Rendition Server

    ARender Rendition, produit développé par Arondor, est le moteur de conversion des contenus pour que ces derniers soient utilisables par ARender HMI. C’est une application Java standalone qui s’exécute dans sa propre JVM. Le principe est de transformer les contenus (PDF, Word etc) en images qui sont envoyées vers ARender HMI.

    Données

    Cette partie décrit la couche de données seulement pour le connecteur Elasticsearch. Consulter la document Alfreso ou IBM FileNet P8 pour les autres connecteurs.

    Elasticsearch

    Le moteur d’indexation et de recherche Elasticsearch, application Java standalone, est utilisé pour l’indexation et la recherche des données. Il fournit un moteur de recherche distribué et multi-entité ainsi qu’un stockage NoSQL de type Document. Flower utilise ces fonctionnalités pour stocker les métadonnées du document dans la partie NoSQL et les capacités avancées de moteur de recherche pour les requêtes sur les documents, les tâches et les dossiers.

    La communication se fait via l’Elasticsearch Transport Protocol qui repose sur un module spécifique basé sur TCP. Les Web Services RESTful proposés par Elasticsearch sont eux utilisés pour les requêtes de Kibana.

    Stockage des contenus

    Les contenus des documents (PDF, MS Word, etc.) gérés par Flower ne sont pas stockés dans Elasticsearch mais sur un espace de stockage dédié qui peut être :

    • un système de fichiers type NAS via CIFS/NFS
    • un système de fichiers type SAN via Fiber Channel
    • un service de stockage objet type AWS S3 via des WebServices RESTful

    Exemple d'architecture simple
    Exemple d'architecture simple


    Découvrez les concepts évoqués dans un cas d’application simple : la Gestion de factures fournisseurs

    Scénario

    Une solution de gestion de factures fournisseurs gère de manière digitalisée le traitement des factures émises par des fournisseurs.

    Pour compliquer notre cas d’applications, ajoutons un peu de processus ! Les factures dont le montant est supérieur à 2500€ doivent être soumises à la validation d’un tiers.

    Les factures peuvent être consultés par deux services de l’entreprise :

    • le service comptable : afin de traiter les factures, une liste de factures à traiter sera présentée à ses utilisateurs
    • le service achat : afin de pouvoir négocier lors de futures commandes, ses utilisateurs pourront consultées l’ensemble des factures émises par un fournisseur donné

    Solution

    Gestion des documents

    Ces factures possèdent un ensemble de caractéristiques communes :

    • Un émetteur
    • La date d’émission
    • Un numéro de pièce
    • Un libellé
    • Montant hors taxe
    • Etc.

    Dans cet exemple, nous optons pour des composants de catégorie Document étant donné qu’ils auront un contenu (image, PDF…). Nous choisissons une classe de document unique FactureFournisseur référençant les classes de tags :

    Classe de tag Type Obligatoire
    Emetteur Chaîne de caractère Oui
    DateEmission Date Oui
    NumeroPiece Chaîne de caractère Oui
    MontantHT Décimal Oui

    Le libellé de la facture sera utilisé pour remplir le nom du document

    Traitement

    Afin de notifier le service comptable de l’arrivée d’une facture à traiter, nous allons déclencher le traitement d’une tâche de traitement de facture à la création d’un document de classe FactureFournisseur. Nous définissons donc la classe de tâche TraitementFacture avec les caractériques suivantes.

    Les tags de l’étape de traitement

    La pièce jointe

    Afin que le service comptable puisse traiter le facture s’apppuyant sur les informations (et le fichier) de la facture reçue, nous ajoutons une pièce jointe sur la classe de tâche :

    • catégorie : Document
    • classe : FactureFournisseur
    • obligatoire : Oui

    Les réponses

    Les factures reçues sont toujours parfaites, nous ajoutons donc une seule réponse Valider offrant ainsi, au service comptable, seulement la possibilité de valider la facture reçue.

    Consultation

    Validation


    Ce type de conception peut être appliquer à (tous) vos cas d’usage autour de la gestion de documents électroniques.