L’ IMPORT ET L ’ INDEXATION DES METADONNEES

Suivant le mode opératoire décrit ci-dessus, une procédure stockée est ainsi exécutée après réception d’un lot de décomptes dématérialisés. Le choix de la base de données choisie pour la création de cette procédure stockée s’est porté sur la base InternetDB. Cette base de données hébergeant déjà les informations liées aux différents services Internet, elle s’est imposée à nous pour y indexer les décomptes. A cet effet, la table INDEXDEC permettant d’indexer les métadonnées est créée, dont la description est la suivante :

NOM DESCRIPTION --- ---

IDINDEXDEC Identifiant (numéro séquentiel) IDSRCSYST Système d’information source IDPERSPHY Identifiant de l’adhérent NUDECNUM Numéro de décompte

DTDEC Année des soins portés par le décompte DTEDIT Date d’édition du décompte

NOMFICH Nom du fichier PDF TAILLEFIC Taille du fichier en octet

La dénormalisation de cette table – le nom du fichier étant la concaténation des colonnes IDPERSPHY, NUDECNUM et DTDEC – autorise la gestion de noms de fichiers « hors norme » et laisse ainsi plus de souplesse pour l’adaptation au futur S.I.

Les fonctionnalités de la procédure stockée sont les suivantes :

- extraction dans un même répertoire des fichiers PDF et du fichier texte d’index

- import du fichier texte dans une table temporaire ayant de même structure que la table INDEXDEC

- pour chaque enregistrement de la table temporaire sont effectuées les tâches suivantes : - vérification de la présence du fichier porté par la colonne NOMFICH

85

- insertion de l’enregistrement courant dans la table INDEXDEC - préparation et envoi de l’alerte e-mail de dépôt d’un décompte,

- contrôle de l’indexation effective de l’ensemble des fichiers PDF extraits de l’archive ZIP. 6.3.2.3. LA COPIE DES FICHIERS PDF SUR LE SERVEUR

Comme nous venons de le voir, les fichiers PDF de décomptes dématérialisés sont déposés sur la machine CHRONOSPREV alors que leur destination finale se trouve sur le nouveau serveur de fichiers. Un lien est donc nécessaire pour les faire transiter du premier vers le second.

Sachant que tous deux sont positionnés sur le réseau local, les risques semblent moins venir de l’extérieur que de l’intérieur de l’entreprise. Alors que le réseau interne est protégé de l’extérieur par un pare-feu qui filtre les requêtes entrantes, il est à priori accessible à l’ensemble des salariés de Prévadiès. Or pour la sécurité des données, les accès au serveur de décomptes doivent être limités au minimum.

La première mesure est de limiter l’ensemble des comptes des utilisateurs autorisés à se connecter à cette machine. Cela passe par la désactivation des comptes invités et la création de comptes utilisateurs pour les personnes autorisées.

6.3.2.3.1. L’arborescence des fichiers de décomptes

Même si les fichiers PDF des décomptes de prestations sont indexés à l’aide de la table index créée dans la base de données InternetDB, les décomptes doivent être organisés en gardant à l’esprit les contraintes suivantes compte tenu du volume de données attendu :

- accéder rapidement au fichier demandé,

- éviter les risques d’envoi d’un décompte ne le concernant pas à un Internaute,

- tenir compte des contraintes liées à la configuration du serveur de stockage, notamment au système de fichiers NTFS,

- faciliter la maintenance

- être évolutif afin d’étendre le système aux autres mutuelles du groupe ou autres familles de documents dématérialisés.

La solution mise en œuvre prend donc la forme d’une arborescence de répertoires sur la partition DATA du serveur de stockage. Pour répondre aux contraintes énoncées précédemment, celle- ci sera de la forme :

Type de documents \ Mutuelle \ Identifiant de personne \

6.3.2.3.2. L’arborescence des fichiers de décomptes en environnement de tests

Comme nous l’avons vu précédemment, nous nous dirigerons vers l’utilisation du même environnement à la fois pour la production et pour les tests. L’inconvénient dans cette configuration est de distinguer de manière certaine l’environnement de tests et de production, la confusion entre les deux remettant en question la sécurité des données. Nous nous appuierons pour cela sur l’existant en production où le serveur web choisit d’attaquer la base de données déclarée dans un fichier de configuration du modèle ASP : le fichier global.asa. Le rôle de ce fichier est de configurer une application web avec des paramètres par défaut sans devoir modifier la configuration du serveur. Placé à la racine du site web, il permet à son concepteur

d'exécuter des instructions, d'initialiser des variables, avant ou Figure 31 : Arborescence du serveur de stockage

86 après l'exécution d'un script.

Prévadiès a choisi d’y définir les variables spécifiques à la définition de l’environnement de travail. Ces données sont appelées variables d’environnement – ou globales – et peuvent être utilisées dans toutes les pages de l’application avec la commande application(ma variable). Parmi celles-ci, la variable GLOBAL_NOMSERV définit le nom de la base de données et est initialisée en fonction de l’environnement avec les valeurs Prod ou Backup.

Suivant ce schéma, le fichier global.asa définit le chemin d’accès aux fichiers PDF de décomptes dématérialisés. Concernant l’environnement de stockage en tests, nous avons choisi de créer un deuxième répertoire à la racine de la partition DATA nommé Test et dont la sous- arborescence est identique à celle de production. On obtient ainsi l’arborescence ci-contre.

Pour plus de facilités, SATI nous fait parvenir l’ensemble des fichiers de décomptes et celui des métadonnées dans une archive au format ZIP. Celle-ci est ensuite extraite vers un répertoire temporaire.