Concepts

Prise en main des concepts généraux de la plateforme


    Prenez en main les concepts liés au modèle de données FlowerDocs 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 FlowerDocs.



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 FlowerDocs.


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 avec la propriété scope.default dans le fichier de configuration gui.properties est utilisé.


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


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

Les capacités de FlowerDocs 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 technique


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

  • Agrégations & buckets : 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)


Améliorer la performance, la productivité ainsi que la qualité du service de votre entreprise à l’aide de Business Process Management (BPM).

Flower intègre le moteur de workflow Camunda pour orchestrer les processus.

BPM

Le Business Process Management (BPM) permet d’avoir une vue sur l’ensemble des processus métiers et de leurs intéractions permettant de les optimiser et de les automatiser.

BPMN

Business Process Model and Notation (BPMN) est un standard global permettant aux utilisateurs de modéliser les processus.



CMMN

Case Management Model and Notation (CMMN) définit un méta-modèle commun pour la modélisation et l’expression graphique d’un cas ainsi qu’un format d’échange pour l’échange de cas entre entre différents outils.

HumanTask

HumanTask ou tâche utilisateur permet de modéliser le travail d’un utilisateur.

HumanTask auto

Lorsqu’une HumanTask est lancée de manière automatique par le moteur, une tâche FlowerDocs est créée et affichée dans le dossier.

La tâche FlowerDocs est créée avec pour classe la valeur de la propriété Form Key.

HumanTask manuelles

Lorsqu’une HumanTask est lancée manuellement, aucune tâche FlowerDocs n’est créée.

La classe de tâches (ou formulaire) utilisée pour le lancement de la tâche est déterminé par la proporiété Form Key.

Formulaire

Le formulaire utilisé pour une HumanTask est déterminé par la valeur de la proporiété Form Key dans le designer.

La valeur de cette propriété doit correspondre à une classe de tâches définie et configurée dans la console d’administration.



La valeur de cette propriété peut être :

  • une chaîne de caractère
  • une expression résolue à l’aide des variables de l’exécution

Techniquement

Les tâches

Il est important de distinguer deux types de tâches : celles du processus et celles présentées aux utilisateurs (les tâches Flower).

Les tâches du processus

Les tâches du processus sont des étapes techniques (non-visibles des utilisateurs) ou utilisateurs. Ces dernières implique la création d’une tâche Flower permettant ainsi de les traiter.

Les tâches utilisateurs Camunda

Elles sont divisées en deux types en fonction des normes :

  • BPMN : UserTask
  • CMMN : HumanTask

Les tâches FlowerDocs

Les tâches FlowerDocs sont des composants (disposant de réponses et pièces jointes). Elles sont présentées aux utilisateurs sous la forme de formulaires à remplir.


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ées grâce à :

GET /rest/session/reservations


Le produit FlowerDocs repose sur une architecture classique en 3-Tiers :

  • Présentation
  • Services
  • Données


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

Couche de présentation

FlowerDocs

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

  • FlowerDocs 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 FlowerDocs GUI. Les échanges se font donc via le protocole HTTP(S).

Couche de services

FlowerDocs Core

FlowerDocs 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 FlowerDocs 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 documentation 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. FlowerDocs 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 FlowerDocs 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’application, 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ées 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 consulter 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 documents unique FactureFournisseur référençant les classes de tags :

Classe de tags 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âches TraitementFacture avec les caractériques suivantes :

Les tags de l’étape de traitement

La pièce jointe

Afin que le service comptable puisse traiter la facture en 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 appliqué à (tous) vos cas d’usages autour de la gestion de documents électroniques.

Composants

Tags

Classes de composants

Tous
Operations

Tous
Sécurité