Solution Laboratoire

En mode exploitation, lors de la modification d’un élément de paramétrage (norme, DU ou protocole), sa version est incrémentée. Pour que l’élément versionné soit pris en compte par les éléments de paramétrage qui en dépendent, il est nécessaire de les modifier. Cette opération est automatique depuis la version 4.1.8 de SOLUTION Laboratoire.

Les libellés des écrans de propagation des DU et Normes peuvent être modifiés via la touche F2.

Cette fonctionnalité est accessible suivant deux options distinctes :

Propagation de procédure reversionnée

Cette option est valable pour toute détermination unitaire ou protocole qui a subit un reversionnement. La propagation peut être effectuée sur les DUs de dépendance, les protocoles, les modèles de feuille de paillasse et les dossiers-types qui utilisent la détermination unitaire ou le protocole reversionné.

Propagation de norme reversionnée

Cette option est valable pour toute norme qui a subit un reversionnement. La propagation peut être effectuée sur les modèles de feuille de paillasse et les dossiers-type qui utilisent la norme reversionnée.

Le mode test de SOLUTION Laboratoire a été créé pour faciliter le paramétrage. En effet, dans ce mode d’utilisation du progiciel, les objets versionnés dans SOLUTION Laboratoire ne nécessitent pas de reprise lors de leur modification. Ainsi, on peut modifier une DU, un protocole, une norme, une feuille de paillasse sans avoir à reversionner l’objet modifié.

Par contre, dès lors que le paramétrage est au point et que celui-ci doit être utilisé en production, il est très fortement recommandé de passer le paramétrage en mode Exploitation.

Le versionnement permet :

• d’assurer la traçabilité du paramétrage : si un objet SOLUTION doit être modifié (DU avec ou sans formule de calcul, norme, protocole...), une trace de cette modification est conservée. Sans oublier que l'ancienne version, conservée, permettra la consultation de tout l'historique sans encombre.

• de garantir un fonctionnement correct du progiciel. En effet, l'objet paramétrable versionné est identifié dans la base par son nom et son numéro de version. Ainsi, lorsque cet objet est utilisé par le progiciel, la définition appelée est celle stockée dans la base identifiée par le nom et la version utilisés. L’exemple le plus flagrant se situe au niveau des feuilles de paillasse. Lors du placement d’échantillons sur feuille, SOLUTION Laboratoire utilise la définition du modèle de feuille stockée dans la base. Toute modification du modèle sans versionnement après le placement peut ainsi entraîner l’impossibilité de consulter les feuilles de paillasse créées avant cette modification. 

De ce fait, ALTIK ne peut garantir un fonctionnement correct du mode test pour une utilisation en exploitation. Enfin, il peut s’avérer impossible de résoudre un éventuel problème en mode test, étant donné qu’aucune trace des modifications n’est conservée.

Le progiciel SOLUTION Laboratoire est particulièrement souple au niveau de la réalisation d’interfaces. Il peut aussi bien communiquer par échange de données via des tables intermédiaires (ORACLE, SQL Server), par échange de fichiers (txt ou xml), par socket TCP/IP, par email, par MQ-Series, par FTP, etc…

Pour échanger des informations avec d’autres systèmes reposant sur une base de données (ORACLE, SQL Server), la méthode la plus efficace est l’échange par tables intermédiaires.

Première technique

L’un des systèmes possède naturellement une table de données d’échanges dans son schéma. L’autre système doit pouvoir consulter ces tables en temps réel. Sous ORACLE, il y accède par des vues (basée sur un datalink ORACLE). Les droits d’accès restreignent l’accès à ces tables en mode consultation uniquement.

Deuxième technique

Des tables particulières servent à l’échange d’informations. Pour chaque flux, on crée une ou plusieurs tables d’interface dans un schéma partagé par les deux systèmes. Ainsi, pour chaque table d’interface, l’un des systèmes est producteur d’enregistrements, l’autre est consommateur d’enregistrements. Sur chaque table d’interface, un champ, contenant un numéro chronologique, est géré de façon automatique (par un trigger ORACLE par exemple). Ce champ permet au système consommateur de traiter chronologiquement les enregistrements de la table.

Ces techniques ont déjà été mises en place par les équipes ALTIK. Elles sont entièrement maîtrisées.