Simulateur-LPS Manuel Utilisateur 1.0

Introduction

Objet du document

L'objet de ce manuel est de présenter comment installer, paramétrer et utiliser le Simulateur (injecteur) IDB/CLC, outil développé par KEREVAL basé sur la solution SoapUI (outil de test de web-services permettant l'exécution et le contrôle automatisé des échanges SOAP ou REST avec une application client ou serveur).

Portée du document

Ce document est à destination de l'Association Inter-AMC, les membres de l'équipe projet KEREVAL et toute autre partie prenante du projet IDB/CLC entre les échanges LPS et AMC.

Accès à la documentation

Les livrables se trouvent sur la plate-forme de test, dans la partie «Simulateur LPS»:

ou directement à cette adresse:

Le répertoire contient les éléments suivants:

  • Les fichiers paramétrables (XML) des cas de test utilisés par les simulateurs (CasDeTest.zip).

  • Le simulateur LPS, pour les requêtes IDB et CLC (projet SaopUI)

Installation du simulateur IDB/CLC

Pré-requis d'installation

JAVA doit être installé sur la machine où sera déployé le simulateur de requêtes IDB/CLC.

Si vous ne possédez pas JAVA, vous pouvez l'installer à partir de l'URL suivante:

Installation de l'outil SoapUI

L'outil SoapUI peut être téléchargé à partir de l'URL suivante:

Vous arriverez sur la page d'accueil du site. La version de l'outil présenté dans ce manuel est la v5.6.0

  • Cliquez sur l'onglet «SoapUI» (onglet affiché par défaut), et prenez la version correspondant à votre OS (Windows 64-bit dans l'exemple ci-dessous), en cliquant sur «Download».

  • Attendez la fin du téléchargement :

  • Ouvrez le fichier téléchargé :

  • Une fenêtre de pré-installation s'affiche, attendez que celle-ci se ferme:

  • Vous arriverez ensuite au sein de la procédure d'installation et vous devez simplement suivre les instructions d'installation:

Dernière étape, il faut ajouter une instruction pour forcer l'utilisation du protocole TLSv1.2. Pour ce faire il faut modifier le fichier «SoapUI-5.2.1.vmoptions» qui se trouve dans le répertoire «C:\Program Files\SmartBear\SoapUI-5.2.1\bin» et ajouter la ligne suivante à la fin du fichier: -Dsoapui.https.protocols=TLSv1.2 .

Une fois toutes les étapes d'installation réalisées, l'outil est installé sur votre machine.

Démarrer l'outil SoapUI

Pour démarrer l'outil SoapUI, il suffit simplement de double-cliquer sur l'icône suivante:

Vous arriverez sur la page d'accueil, vierge si aucun projet n'a été créé, suivante:

Installer le simulateur IDB/CLC

Le simulateur de requête IDB/CLC est un projet SopaUI, construit dans un fichier de type XML.

  • Cliquer sur «File» «Import Project» (ou directement via la combinaison de touche CTRL+i)

  • Sélectionner la dernière version du simulateur livré par KEREVAL, puis cliquez sur «Ouvrir»

Dans cet exemple, vous chargez le simulateur IDB+CLC.

  • Le simulateur est dorénavant déployé sur votre machine:

Utilisation du simulateur

Comprendre l'architecture du simulateur

Le Simulateur LPS est décomposé en plusieurs éléments:

  • 1. Le nom du projet

  • 2. Nom des méthodes dans le WebService (fichier wsdl)

  • 3. Suites de tests «Test Suite»

    => Il existe une suite de tests par catégorie de PS.

  • 4. Cas de test «Test Case»

  • 5. Suite d'étapes de test «Test steps»

  • 6. Pas de test «Step»

  • Le nom des méthodes dans le WebService (niveau 2) contient un wsdl pour IDB et un pour CLC.

  • Une suite de tests (niveau 3) correspond à un regroupement de tests. => Il existe une suite de tests par catégorie de PS.

  • Chaque cas de test (niveau 4) représente un test, dont le nom est identique à celui présent dans le cahier de tests de la plateforme Gazelle.

ATTENTION,

Vous ne devez à aucun moment modifier le nom des tests!

  • L'étape de test «replace» charge le message XML, jeu de données représentatif du cas de test, et l'enregistre dans la propriété «xml_flux»

  • L'étape de test «requestXXX» injecte le message XML construit dans la requête Soap et transmet le message vers le système d'information SI de l'AMC.

Exécuter un test

  • Pour exécuter un test, double cliquer sur le nom du cas de test souhaité (niveau 4 dans l'architecture du simulateur vue précédemment). Une fenêtre s'ouvrira avec les étapes de test.

  • Pour lancer le test, cliquer sur la flèche verte, premier élément de la fenêtre ouverte . Pour visualiser les étapes de test, cliquer sur l'onglet «TestsSteps». La liste des étapes de test s'affiche.

  • Votre résultat de test sera affiché par jeu de couleur (Rouge = KO / Vert = OK) en bas de cette fenêtre. Pour visualiser le résultat, cliquer sur le bouton «TestCase Log»

Afficher le détail d'une exécution

Après avoir exécuté un test, il peut être intéressant (notamment dans le cas d'un échec) de regarder le détail de l'exécution.

Pour ouvrir les logs de la requête «Aller», double-cliquer sur le dernier «Step»:

Remarque : Si vous êtes sur un cas de test IDB, cela sera le step 2, sur un CLC cela sera généralement le step 5.

Vous pourrez accéder à trois éléments:

  • Requête Aller, envoyée par le Simulateur LPS

  • Message Retour, généré par votre Service En Ligne

  • Informations complémentaires, heure d'exécution du test & URL de réception

Ci-dessous, vous pouvez voir la réponse que votre SI à retourné :

Il est également possible d'afficher cette même réponse au format raw (sans interprétation de SoapUi et sur une seule ligne) :

Valider le message Retour

L'objectif du simulateur est de fournir une requête afin que les Services En Ligne des AMC soient stimulés et génèrent des messages XML conformes au Cadre d'Interopérabilité des échanges PS-AMC.

Dans l'onglet «Response Message», vu dans le paragraphe précédent, copier le contenu du message et injecter le dans l'outil EVSClient pour validation.

Dans l'onglet «RAW» de la réponse, copier le contenu du message et injecter le dans l'outil «Validateur de signature XMLDsig» pour validation de la signature SAML.

Les paramètres du simulateur

SoapUI offre la possibilité de personnaliser les requêtes via des paramètres personnalisés (custom properties). Ces paramètres peuvent être définis à trois niveaux:

  • Au niveau du projet,

  • Au niveau des suites de tests (Test suite).

  • Au niveau des cas de test (Test case).

Paramètres au niveau du projet

Pour identifier les paramètres du niveau projet, il faut cliquer sur le nom du projet. Les paramètres apparaissent sous le nom du projet à coté des propriétés du projet (Project Properties).

Les différentes valeurs au niveau projet sont communes pour tout le projet. Vous y trouverez :

  • Le bénéficiaire par défaut (BENEF_00) avec ces différents paramètres

  • Le répertoire où sont présents les templates sur votre disque/serveur : xml_repertoire

  • Les endpoint IDB et CLC pour que le simulateur pointe vers votre SI

ATTENTION,

Il est important de renseigner tous les paramètres au niveau projet avant d'exécuter un step de cas de test.

Paramètres au niveau de la suite de tests

Pour identifier les paramètres de la suite de tests, il faut cliquer sur la TestSuite. Les paramètres apparaissent à coté des propriétés de la TestSuite projet (Project Properties). Cliquer sur Custom Properties

Toutes les Assertions SAML sont renseignées automatiquement dans les propriétés de la TestSuite.

Paramètres au niveau cas de test

Pour identifier les paramètres du niveau cas de test, il faut cliquer sur le nom du cas de test. Les paramètres apparaissent sous le nom du cas de test (au même endroit que les propriétés du projet) à coté des propriétés du cas de test (TestCase Properties).

Contrairement au niveau projet, la présence de paramètre au niveau des cas de test n'est pas systématique. Ils ne sont définis que pour les besoins spécifiques du cas de test.

Voici une liste de cas de test spécifique à renseigner => Variables à remplir :

  • IDB_KO_BENEF_SANS_DROITS => Bénéficiaire spécifique 05

  • CLC_KO_BENEF_SANS_DROITS => Bénéficiaire spécifique 05 + ID_Response_IDB

  • IDB_KO_SUSPENDU => Bénéficiaire spécifique 06

  • IDB_KO_SEL_NON_OUVERT => Bénéficiaire spécifique 08

  • IDB_OK_ODR_BS_NIR => Bénéficiaire spécifique 02

  • IDB_OK_ODR_BS => Bénéficiaire spécifique 02

  • IDB_OK_FORMULE => Bénéficiaire spécifique 07

  • CLC_OK_MEDG_SANSFORMULE => Bénéficiaire spécifique 07

  • IDB_OK_MEDS_MIXITEFORMULE => Bénéficiaire spécifique 09

  • AMC_CLC_018_OK_CSTE_SAGE => DATE_DEBUT_PRESTATION au format(YYYY-MM-DD)

Les différents bénéficiaires sont définis en bas de cette documentation.

ATTENTION,

Il est important de renseigner toutes les paramètres au niveau du cas de test avant d'exécuter le premier step de cas de test.

Customisation des simulateurs IDB/CLC

Edition des paramètres niveau projet

Comme vu dans le chapitre précédent, des paramètres au niveau projet ont été définies.

Ces paramètres sont de deux ordres:

  • Des paramètres de configuration des services web,

  • Des paramètres de jeu de données.

Les paramètres de configuration des web services sont:

  • xml_flux,

  • xml_repertoire,

  • endpoint_IDB et endpoint_CLC.

Les paramètres de jeu de données concernent le Bénéficiaire nominal, i.e. BENEF_00, utilisé dans la plupart des cas de test.

Paramètres de configuration des WS

Chargement du flux XML

Le paramètre «xml_flux» est placé dans la requête de telle manière que le flux concerné lors de l'exécution d'un test soit chargé dans la requête.

  • xml_flux: permet de charger un message XML. Ce paramètre ne doit pas être modifié!

ATTENTION,

  • les flux XML doivent être sans entête XML de type: "<?xml version="1.0" encoding="UTF-8"?>".
  • les flux XML doivent être encodés en UTF-8 sans BOM

Définition du répertoire des messages XML

L'emplacement des messages XML, IDBREQ et CLCREQ, est propre à chaque environnement. Il est défini par le paramètre «xml_repertoire». Ce paramètre doit être renseigné.

  • Pour cela, indiquer dans le champ «Value» de la propriété xml_repertoire le chemin d'accès au répertoire de stockage de vos messages XML IDBREQ et CLCREQ. Vous devrez probablement indiquer '\\' dans vos chemins d'accès.

    • Remarque : Vous devez ajouter un \ en fin de votre repertoire.

  • /!\ Pour rappel, l'ensemble des flux de test est fourni dans un répertoire avec les simulateurs de requêtes. Le fichier contenant ces flux s'appelle «CasDeTest_AAAAMMJJ.zip»

URLs d'accès à votre Service En Ligne

Afin que le simulateur communique avec votre Service En Ligne (de type IDB ou CLC), il faut paramétrer l'adresse URL du Service AMC. Le lien est fait via les paramètres «endpoint_IDB» et «endpoint_CLC».

Ce paramètre est injecté automatiquement dans les requêtes:

  • /!\ Ces paramètres doivent être de type «URL». Exemple: http://xxxxx:8088/ServiceIDB

Liste des PS de test

Vous trouverez la liste des PS dans les prérequis VILLE :

Paramètres des jeux de données

Les paramètres de jeu de données définis au niveau projet concernent le bénéficiaire nominal utilisé dans la majorité des cas de test. Si un bénéficiaire spécifique est requis alors il sera défini comme paramètre de cas de test.

Le bénéficiaire nominal est défini de la façon suivante:

  • Bénéficiaire nominal assuré depuis plus de 365 jours et présent les 10 jours suivants avec consigne CLC attendue. BENEF_00

  • Bénéficiaire nominal, i.e. BENEF_00

  • BENEF_00_NIR,

  • BENEF_00_CLE_NIR,

  • BENEF_00_DATE_NAISSANCE,

  • BENEF_00_NOM,

  • BENEF_00_PRENOM,

  • BENEF_00_NUM_AMC,

  • BENEF_00_NUM_ADHERENT,

  • BENEF_00_NIR_CERTIFIE,

  • BENEF_00_CLE_NIR_CERTIFIE,

  • BENEF_00_CSR.

Tous les paramètres décrits ci-dessous seront injectés dans les flux pour les tests. Cette injection est réalisée lors de l'étape de test nommée «replace».

De façon générique, ces paramètres représentent:

  • BENEF_xx_NIR: NIR du bénéficiaire xx

  • BENEF_xx_CLE_NIR: Clé NIR du bénéficiaire xx

  • BENEF_xx_DATE_NAISSANCE: Date de naissance du bénéficiaire xx

  • BENEF_xx_NOM: Nom du bénéficiaire xx

  • BENEF_xx_PRENOM: Prénom du bénéficiaire xx

  • BENEF_xx_NUM_AMC: Numéro d'AMC attaché du bénéficiaire xx

  • BENEF_xx_NUM_ADHERENT: Numéro d'adhérent du bénéficiaire xx

  • BENEF_xx_NIR_CERTIFIE: NIR certifié du bénéficiaire xx

  • BENEF_xx_CLE_NIR_CERTIFIE: Clé du NIR certifié du bénéficiaire xx

  • BENEF_xx_CSR: CSR de l'AMC qui est attaché au bénéficiaire xx

  • BENEF_xx_TYPE_CONV : Type de convention associée à AMC attaché du bénéficiaire xx

ATTENTION,

Il est impératif de conserver le nom du paramètre concerné (colonne «Name») lors d'une modification de sa valeur. Ce nom est injecté dans TOUS les messages XML.

Edition des paramètres au niveau cas de test

Comme vu dans le chapitre précédent, des paramètres au niveau cas de test ont été définis.

Ces paramètres sont de type «jeu de données» et décrivent des bénéficiaires différents. La description des paramètres est la même que celle du niveau projet.

La description des différents bénéficiaires sont les suivantes:

Bénéficiaire «ouvrant droit» (le père) BENEF_01
Bénéficiaire lié à l' «ouvrant droit» (différent du père) BENEF_02
Bénéficiaire sans n° adhérent BENEF_03
Bénéficiaire inconnu BENEF_04
Bénéficiaire sans droits BENEF_05
Bénéficiaire contrat suspendu non résilié BENEF_06
Bénéficiaire retournant un IDB avec formule 090 BENEF_07
Bénéficiaire sans SEL ouverts BENEF_08
Bénéficiaire avec ATM en CLC et Domaine (MEDS) en 090 BENEF_09

ATTENTION,

Vous devez être capable au moment de l'exécution des tests de faire des liens entre les descriptions de ces bénéficiaires et des bénéficiaires existants dans votre système d'infirmation de qualification.