SEPA_TGEN est une gamme de produits conçus pour aider les entreprises et les banques à qualifier leurs nouvelles plates-formes de traitement SEPA. Cette application permet de :

• identifier des cas de tests
• décrire le contenu du ou des fichiers composant ces cas de test selon une spécification basée sur l'ISO20022
• générer des R-messages à partir de fichier XML existant
• rapprocher/vérifier des fichiers SEPA ou fichiers à plat pour comparer automatiquement les évènements et les données présents avec l'injection initiale. 

SEPA_TGEN for Corporate est destiné aux entreprises. Son périmètre fonctionnel concerne les besoins liés à la relation Client-Banque (C2B).

SEPA_TGEN for bank est destiné aux banques. Il couvre les besoins liés à la relation client-banque (les flux pain) et ceux de la relation interbancaire (les flux pacs).

Un cas de test représente pour SEPA_TGEN un jeu d'essai ou un ensemble de jeux d'essai. Un jeu d'essai se matérialise par un fichier, il est défini par une structure "FILE" à laquelle est rattaché le format de génération (XML pain, XML pacs, format à plat).

La description de ces structures "FILE" s'appuie sur les définitions des messages ISO20022 composés de "niveaux" XML (group header, payment level, transaction level correspondant à des notions d'entête, remise et opération). Ces niveaux sont composés de données, dépendantes de la version ISO choisie et du type de paiement en cours de définition (virement, prélèvement).

Ces cas et jeux d'essai sont définis soit manuellement (en utilisant ou non des objets prédéfinis ou des meta-données), soit en chargeant des fichiers existants et en les personnalisant.

L'application permet de définir des meta-données représentant tout type de données homogènes (relatives à un même niveau XML et type de paiment). Ces ensembles nommés peuvent être utilisés dans toute définition de même nature pour accélérer la définition de ces jeux d'essai.

L'application permet également de définir des objects type comme des headers ou des remises (entête de remise et opérations). L'utilisation de ces objets est l'un des facteurs de la rapidité de spécifications des fichiers.

Les cas et jeux d'essai se définissent en général à partir des objets type et méta-données puis sont personnalisés par rapport au besoin recherché. Cette approche permet de limiter la définition du cas à la seule saisie des quelques données ou valeurs caractérisant le cas.

Chaque donnée peut être valorisée selon différentes méthodes : 

• affectation automatique : la valeur est définie par l'application et selon le paramétrage utilisateur
• affectation explicite : les valeurs sont définies par l'utilisateur
• affectation XML : des arbres XML peuvent être saisis.

Il est également possible de forcer l'absence de valeur (Null tag) ou l'absence de la donnée (absence du tag XML définissant la donnée ou l'arbre XML).

Certaines données peuvent également être valorisées via les données de type "partie" décrites ci-après.

Pour identifier tout ou partie des données des "debtors" ou "creditors" ou encore ceux des ultimate, une base de "parties" est gérée par cette application. Cette notion est plus générique qu'une meta-donnée utilisant les mêmes données unitaires car indépendante de la notion de débiteur/créditeur : une partie est juste un nom (identifiant) pouvant être utilisé comme débiteur ou créditeur ou ultimate.

Elle permet d'identifier les éléments ISO associés : nom, identifiants, adresse postale, pays de résidence, contacts.

Ces données peuvent être regroupées par famille et être utilisées dans les tests de charge ou dans n'importe quel cas fonctionnel.

Cette fonction a été principalement conçue pour accéler les phases de test de non régression mais peut être utilisée à d'autres fins.

Elle permet de :

• regrouper des cas de test selon un choix utilisateur,
• générer unitairement ou par ensemble les jeux d'essais correspondants
• définir un statut d'avancement et annoter le cas
• archiver toutes les données lorsque tous les cas ont été traités jusqu'au bout.

Elle permet ainsi de générer des centaines de jeux d'essai et vérifier leurs effets via la fonction de rapprochement (voir ci-dessous).

Remarques :

• Cette fonction vient en général en complément d'autres outils comme Quality Center, le lien étant le nom du cas de test
• l'automatisation des injections n'est pas pris en charge par l'application mais peut être réalisée via un module QTP par exemple.

Cette fonction permet de générer tout message "R" émis ou reçu soit manuellement soit selon un modèle prédéfini.

Un R-message émis (annulation par exemple) peut être défini et rattaché à un jeu d'essai initial défini dans SEPA_TGEN et créé automatiquement lors de la génération de ce jeu initial.

En général, les R-messages doivent être créés à partir de fichiers XML générés par d'autres applications. Dans ces cas, leur création s'effectue via le chargement préalable de ces fichiers et la définition des évènements souhaités soit manuellement soit via modèle.

Ces évènements peuvent être rattachés à tout niveau XML : group header, remise ou opérations.

Cette fonction permet de vérifier la qualité des flux produits par des applications tiers (canaux, moteur de paiement...) à partir des jeux d'essai générés par SEPA_NGEN. Elle permet ainsi d'automatiser la comparaison des évènements et données fonctionnelles et accélère la qualification de ces applications intermédiaires.