Le Coffre-Fort Numérique (CFN)

L'entreprise Adour Gestion Informatique (AGI) développe ses applications principalement grâce aux technologies Microsoft (.Net Framework 4.5+ et langage VB.Net pour la majorité de ses projets). Elles s’appuient sur le système de gestion de bases de données Oracle pour le stockage de données. C’est un système robuste qui nécessite cependant des coûts d’acquisition de licence élevée.

Dans le cadre de la mise à disposition des documents PDF du Coffre-Fort Numérique (CFN1000) aux clients finaux (les clients des clients d’AGI) il s’agit de mettre au point une alternative de stockage afin de diminuer le montant requis pour les licences d’exploitation.

Le Coffre-Fort Numérique (CFN1000) est un module intégré au sein de l’application InteGraal XXL qui permet le stockage sécurisé de documents PDF sous forme dématérialisée. Le module communique avec un serveur (CFN Server) par le biais de requêtes http. Les documents PDF sont stockés sous forme binaire dans une base de données.

Cette architecture logicielle est déployée sur un réseau TCP/IP standard :

• Le serveur, qui héberge à la fois l'API REST du CFN Server et la base de données contenant l'intégralité des informations,
• Deux postes de travail en exemple, chacun exécutant l'application InteGraal XXL avec le module CFN1000.

Le projet a ainsi évolué vers la recherche d'une base de données alternative, avec PostgreSQL se démarquant comme une solution viable répondant aux besoins professionnels tout en offrant une compatibilité avec les capacités d'Oracle. L'objectif est double : adapter les requêtes pour assurer la compatibilité avec la nouvelle base de données choisie et, si possible, du code, et du fonctionnement général du Coffre-Fort Numérique, sans pour autant modifier l'interface utilisateur

L’objectif est de rendre CFN1000 compatible avec Oracle et PostgreSQL simultanément. Pour des raisons techniques le projet a basculé sur le développement d'une API REST entièrement nouvelle laissant de côté la version serveur initiale. Le code du module client préalablement en VB.Net, a été migré vers C# afin de bénéficier d’une meilleure prise en charge des outils de refactorisation disponible dans mon IDE Rider.

Pour pouvoir rendre le Coffre-Fort Numérique compatible avec les deux différents types de bases de données il est nécessaire qu’elles aient le même schéma. La base PostgreSQL a donc été calquée sur sa version Oracle (les types de données supportés étant similaires). Voici un schéma de la base de données qui est utilisée :

Il y a 10 tables, parmi lesquelles trigger_message et dmt_files_tampon peu utilisées. Voici une description détaillée de leurs fonctions :

• dmt_lignes : Cette table recense de manière exhaustive les fichiers, en précisant le nom, la référence et la date du fichier, ainsi que des informations en lien avec les autres tables.
• dmt_type_entrees : Cette table détermine si l'entité concernée est un client ou un fournisseur
• dmt_type_document : : Elle catégorise les fichiers PDF selon leur type, indiquant s'il s'agit d'un bon de livraison, d'une facture, etc.
• dmt_droits : Cette table définit les droits d'accès attribués aux utilisateurs.
• dmt_societe : Cette table attribue un numéro unique à chaque société (001, 002, 003, etc.).
• dmt_users : Elle conserve la liste des utilisateurs, incluant leur code utilisateur et leur mot de passe sécurisé via un hachage MD5.
• dmt_files : Elle stocke les fichiers sous forme binaire directement dans la base de données et attribue à chaque fichier un ID unique, actualisé par une séquence. Cet ID est aussi référencé dans Dmt_lignes
• dmt_entrees : Elle répertorie les entreprises et entités qui possèdent des fichiers au sein du Coffre-fort Numérique.

Le Coffre-Fort Numérique (CFN1000) est organisé en trois composantes principales : l'application cliente sur le poste informatique, l'API REST et la base de données sur le serveur. Nous nous concentrerons d'abord sur l'API, qui constitue la partie serveur.

L'API REST est une application serveur conçue en .NET 7 utilisant le langage C# avec l'outil Dapper, un micro-ORM, pour faciliter le transfert des données de la base vers et depuis dans des objets en mémoire

Il est précisé en en-tête que la fonction est accessible via une méthode HTTP POST sous l'URL ListeDocuments. Une balise (AuthorizeReadJwt) indique que l'accès à cette fonction nécessite une autorisation spécifique provenant du token, sujet sur lequel nous reviendrons ultérieurement.

Un exemple d’appel coté client :

La fonction démarre avec la création d'une nouvelle requête à l'adresse URL suivante :

• api/documents/ListeDocuments

Cette URL indique que la fonction recherchée est située dans le contrôleur des documents au sein de l'API, fournissant ainsi le chemin complet. Il est important de noter que chaque contrôleur au sein de l'API REST dispose de son propre chemin d'accès ainsi que de sous-chemins pour ses fonctions associées. (Les chemins originaux de la version Web Service ont été conservés). Une particularité existe avec le contrôleur Tiers, qui gère deux chemins distincts pour ses deux types d'entités Tiers et Type de Tiers ce qui se traduit par les URLs suivantes :

• api/tiers/delete
• api/tiers/TypeTiers/delete

Ces chemins correspondent aux tables dmt_entrees et dmt_type_entrees dans la base de données, respectivement pour les tiers et les types de tiers. Cette organisation permet une gestion structurée et claire des appels API en relation avec les structures de données sous-jacentes.

Le dossier Helpers gère les tokens JWT au sein de l'API où il est signé et déchiffré, garantissant que seul l'API puisse manipuler ces informations sécurisées. Le processus d'authentification est strict : si une requête à l'API ne comporte pas de token ou s’il ne contient pas les droits nécessaires, une erreur est renvoyée. La gestion des droits est détaillée ci-dessous où les droits d’accès sont comparés aux informations de la base de données. Un mécanisme similaire est mis en place pour les droits d'écriture.

En outre, à chaque démarrage du module CFN1000 des requêtes sont systématiquement envoyées à l'API. Ces requêtes ont pour but de charger les données nécessaires pour remplir deux menus déroulants dans l'interface du module, permettant ainsi une interaction utilisateur fluide dès le lancement de l'application.

Cette structure permet non seulement de sécuriser les échanges de données mais aussi de garantir que l'interface utilisateur soit toujours à jour, grâce à des informations correctement initialisées et sécurisées par l'API.

Maintenant que les bases du fonctionnement ont été établies voici l’interface de base du module CFN1000 ci-dessous :

Dans le volet gauche de l'écran principal, vous découvrez un ensemble de champs de saisie dynamiques conçus pour affiner vos recherches documentaires avec précision. Vous avez la possibilité de filtrer les résultats selon plusieurs critères, notamment :

• le type de document recherché,
• la catégorie des tiers (clients ou fournisseurs, par exemple),
• un tiers spécifique,
• une référence documentaire particulière,
• ainsi qu'un intervalle de dates pour une recherche chronologique ciblée.

Au sommet de l'interface, des icônes directionnelles servent de guides visuels vers les fonctionnalités essentielles du système. Ces icônes vous mènent aux outils d'insertion de nouveaux documents et d'accès à la configuration du système.

Lors de cette démarche, des listes déroulantes permettent de sélectionner le type de document et le type de tiers. De plus, lorsqu'il s'agit de renseigner le code tiers, une fenêtre intermédiaire apparait permettant de choisir parmi les éléments pré-enregistrés dans le système.

Les utilisateurs doivent s'authentifier pour débloquer l'accès à des fonctionnalités avancées.

Dans cet environnement sécurisé, l'utilisation de droits administratifs est nécessaire et fait l'objet d'une vérification. Si l'authentification est confirmée des onglets supplémentaires sont affichés permettant de modifier les informations stockées dans la base de données.