Rapport stage 2005 - nade77.free.frnade77.free.fr/CV/CV_gonord_fichiers/Rapport_stage_2005.pdf · Par la suite, je propose une synthèse sur les différentes étapes qui ont constitué

Intitulé Rapport de stage de fin d’études

Auteur GONORD Nadège

Etudes DESS CRI

Année 2004 - 2005

Société STERIA, 46 rue Camille Desmoulins,

92 782 Issy-les-Moulineaux

Tuteur LABORDE Pascal

[email protected]

RRaappppoorrtt ddee ssttaaggee DDEESSSS CCRRII

CCCOOOMMMPPPIII LLLAAATTTEEEUUURRR DDDEEE SSSTTTUUURRRSSS

Rapport de stage de fin d’études - 2 -

REMERCIEMENTS

Je tiens à remercier les personnes suivantes grâce auxquelles j’ai pu réaliser ce projet :

Pascal LABORDE, demandeur et tuteur du projet, pour la confiance qu’il m’a accordée. Marc ALBOUY, conseiller technique du projet, pour ses conseils, ainsi que pour sa grande disponibilité. L’ensemble des collaborateurs de l’équipe STECARD, pour leur accueil et leur soutien.


RESUME

Le présent rapport fait état du travail que j’ai effectué au cours des six mois de mon stage de

fin d’étude DESS CRI à l’Université de Marne la Vallée. Ce stage se déroule sur une période de six mois, d’avril à septembre à Paris, dans une société

de service et d’ingénierie informatique (SSII), la société STERIA. Cette société fait partie des SSII les plus importantes aussi bien au niveau national qu’international. Elle est notamment très présente dans le domaine bancaire avec le développement d’une solution monétique très complète. La monétique correspond à l’ensemble des techniques électroniques et informatiques permettant d’effectuer des transactions bancaires. La société STERIA développe notamment un serveur monétique, STECARD qui est un produit bien connu sur le marché de la monétique.

Mon stage a eu pour but de réaliser une maquette d’un compilateur permettant de générer un

programme d’analyse de message bancaire en langage C, à partir de fichier qui définissent les règles de spécification techniques d’utilisation du réseau pour les cartes bancaires. En cas de succès de cette maquette, moindre coût de développement et rapidité d’exécution, une version améliorée sera réalisée et intégrée au produit STECARD.

J’ai réalisé cette application conformément aux directives qui m’ont été transmises par mon

tuteur au sein de ce projet, monsieur Pascal LABORDE. Aujourd’hui cette application est encore en cours de développement et n’a donc pas encore

été testée. Mon stage se poursuit jusqu’au 10 octobre 2005.


SOMMAIRE

1. Introduction.........................................................................................................................5

2. Présentation de l’environnement........................................................................................6

2.1. La société STERIA .................................................................................................................. 6

2.2. Le secteur Banque ................................................................................................................... 7

2.3. Le département Monétique et Messagerie bancaire (MMB)............................................... 8

3. Présentation de ma mission ..............................................................................................12

3.1. Le but de ma mission ............................................................................................................ 12

3.2. Les spécifications ................................................................................................................... 12

3.3. Le déroulement du stage....................................................................................................... 13

4. Etude et analyse de l’existant............................................................................................14

4.1. Fonctionnement général de l’application ............................................................................ 14

4.2. Structure d’un message......................................................................................................... 17

5. Analyse fonctionnelle........................................................................................................21

5.1. Principe de la modification................................................................................................... 21

5.2. Fichiers de règles ................................................................................................................... 22

5.3. Outils pour créer le compilateur.......................................................................................... 28

5.4. Le simulateur ......................................................................................................................... 29

6. Analyse technique .............................................................................................................33

6.1. Organisation du développement .......................................................................................... 33

6.2. Le développement.................................................................................................................. 34

7. Conclusion.........................................................................................................................39

7.1. Ce qui reste à faire ................................................................................................................ 39

7.2. Du point de vue de l’entreprise ............................................................................................ 39

7.3. Du point de vue personnel .................................................................................................... 39

1. Planning ............................................................................................................................40

1.1. Planning de développement du projet ................................................................................. 61

1.2. Diagramme de Gantt............................................................................................................. 62

2. Cahier de tests sur RCB ....................................................................................................64

2.1. Tests préliminaires ................................................................................................................ 64

2.2. Tests approfondis .................................................................................................................. 67

3. LEXIQUE..........................................................................................................................68

Université de Marne-la-vallée DESS CRI


1. INTRODUCTION La formation de DESS CRI dispensée par l’Université de Marne la vallée se finalise par un

stage en entreprise d’une durée de quatre à six mois. L’objectif de ce stage de fin d’études est de valider cette dernière année universitaire par la

mise en pratique, dans des projets plus importants, des enseignements dispensés durant la totalité du cursus. De plus, ce stage a pour but de faciliter l’intégration dans le monde de l’entreprise.

Pour ma part, ce stage s’est déroulé au sein de la société STERIA à Issy-les-Moulineaux,

l’occasion pour moi de découvrir l’environnement si particulier d’une importante Société de Service et d’Ingénierie en Informatique. La mission qui m’a été confiée avait pour but la réalisation d’un compilateur, permettant de générer un programme C à partir de fichiers de règles dont on a défini la syntaxe. Le programme C généré permet l’analyse de la structure et de la syntaxe de transactions bancaires.

Ce rapport présente le travail que j’ai réalisé durant les six mois de mon stage. Pour commencer, je vous présenterai la société STERIA ainsi que le département dans lequel

se déroule encore actuellement mon stage. On trouvera également une description de la mission qui m’a été confiée, ainsi que les

conditions dans lesquelles elle a été définie. Par la suite, je propose une synthèse sur les différentes étapes qui ont constitué mon projet :

l’étude et l’analyse de l’existant, la recherche de solutions, la rédaction des documents fonctionnel et technique, le développement et les tests d’intégration.

Enfin, je terminerai ce rapport en faisant le point sur l’état d’avancement de l’application à

la fin de mon stage, et en établissant un double bilan de ce projet : pour STERIA et pour moi-même.



2. PRÉSENTATION DE L ’ENVIRONNEMENT

2.1. La société STERIA STERIA se place aujourd'hui parmi les dix premières sociétés de services informatiques en

Europe. Ses trois métiers - le conseil, l'intégration de systèmes et l'infogérance - en font un opérateur global de services informatiques.

Des infrastructures informatiques aux applications, STERIA répond à l'ensemble des besoins

de ses clients, de la conception, au développement et à l'exploitation des systèmes d'information. Présent dans 12 pays et dans les principaux secteurs de l'économie, STERIA fait partie des dix

premières sociétés informatiques d'Europe.

1. Les offres sectorielles de STERIA : STERIA constitue le lien entre les utilisateurs finaux des différents secteurs de l'économie et

les fournisseurs du marché de l'information, en tant qu’intégrateur de systèmes et de services. Aujourd’hui elle est présente sur quatre grands secteurs de marché : banque et assurance, secteur public, industrie/énergie/transport et télécommunication.

Le découpage de la société prend forme en trois domaines liés aux secteurs d’activités : - Infogérance - Conseil - Intégration de systèmes J’évolue actuellement à l’intérieur du secteur d’activité « Banque et assurance ». Il a pour

vocation d’accompagner les établissements financiers dans leur objectif de développement externe par l’expertise de Steria sur les systèmes d’information.

2. Les chiffres clefs : • 9 000 collaborateurs en 2005 (en moyenne) • 1 500 nouvelles embauches prévues pour 2005 (dont 50% de jeunes diplômés) • Age moyen : 36 ans • 70 % d'hommes, 30 % de femmes



2.2. Le secteur Banque Le pôle Banque est un secteur en perpétuelle évolution, c’est un environnement fortement

concurrentiel, impacté par de nouvelles réglementations européennes et internationales. Steria accompagne ses clients dans ces évolutions, en mettant en œuvre des solutions industrialisées telles que les systèmes de gestion de la relation client de deuxième génération, visant à développer leur activité commerciale.

La Banque est un domaine de compétence faisant partie du cœur de métier Steria avec une

clientèle fidélisée de longue date. C’est un marché important et stable pour le groupe représentant un quart de l’activité totale.

Le Secteur de la Banque est organisé comme suit : • Monétique et Messagerie Bancaire • Banque Finance Intégration • Banque Service Intégration • Application & Data Migration Chacun de ces services est formé d’un chef de département, d’un directeur de produit, de

chefs de projets et d’ingénieurs. Spécialisées selon leurs compétences techniques, les équipes interviennent en clientèle sous forme de forfait ou de régie.

Transversalement à ces services, des postes sont rattachés directement au département.

Enfin, le directeur de proposition, les ingénieurs commerciaux et les ingénieurs qualité sont affectés par comptes clients.



2.3. Le département Monétique et Messagerie bancaire (MMB) A l’intérieur de cette entité, je travaille dans le département « Monétique et Messagerie

bancaire » (MMB) à la charge de Frédéric Diverrez. Ce département est spécifique dans l’organisation de STERIA car il a pour particularité d’éditer des produits autour de la monétique et de la messagerie bancaire. Comme toute société de services, STERIA vend avant tout, des prestations de service autour de gros projets d’intégration. Voici un bouquet des offres proposées par le service MMB suivant quatre grandes activités :

• Conseil

− Stratégie business − Urbanisation − Etudes d’impact et d’opportunité − Conduite du changement

• Services − Infogérance, Externalisation − Support et services autour de l’offre : Produits − Tierce Management Applicatif

• Produits − Stelink − Stematch − Stecard, Stegab − Steform − STP Toolkit

• Intégration − Grands projets d’intégration − Globalisation des échanges − SWIFTNet, EAI, e-STP − Carte bancaire et monétique − Sécurité (PKI)

Pendant mon stage, j’ai intégré l’équipe de développement de STECARD, produit développé

par le département MMB. L’équipe produit STECARD se compose d’un responsable produit, Pascal LABORDE, d’un responsable technique, Vincent LENGLET, d’une quarantaine de réalisateurs ainsi que d’une équipe de consultants agissant sur divers domaines fonctionnels.



1. La monétique La monétique c’est l’ensemble des techniques électroniques et informatiques permettant

d’effectuer des transactions bancaires : • sans échange de papier, • et avec utilisation d’un support de type carte bancaire. La carte bancaire est devenue un support de services et d’informations de plus en plus

utilisé. La gestion des opérations sur carte requiert des caractéristiques de fonctionnement bien spécifiques en terme de fiabilité, de disponibilité, de performance et d'évolutivité.

Outre sa qualité de moyen de paiement aisé, la carte est devenue un support de services et

d’informations. Les nécessités de la lutte contre la fraude ainsi que le développement des transactions et des services supportés par les cartes concourent à l'accroissement du trafic.

Sur l'ensemble de l'année 2002, le nombre d'autorisations a augmenté de +15,7 % par

rapport à 2001. Tandis que le nombre de transactions fait un bond de 10.4 % entre 2001 et 2002. De plus, si les banques décident de rendre les chèques bancaires payants, une explosion du trafic verra le jour. Ci-dessous, nous pouvons visualiser l’ensemble des éléments qui interagissent pour former l’environnement de la monétique.

Environnement général de la monétique :

RESEAUX INTERNATIONAUX ET DOMESTIQUES

AUTORISATIONS COMPENSATION

FRONT OFFICE

AUTORISATIONS

GESTION DES TPE

GESTION DES GAB

ENVIRONNEMENT CENTRE CARTE

SYSTEME D’INFORMATION DE LA BANQUE GESTION DES CLIENTS ET COMPTES

FOURNISSEUR

CCAARRTTEE &&

CCOODDEE

CCOONNFFIIDDEENNTTIIEELL

BACK OFFICE

CONTRAT COMMERCANT

GAB

CONTRAT PORTEUR

GESTION DES

TRANSACTIONS

AGENCE

TTPPEE GGAABB

COMMERCANT

TTPPEE



Le système doit assurer un fonctionnement permanent du réseau : 24 heures sur 24, 7 jours sur 7. Toute dégradation du temps de réponse a un impact immédiat sur la rentabilité du système : mise en place de procédures manuelles longues et coûteuses, accroissement du risque par l'acceptation de transactions non autorisées, voire, dans le cas des guichets automatiques bancaires, diminution de la disponibilité et du niveau d'activité du service…

Il convient donc de prévoir un équipement qui maintienne un haut niveau de performance,

quel que soit le type d'incident qui puisse survenir. Dans un domaine où les nécessités de la lutte contre la fraude ainsi que le développement

des transactions et des services concourent à l'accroissement du trafic, la solution STERIA est capable de suivre ces augmentations, sans dégradation de la fiabilité et des performances du service.

2. Stecard Le progiciel STECARD est un serveur monétique réalisé par le département MMB. STECARD

est un gestionnaire de terminaux de paiement électroniques (TPE), et d’automates bancaires. C’est aussi un serveur d’autorisations de retraits et paiements, il gère l’administration de réseaux.

Aujourd’hui, plus du tiers du parc français de terminaux monétiques est géré par ce logiciel.

Précisons que les TPE sont des terminaux sur lesquels les clients saisissent leur code confidentiel lorsqu’ils effectuent un achat chez un commerçant par carte. Lorsqu’un achat d’un montant dépassant une certaine limite fixée par les banques est réalisé, une demande d’autorisation doit être faite à la banque. Celle-ci doit interroger les bases de données pour savoir si le client est solvable, si la carte n’a pas été opposée…STECARD est donc un système temps réel, dit de front office. Il gère une interface avec des systèmes dits de « back office », qui sont des logiciels de gestion et d’administration des concepts et des produits bancaires internes à la banque, non temps réel. Ce progiciel mutli-secteurs, multi-terminaux et multi-plates-formes conçu dans une architecture client-serveur est modulaire et évolutif.



STECARD couvre les domaines fonctionnels suivants : • gestionnaire de Terminaux Monétiques (DAB1 , GAB2 , TPE3 ,...) • routage des flux monétiques • serveur d'autorisations • serveur d'oppositions • serveur de sécurité • gestion du risque • connexion aux centraux bancaires • libre service bancaire • télécollecte, téléparamétrage • connexion aux réseaux d'autorisation (RCB, VISA, MASTERCARD, EUROPAY,

privatifs,...) • supervision des terminaux électroniques (Administration Réseaux et Données)

Quelques références en terme de clients de STECARD sont : la Poste, le Crédit Lyonnais, la Caisse d'Epargne, la Banque du Sud (Tunisie), la Beobanka (Yougoslavie), Byblos au Liban, et le groupe CT6, qui englobe le CIC, Crédit Mutuel, Cetelem, Carrefour, CCF, Société Générale et d'autres banques.

3. L’organigramme du département

Chaque produit édité est sous la charge d’un responsable qui contrôle et valide ses évolutions.

Pascal Laborde remplit ce rôle pour le produit Stecard, tandis que Hervé Deschamps lui remplit ce rôle pour le produit Stelink. Il encadre aussi les responsables de compte dont l’objectif est de maintenir chaque version cliente du produit en adéquation avec les besoins exprimés par ces derniers.

1 Distributeur automatique de billet 2 Guichet Automatique de Billet 3 Terminaux Electroniques de Paiement



3. PRÉSENTATION DE MA MISSION

3.1. Le but de ma mission Le but de mon stage au sein de la société STERIA est de concevoir, de développer et de

tester un compilateur permettant, à partir d’un fichier texte dont on définit la syntaxe, de générer un programme en langage C. Ce programme permet l’analyse à la fois lexicale et syntaxique d’une transaction bancaire.

3.2. Les spécifications Au sein du département est développés un produit phare de la société STERIA, à savoir

STECARD, logiciel de monétique. Ce produit est soumis à une réglementation européenne sur l’utilisation du réseau et les spécifications d'échange de messages.

La norme ISO8583, est une norme émanant de l'organisme mondial de normalisation ISO

(International Standard Organisation) et spécifiant les messages initiés par carte de transaction financière, et les spécifications d'échange de messages.

Les STURs Spécifications Techniques d'Utilisation du Réseau, sont les normes qu’un

appareil doit respecter pour avoir la permission de se connecter à un réseau. Ces normes sont nécessaires pour éviter qu'un seul appareil vienne tout gâcher en mettant le désordre sur le réseau. Ils sont mis à jour tous les ans et respectent la norme ISO8583.

La norme EMV (Europay Mastercard Visa) est un standard international de carte à puce

définie conjointement par Europay, Mastercard et Visa. EMV permet à de nombreux pays de disposer pour la première fois de cartes bancaires à puce, plus sûres, et non plus à piste magnétique. Cette puce permet d'offrir de nouveaux services aux porteurs et aux commerçants.

Le problème, lié aux normes et principalement lié aux STURs, est qu’il force à reprendre

annuellement une partie du code du logiciel STECARD, pour être conforme aux spécifications d’utilisation du réseau. De plus, il existe plusieurs protocoles de transport de messages et suivant le protocole utilisé et les données contenues, dans les messages envoyés par les banques les règles que l’on doit appliquer à ces messages ne sont pas toujours identiques.

Pour cette raison, l’équipe de STECARD a souhaité se munir d’un fichier de configuration qui

pourra être plus facilement modifier que du code et qui sera propre à ces clients. Ce fichier de configuration sera la base pour générer le code de vérification de la conformité des messages aux différentes normes de formation des messages et les différents protocoles de transport de ces messages.



3.3. Le déroulement du stage Pour ce stage j’ai évoluée en parfaite autonomie, aidée et guidée par mon maître de stage

Pascal LABORDE, ce stage s’est déroulé en plusieurs étapes, ce qui m’a permis de mener ce projet de bout en bout.

� Etude et analyse de l’existant :

o Lecture des STURs. o Etude du code du protocole RCB existant. o Découpage manuel d’un message permettant une transaction. o Recherche d’une syntaxe pour le fichier de configuration. o Etudes des divers compilateurs existants.

� Analyse fonctionnelle : o Récapitulatif des spécificités générales du fonctionnement du programme. o Définition de la syntaxe choisie pour le fichier de configuration. o Choix des outils permettant de créer le compilateur. o Ecriture du document d’analyse fonctionnel.

� Spécification Techniques : o Définition des fichiers créés et de l’arborescence. o Etablissement du planning de réalisation. o Ecriture du cahier des charges techniques détaillées. o Ecriture du cahier de tests.

� Développement : o Ecriture des fichiers de configuration. o Réalisation d’une première version, compilateurs et simulateur, permettant

une vue d’ensemble. o Tests de raccordement et de performance. o Réalisation d’une seconde version, mise à jour des compilateurs, plus

performante. � Tests d’intégration :

o Jeux de tests des STURs. o Tests en définissant d’autres protocoles. o Tests de raccordement et de performance. o Tests de saturation du réseau.



4. ETUDE ET ANALYSE DE L ’EXISTANT

4.1. Fonctionnement général de l’application

1. Le protocole RCB/RSB

� Principe de fonctionnement Le système accepteur est lié à la banque A par contrat, sur un réseau privé en X25 ou IP.

Nous voyons ici le cas où le porteur de la carte de paiement n’appartient pas à la banque A, dans ce cas précis la banque A doit contacter la banque B, via le réseau RCB/RSB qui est géré par le GIE carte bancaire, c’est un ensemble de banques gérant les cartes bancaires. Pour contacter la banque B, la banque A passe par le processus RCBD (RCB demandeur) du logiciel STECARD, qui transforme le message du terminal en un message RCB/RSB celui-ci pourra ainsi transiter sur le réseau. Le message arrive sur le serveur d’autorisation, il est retransformé par le processus RCBS (RCB serveur) puis un dialogue avec le système central de la banque est engagé pour contrôler la sécurité et accepter ou non la transaction. Une réponse est envoyée au système accepteur en transitant de nouveau sur le réseau RCB/RSB.

Remarque : Le réseau d'autorisation RCB (Réseau de cartes bancaires) est remplacé

progressivement par un réseau plus moderne, le RSB (Réseau de services aux banques). Cette migration vise à fournir à la profession bancaire un système plus performant et ouvert en mesure d'absorber durablement les volumes d'autorisations interbancaires ce qui implique le passage de X25 à une technologie IP. Aujourd’hui encore les deux réseaux cohabitent et le déploiement doit se faire au fur et à mesure, les banques ayant soit à gérer différentes priorités, soit à réaliser d'ultimes tests avant de basculer au nouveau réseau.



2. Etude du code RCB existant

� Les diverses couches du programme Le programme RCB se découpe en plusieurs couches pour le traitement des transactions

bancaires :

J’ai travaillé au niveau de la couche présentation, sur l’analyse et le découpage d’un

message et sur son stockage, la couche application est en réalité un automate qui appelle à plusieurs reprise la couche présentation.

� La couche application Principe de l’automate : Pour l’étude d’un message bancaire.

• Réception de la demande du réseau o Analyse de la question o Envoie la question à l’application o Lance une horloge

• Réception par l’application

o Arrêt de l’horloge o Constitue la réponse o Envoie la réponse au réseau

• Alarme

o Constitue la réponse KO (time out) o Envoie la réponse au réseau

Attente



� La couche présentation RCBS : Le module RCBS reçoit une question, l’analyse, vérifie sa cohérence, la découpe et la stocke

dans une structure que l’on envoie à l’application. On stocke la question dans un contexte, l’application renvoie ou non une réponse dans un temps donné (Réponse OK/KO), si une réponse est reçue, on vérifie sa cohérence par rapport à la question, dans l’autre cas on construit la réponse (KO pour cause de time out).

RCBD : Le module RCBD construit une question (format de message) à partir d’une structure et

l’envoie, puis s’il reçoit une réponse (KO/OK), il l’analyse, vérifie sa cohérence par rapport à la demande et la découpe dans sous forme de structure que l’on envoie à l’application. Si au bout d’un certain délai, il n’a pas reçu la réponse, il la construit (KO).



Résumé : A la réception d’une question, on :

• Analyse la question (découpe) • Stocke la question dans la structure • Contrôle la conformité de chacun des champs (règles). • L’envoie à l’application/réseau qui renvoie ou non une réponse • Applique les règles de construction/conformité d’une réponse.

En cas de time out, on construit la réponse KO à partir de la question, sinon on vérifie la réponse à partir des données de la question puis on envoie la réponse à l’application/réseau

4.2. Structure d’un message

1. Structure du message

� Structure générale Les messages utilisés par le protocole STUR sont conformes à la norme ISO 8583. Chaque message a l'une des deux structures suivantes :

Identifiant Bitmap Ch i … Ch j … Ch k avec i, j et k variant de 2 à 64 ou

Identifiant Bitmap Bitmap Ch i … Ch j … Ch k avec i, j et k variant de 2 à 128. Il comprend donc les parties suivantes :

- l'identifiant du type de message, - 1 ou 2 bitmaps, - les champs de données qui apparaissent par ordre croissant de numéro de champ à

l'intérieur du message.



� Identifiant L'identifiant du type de message est un champ numérique, de longueur 4 et codé en DCB.

C'est un champ obligatoire. Les identifiants utilisés dans le protocole STUR sont :

� Bitmap Chaque bitmap est composée de 64 bits numérotés de gauche à droite.

Deux bitmaps sont définies. La première est obligatoire, la deuxième est optionnelle. Le premier bit de la première bitmap spécifie la présence ou l'absence d'une seconde bitmap. Dans chaque bitmap, un bit à 1 exprime la présence du champ associé, un bit à zéro son absence. La présence d'une deuxième bitmap indique que le sceau du message est transporté dans le champ 128, même si le champ 128 est le seul champ utilisé dans la deuxième bitmap.



2. Structure des champs du message

� Format des champs

Champs de longueur fixe : Les champs numériques de longueur fixe sont justifiés à

droite, avec des zéros en tête le cas échéant. Les champs binaires occupent un nombre entier d'octets. Les autres champs sont justifiés à gauche et complétés par des blancs.

Champs de longueur variable : Les champs de longueur variable sont précédés d'un octet indiquant la longueur du champ. Le codage de cette longueur est réalisé en binaire. La longueur d’un champ variable est comprise entre 1 et 255 octets.

Champs de structure TLV (Type Longueur Valeur) : Les champs TLV sont des champs de longueur variable contenant un ou plusieurs éléments de données de structure TLV. Ils se présentent de la façon suivante :

Longueur totale du champ Elément de données 1 … Elément de données n

La longueur totale du champ, comme pour tous les champs de longueur variable, est codée en binaire sur 1 octet. Elle exprime la longueur des éléments de données en nombre d’octets. Un élément de donnée est constitué de la façon suivante :

- « T » : le type d'élément de donnée, - « L » : longueur de la donnée (supérieure ou égale à 1). Elle n’est pas intégrée dans

le calcul de la longueur de la donnée. Elle exprime le nombre d’octets permettant de transporter la valeur « V » à suivre.

- « V » : valeur de la donnée sur le nombre de caractères défini par la longueur. Un champ TLV a donc finalement la structure suivante :

Elément de données 1 … Elément de données n Longueur totale du champ Type

n Longueur

n Valeur

n … Type n

Longueur n

Valeur n



� Type des champs

� Codage des champs

• Données de format "numériques" (n) : Pour les STURs, ces champs de données sont codés en DCB.

• Données de format "binaire" (b) et de format 'z' (Piste ISO2) : Pour les STURs, ces champs de données sont codés en binaire.

• Données de format "caractères" (a, an, as, ns, ans, …) : Pour les STURs, ces champs de données sont codés en ASCII ou en EBCDIC.

� Exemple

…

…



5. ANALYSE FONCTIONNELLE

5.1. Principe de la modification

1. Utilisation des fichiers de règles Il fat réécrire les deux modules RCBS et RCBD en utilisant des fichiers de règles pour

vérifier la conformité des messages reçus, on réalise une vérification à la fois lexicale et syntaxique et on donne les règles pour construire la réponse à la demande. On stocke les questions et réponse dans des buffers FML. Une partie du code est réutilisée et l’autre est générée automatiquement à partir des fichiers de règles.

2. Etude du message en 3 étapes Etapes pour l’analyse d’une question :

• Découpage des différents champs et sous-champs du message par type, format et longueur à partir des fichiers de règle créés et stockage dans les buffers FML associés. (Analyse Lexical)

• Vérification des valeurs possibles que peuvent prendre chacun des champs (règles générales s’appliquant à tout type de message). (Analyse syntaxique)

• Vérification des règles de valeur et de présence des champs suivant le type du message et construction de la réponse en cas d’erreur ou de time out. (Analyse syntaxique)

On effectue les étapes inverses pour la construction d’une réponse :

• Vérification des règles de valeur et de présence des champs suivant le type de la réponse et vérification de la cohérence par rapport à la question. (Analyse syntaxique)

• Vérification des valeurs possibles que peut prendre chacun des champs (règles générales s’appliquant à tout type de message). (Analyse syntaxique)

• Construction du message réponse à partir des buffers FML. (Analyse Lexical)

Fichiers de règles

Programme C Compilateur



5.2. Fichiers de règles

1. L’analyse lexicale

� Principe général Description de la première étape : Découpage et reconstitution du message.

A partir des fichiers de règles d’analyse lexicale et à l’aide des outils Flex et Bison, on crée

un parseur, qui génère un programme C possédant une fonction de découpage et une fonction de reconstitution du message. Ce programme C fait appel à des fonctions déjà existantes de la librairie comme par exemple le découpage d’un champ LLVAR.

Lorsque le programme généré reçoit un message, il le découpe et stocke les données dans un

buffer FML et inversement lorsque les données sont stockées dans un buffer FML, il reconstitue un message.



� Syntaxe du fichier décrivant les champs L’analyse lexicale du message se fait à partir de deux fichiers de règles, suivant le

protocole utilisé ici ISO8583, le premier décrivant les divers champs présents dans la bitmap le second permettant la description des sous-champs de type TLV. Même si ces deux fichiers sont séparés l’analyse d’un champ est suivit de l’analyse de ses sous-champs s’il en possède.

Voici un extrait du fichier de découpage des champs ISO8583 :

Description des instructions : • L’instruction Field …End nous permet

de délimiter la description du champ. • L’instruction Name correspond au nom

de la variable de stockage du champ si le champ n’est pas un buffer FML on le déclare avant dans un fichier *.h.

• L’instruction Description correspond à la description du champ c’est une chaîne de caractère.

• L’instruction Type peut avoir les valeurs suivantes FIXE pour un champ non variable LLVAR, LLLVAR,LLVAR_B pour les champs dont l’on doit calculer la taille.

• L’instruction CodingSize est optionnelle, elle permet de définir le mode de codage de la taille du champ (DCB, ASCII, EBDIC).

• L’instruction Size correspond à la taille fixe ou maximale ou borne (ex : 1..25) du champ à découper.

• L’instruction Format permet de définir le format du champ qui peut prendre les valeurs suivantes :

o n pour numérique o a, an, as, ns, ans … pour les

caractères o b, ansb, anscb … pour le

binaire o z pour une piste magnétique o hhmmss, MMJJ, AAMM …

pour les heures ou dates. • L’instruction Coding permet de définir

le mode de codage du champ DCB, ASCII, EBDIC

• L’instruction Version est facultative, elle permet de spécifier pour quelle version est valide un découpage, par défaut le découpage est valide pour toutes les versions.

Field ident Name IDENT Description "Identifiant du

message" Type FIXE Size 4 Format ans Coding ASCII End Field bitmap Name BITMAP Description "bitmap" Type FIXE Size 16 Format ans Coding ASCII End Field 1 Name BITMAP_EXT Description "2eme bitmap" Type FIXE Size 16 Format ans Coding ASCII End Field 2 Name

FML_ISO_CHAMP2 Description "Numéro de

porteur" Version 1 Type LLVAR CodingSize DCB Size 19 Format n Coding DCB End



� Syntaxe du fichier décrivant les sous-champs Voici un extrait du fichier de découpage des sous-champs ISO8583:

Description des instructions pour le champ:

• L’instruction Field …End nous permet de délimiter la description du champ. • L’instruction Name correspond au nom de la variable de stockage du champ si

le champ n’est pas un buffer FML on le déclare dans un fichier *.h. • L’instruction Description correspond à la description du champ c’est une

chaîne de caractère. • L’instruction TSize donne la taille de codage pour le champ type. • L’instruction Lsize donne la taille de codage pour le champ longueur.

Description des instructions pour le sous-champs: • L’instruction UnderField End nous permet de délimiter la description du sous-

champ. • L’instruction Name correspond au nom de la variable de stockage du sous-

champ si le champ n’est pas un buffer FML on le déclare dans un fichier *.h. • L’instruction Description correspond à la description du sous-champ c’est une

chaîne de caractère. • L’instruction Version est facultative, elle permet de spécifier pour quelle

version est valide un découpage, par défaut le découpage est valide pour toutes les versions.

• L’instruction Type peut avoir les valeurs suivantes TLV, LTV pour les sous-champs dont l’on doit calculer la taille.

• L’instruction Size correspond aux tailles fixes possibles (4,6,8) ou à la taille fixe ou maximale ou borne (ex : 1..25) du sous-champ à découper.

• L’instruction Format permet de définir le format du champ qui peut prendre les valeurs suivantes :

o n pour numérique o a, an, as, ns, ans … pour les caractères o b, ansb, anscb … pour le binaire o z pour une piste magnétique

# Les sous éléments du champ 44 Field 44

Name FML_ISO_CHAMP44 Description "données compl. de réponse" TSize 2 LSize 2 UnderField AA

Name FML_ISO_CHAMP44_AA Description "Champs erroné" Type TLV Size 4,6,8 Format ans Coding EBCDIC

End End



o hhmmss, MMJJ, AAMM … pour les heures ou dates. o L’instruction Coding permet de définir le mode de codage du champ

DCB, ASCII, EBDIC de la valeur du sous-champ TLV ou LTV.

2. L’analyse syntaxique

� Principe général Description de la seconde étape : Analyse syntaxique du message.

A partir des fichiers d’analyse syntaxique de messages et à l’aide des outils Flex et Bison, on crée un programme C permettant l’analyse syntaxique d’un message entrant que ce soit une demande ou une réponse. Le programme analyse le message stocké dans un buffer FML, en appliquant à ce message les règles de bonne constitution (norme ISO8583) si l’une des règles n’est pas respectée alors le programme construit et renvoie une réponse KO, sinon le programme valide le message en le transmettant à l’application



� Syntaxe des fichiers de règles L’analyse syntaxique du message est l’application des diverses règles propres à chaque

champ. Elle se fait à partir de deux fichiers de règles, suivant le protocole utilisé ici ISO8583, le premier décrivant les règles d’ordre général communes à tout type de message ISO8583 le second permettant la description des règles particulières au type du message, suivant son identifiant et permettant la construction d’une réponse.

On définit ici la syntaxe des fichiers de règles permettant l’analyse syntaxique d’un

message, on met fin à une instruction avec « ;; » :

o Permet de spécifier une ou plusieurs conditions préalables à une instruction.

o Renvoie vrai si le champ Field est compris dans la liste des valeurs spécifiées (entiers, ou chaîne de caractères entre « ») et renvoie faux sinon.

o Associe une valeur ou un intervalle de valeur à un libellé plus

concrètement une valeur possible d’un champ à sa description.

o L’instruction Error permet de spécifier qu’une erreur dont le type est précisé dans le paramètre 1 a eu lieu, cette erreur concerne le champ spécifié dans le second paramètre, le paramètre 3 correspond au libellé de l’erreur. Le type de l’erreur peut prendre les valeurs suivantes ABS_FIELD, VALUE_FIELD, DO_NOT_PRESENT, ABS_KEY, FORMAT_FIELD…

o Permet de spécifier les versions pour lesquelles la règle est

valide ou non.

o Instructions booléennes « et » « ou » et « négation ».

o Instruction de comparaison et d’affectation.

o Instruction permettant d’ajouter un commentaire.

o Instruction permettant la création et l’appel de fonction, on spécifie le nom de la fonction et la liste des paramètres avec leur type primitif (C).

If (…) Then ElseIf(…)Then Else EndIf;;

Field in [ 1, 2, 3] ;;

value => "libellé" ;; deb-fin => "libellé" ;;

Error(VALUE_FIELD,3,"champs 3 type de compte affecté au crédit invalide");;

&&, ||, Not

# commentaire

!=, ==, <, >, =

Version 1,2 End ;; Not Version 1,2 End ;;

CallFunction name (param) ;; CreateFunction name (type param, …){…};;



On définit ici la syntaxe des fichiers de règles pour un message spécifique, ici aussi on met fin à une instruction avec « ;; » :

o Marque le début et fin de la description des règles pour le message dont le(s) identifiant(s) est(sont) spécifié(s).

o Instruction permettant de spécifier le libellé du type de message, cette instruction est liée à l’instruction précédente qui spécifie l’identifiant du message.

o Instruction permettant de spécifier les champs obligatoirement présents dans la bitmap pour ce type de message.

Instructions propres à la construction ou à l’analyse d’une réponse :

o Instruction permettant de séparer la partie construction d’une réponse au message de la partie analyse syntaxique du message.

o Ces deux instructions permettent de préciser lorsque

l’on utilise un champ dans l’analyse de la réponse s’il s’agit du champ de la question ou celui de la réponse. Par défaut c’est celui de l’identifiant du message précisé dans l’instruction Trame8583.

Trame8583 100,101 …

End ;;

Name "Demande d'autorisation","Répétition de demande d'autorisation";;

Obli_Field 2,3,4,7,11 ;;

ConstructReply{…} ;;

Answer{…} ;; Reply{…} ;;



5.3. Outils pour créer le compilateur

1. Flex et Bison Pour réaliser notre programme C, permettant le découpage, l’analyse et le traitement de

messages, nous allons utiliser les outils Flex et Bison. FLEX est un générateur d'analyseurs lexicaux, il utilise les expressions régulières pour

décrire la syntaxe des tokens ou unités lexicales. Les commandes FLEX créent un code source C lex.yy.c contenant la fonction yylex(). Cette fonction est appelée par l'analyseur syntaxique. Elle retourne une valeur entière qui est le code du token reconnu ou un code d'erreur.

BISON est un générateur d'analyseurs syntaxiques, il génère un autre programme en analysant la structure d'un fichier texte. Au lieu d'écrire le programme, l'utilisateur spécifie comment les choses doivent être reliées et, avec ces règles, un analyseur est construit dans le fichier y.tab.c pour analyser le fichier texte. L'analyseur est une fonction de type entier de nom yyparse(). Cette fonction peut être appelée du programme principal. L'analyseur syntaxique appelle l’analyseur lexical yylex().



5.4. Le simulateur Le simulateur va nous permettre d’envoyer des messages ISO8583 à l’application

(programmes C générés par Flex et Bison) et de voir le comportement de celle-ci suivant le type de messages.

Il nous faut donc deux fonctionnalités sur le simulateur, la première pour tester la partie serveur et la seconde pour la partie demandeur. Il faut de plus créer un simulateur simple et compatible avec tous les différents types de protocoles ISO8583.

1. Fonctionnement du simulateur

� Partie serveur : Le simulateur reçoit sur son entrée standard la (les) question(s) ISO8583 et le nom de

protocole à utiliser, il renvoie le message au programme serveur du protocole concerné, dans le cas où tout se passe bien le programme serveur découpe et analyse le(s) message(s) et le(s) renvoie(nt) sous forme FML au simulateur qui l’affiche. Le simulateur envoie avant le timeout la (les) réponse(s) à l’application serveur sous forme de buffer FML qui sera analysée par l’application serveur puis retournée sous forme de chaîne de caractère qui sera ensuite affichée par le simulateur.



Le simulateur reçoit sur son entrée standard la (les) question(s) ISO8583 et le nom de protocole à utiliser, il renvoie le(s) message(s) au programme serveur du protocole concerné, dans le cas où tout se passe bien le programme serveur découpe et analyse le(s) message(s) et le renvoie sous forme FML au simulateur qui l’affiche. Dans le cas où l’application serveur n’a pas reçut de réponse(s) avant le timeout ou en cas d’erreur lors de l’analyse de la question, l’application serveur construit la réponse(s) et la renvoie au simulateur qui l’affiche.

Par conséquent la fonctionnalité serveur du simulateur prend en entrée les données suivantes :

• Le nom du protocole utilisé (RCB ou autre…) • Question(s) sous forme de chaîne de caractères • Fichier contenant la (les) réponse(s) au format FML • Booléen indiquant si le simulateur doit faire un timeout.



� Partie demandeur : Le simulateur reçoit sur son entrée standard la (les) question(s) ISO8583 au format

lisible pour du FML et le nom de protocole à utiliser, il renvoie le(s) message(s) au programme demandeur du protocole concerné, dans le cas où tout se passe bien le programme serveur découpe et analyse le(s) message(s) et le renvoie sous forme de chaîne de caractère au simulateur qui l’affiche. Le simulateur envoie avant le timeout la (les) réponse(s) à l’application serveur sous forme de chaîne de caractère qui sera analysée par l’application serveur puis retournée sous forme de buffer FML qui sera ensuite affichée par le simulateur.



Le simulateur reçoit sur son entrée standard la (les) question(s) ISO8583 au format lisible pour du FML et le nom de protocole à utiliser, il renvoie le(s) message(s) au programme serveur du protocole concerné, dans le cas où tout se passe bien le programme serveur découpe et analyse le(s) message(s) et le renvoie sous forme de chaîne de caractère au simulateur qui l’affiche. Dans le cas où l’application serveur n’a pas reçu de réponse avant le timeout ou en cas d’erreur lors de l’analyse de la question, l’application serveur construit la réponse et la renvoie au simulateur qui l’affiche.

Par conséquent la fonctionnalité demandeur du simulateur prend en entrée les données suivantes :

o Le nom du protocole utilisé (RCB ou autre…) o Question(s) sous forme lisible FML o Fichier(s) contenant la (les) réponse(s) sous forme de chaîne de caractère o Booléen indiquant si le simulateur doit faire un timeout.

� Pour résumer Le simulateur prend en paramètres :

o Le nom du protocole utilisé (RCB ou autre…) o Une chaîne de caractères indiquant s'il est demandeur ou serveur. o Les fichiers contenant la (les) question(s) et la (les) réponse(s) au format FML ou au

format chaîne de caractère. o Un booléen indiquant si le simulateur doit faire un timeout.



6. ANALYSE TECHNIQUE

6.1. Organisation du développement

� Rappel

Le projet est développé sous un environnement Linux et l’on utilise les outils Flex et Bison de la librairie GNU.

En s’inspirant de la version des programmes RCB existants, on crée de nouveaux programmes générant les programmes RCB (ou autres protocoles) à partir de fichiers de règles.

� Planning du projet Une des premières étapes après la conception du document d’analyse fonctionnelle est la

rédaction du planning de développement, on évalue de cette façon le nombre de jours nécessaire pour le développement de chacune des versions du projet et des tests d’intégrations de celui-ci, comme ce projet n’est qu’un prototype, on n’envisage pas dans l’immédiat des tests de recettes.

Le planning de développement est fournit en annexe de ce document.

� Le cahier de tests Une autre étape est la rédaction du cahier de tests, on y définit précisément les tests qui

seront effectués à la fin du développement de l’application et les résultats que l’on en attend. Le cahier de test est fournit en annexe de ce document.



6.2. Le développement

1. L'arborescence de développement

On regroupe tout le projet dans le répertoire racine CompilerISO8583 qui contient lui-même trois répertoires :

• Le répertoire ISO8583 contient les répertoires des protocoles de transport répondant à la norme ISO8583 puis un répertoire de programmes communs à tous ces protocoles.

o Le répertoire RCB contient les règles de formatage d’un message RCB et les programmes générés par le compilateur à partir de ces fichiers de règles.

• Le répertoire Compiler contient les fichiers Flex et Bison de construction du compilateur. Ces fichiers du compilateur « parsent » les fichiers de règles et génèrent les programmes du protocole permettant l’analyse lexicale et syntaxique d’un message.

• Le répertoire Simulator contient les programmes du simulateur qui va nous permettre de tester les programmes générés par le compilateur.

Remarque :

• Le répertoire Simulator contient les sous-répertoires src, objet, include et test qui contiennent respectivement les fichiers *.c avec le makefile, les fichiers *.o, les fichiers *.h, les fichiers *.exe.

• Le répertoire Compiler contient un sous-répertoire pour le compilateur lexical et un autre sous-répertoire pour le compilateur syntaxique, il contient aussi un makefile et enfin dans chacun des sous-répertoires les fichiers de règles lexicales et grammaticales utilisées par Flex et Bison.



2. Les fichiers créés ou générés

� Fichiers de règles créés Voici la liste des fichiers de règles créés ou encore à créer pour générer les programmes

d’analyse lexical et syntaxique d’un message.



� Fichiers des compilateurs La liste de programmes des deux compilateurs Flex/Bison créés pour générer les

programmes d’analyse lexical et syntaxique d’un message.

� Fichiers communs Voici les fichiers qui sont à la fois utilisés par les compilateurs et par les programmes

générés.



� Le simulateur Ci-dessous la liste des fichiers à implémenter pour le simulateur.

� Fichiers et fonctions générés Et enfin voici la liste des fichiers générés et des principales fonctions qui permettent

l’analyse lexical et syntaxique d’une transaction bancaire.




Nadège GONORD Page 39 sur 68

7. CONCLUSION

7.1. Ce qui reste à faire Je ne suis actuellement pas encore arrivée au terme du développement de mon

application, mais je reste dans le calendrier de la mission. Je développe en ce moment la première version du compilateur syntaxique puis ensuite le simulateur, ce qui me permettra de mieux tester les deux compilateurs et de les améliorer. Il reste donc à rédiger les fichiers de règles manquants, à reprendre les compilateurs et le simulateur pour une seconde version plus performante, et enfin à réaliser les tests d’intégration.

7.2. Du point de vue de l’entreprise Du point de vue de STERIA, ce stage s’achève sur la réalisation d’un prototype qui

pourra être ou non retenu, suivant un budget et un temps de développement défini. Dans le cas où ce projet serait retenu, les clients pourront désormais paramétrer eux-mêmes le programme d’analyse de message. Malgré des fichiers de paramétrage différents, tous les clients auront une version commune des compilateurs ce qui éviterait la gestion de différentes versions d’un même code par client.

7.3. Du point de vue personnel Pour ma part, ce premier projet pendant mon stage a rempli deux objectifs. Il m’a

permis de mettre en pratique les connaissances acquises au cours de mon cursus au sein de l’Université de Marne-la-vallée, tout en acquérant une nouvelle expérience professionnelle dans une société de service. Il m’a ainsi été possible d’évaluer mes acquis en terme de méthodologie de conception d’un projet d’envergure.

D’autre part, j’ai eu l’avantage de pouvoir travailler sur ce prototype depuis son début,

et de faire au mieux pour que le travail que j’ai réalisé soit finalement intégré au logiciel STECARD. Ce projet m’a permis de disposer d’une grande autonomie dans mon travail et dans le déroulement des différentes étapes constituant ma mission, ce qui me permettra d’envisager avec un peu plus de sérénité les premières missions qui me seront confiées par la suite.



ANNEXE

1. ETUDE SUR LES META-LANGAGES

1.1. O CAML Ce langage axé mathématiques présente l’avantage d’être court et facile à comprendre,

de plus son intérêt réside dans le fait qu’il est basé à la fois sur le langage C et qu’il possède un style objet car il utilise des classes pour décrire les structures et leurs comportements.

Utiliser un partie de la syntaxe du langage O CAML pour définir les règles lexicale et syntaxique des messages semble intéressant.

Ce qui est intéressant :

• La possibilité de définir des variables et des fonctions : � let x = 3;; � let addition x = x+1;;

• La possibilité de charger des fichiers : � load « monfichier »

• L’utilisation des conditions if, then , else. • L’utilisation des opérateurs booléens

� not : pour la négation � &&: et séquentiel � ||: ou séquentiel

• les opérateurs classiques : + - * / < = <= > >= == != • la syntaxe des listes [] • les exceptions • la définition de chaîne de caractères « »

Ce qu’il manque :

• Préciser le type des variables que l’on définit : int, char, bit … • Les opérateurs sur les bits >> et << pour vérifier la présence d’un champs. • Une syntaxe pour les commentaires. • Une syntaxe pour associé une valeur à un message. • Pouvoir associé un message à une exception. • Une fonction d’extraction de chaîne. • Une notation préfixé pour les opérations. • Un identificateur différent pour la déclaration et l’affectation d’une variable.



1.2. LISP Le lisp possède une syntaxe simple qui possède un grand nombre de structures de données et

d’opérateurs prédéfinis. Ce qui est intéressant :

• La notation préfixée des opérations : + 2 3 • Les paramètres passés en argument lors de la définition d’une fonction : (defun FB-en-

euros (x) (/ x 40.3399)) • Les fonctions prédéfinies equal, list, first, length… • Les types de données existants int, float, string • Les prédicats >, <, >=, <= • Expressions logiques : and, or et not • Opérateurs d’itérations : dolist (qui parcours une liste), loop for n from 1 to 10 when • La macro return

Ce qu’il manque :

• Pouvoir spécifier le type de données d’une variable • Ajout du type de données llvar • Une différence entre les variables définis par l’utilisateur et les instructions

1.3. SML

SML est un langage de programmation fonctionnel. Les fonctions y sont les données de base privilégiées. Elles peuvent être passées comme arguments, retournées comme résultats et en-registrées dans des variables. Comme pour tout langage fonctionnel, le principal mécanisme de contrôle en SML est l’application de fonctions récursives. SML est très fortement typé. Chaque expression valide a un type, qui est automatiquement déterminé par le compilateur. Ce dernier effectue également toutes les vérifications de types de façon à éviter les erreurs de sémantique dynamiques dues à un mauvais typage. SML est un langage interactif. Chaque expression lue est analysée, compilée et exécutée, et la valeur de l’expression est retournée avec son type. SML est doté d’un typage polymorphe et implémente une notion de type abstrait. SML est muni d’un mécanisme d’exception, similaire à celui du langage Ada. Les implémentations connues de SML mettent en oeuvre un mécanisme de ramassage de miettes ce qui rend ce langage approprié à la manipulation d’entités de manière dynamique comme par exemple pour la construction de compilateurs.

Ce qui est intéressant :

• Les types de données existants bool, int, real, string • La syntaxe des liste [] • La notation infixé • La surcharge des opérateurs • Les références

Ce qu’il manque :

• La gestion de pointeurs pour les chaîne de caractères



1.4. NOTATION CHOISIE Les seules règles de l’un des langages décrit ne nous permet pas de définir les règles d’un

message, pour cette raison je propose la syntaxe suivante : Fonctions : Fonction Description Exemple

Let Définie une variable Let bool question ;; Let char(4) ident;;

Set Affecte une variable Set ident = « 0000 » ;;

If Else Endif Traduit une condition d’exécution If ( question ) Then Set ident = « 1234 »;; Else Set ident = « 4321 »;; Endif;;

Error Affiche un message d’erreur Error(« toto ») ;;

Extract Extrait de la chaîne passé en paramètre les caractères de la position donnée jusqu'à la taille données, il avance le pointeur vers la chaîne de la taille indiquée

Extract (message, 4, 16) ;;

ExtractINT Extrait de la chaîne passé en paramètre l’entier à la position donnée jusqu'à la taille données, il avance le pointeur vers la chaîne de la taille indiquée

ExtractINT (messag e, 4, 16) ;;

ExtractFLOAT Extrait de la chaîne passé en paramètre le décimal à la position donnée jusqu'à la taille données, il avance le pointeur vers la chaîne de la taille indiquée

ExtractFLOAT (message, 4, 16) ;;

ExtractLLVAR Extrait de la chaîne passé en paramètre les caractères de la position donnée jusqu'à la taille maximale données, il avance le pointeur vers la chaîne de la taille indiquée et renvoie la taille réelle de la sous-chaîne.

ExtractLLVAR (message, 4, 16) ;;

Print Affiche la valeur passé en paramètre Print ident ;;

in Vérifie qu’une variable correspond à une des valeurs données.

Ident in [ « 0100 », « 0110 » ]

=> Associe un texte à une valeur "0100" => "Demande d'autorisation"

[ ] Définit une liste [ « toto », « titi » ]

/* */ Syntaxe pour les commentaires /* commentaires */

IsDate Vérifie la syntaxe d’une date passé en paramètre au format voulu.

IsDate (madate,format_voulu) ;;

Date Renvoie la date courante au format voulu.

Date (format_voulu) ::



Règles : • Une variable définie commence par une minuscule et une instruction par une

majuscule. • ;; met fin a une instruction Types :

• bool -> booléens • int -> entier • float -> décimaux • char(taille) -> chaîne de caractères • llvar(max) -> chaîne de caractères de longueur variables

Les prédicat :

• == -> pour tester l’équivalence • != -> pour tester la différence • <=, <, >, >= -> pour tester la comparaison • Not -> pour la négation • <<, >> pour les opérations binaires



1.5. Exemple : une demande d’autorisation de retrait méta-langage

/* Cas d'une demande d'autorisation de retrait */ /* ou de construction d'une réponse à une telle dem ande */ Let bool question;; Let char* message;; Defun int present ( char* bitmap, int field ) { return bitmap&(1<<field); };; /* IDENTIFIANT */ Let char(4) ident;; /* Extraction de la sous-chaine dans la variable à la position

et la longueur donnée */ Set ident = Extract (message, 0, 4);; /* Valeurs du champs et significations pour une que stion */ If ( question ) Then ident in [ "0100" => "Demande d'autorisation" ,

"0101" => "Répétition de demande d'autorisation" ]; ; Else ident in [ "0110" => "Réponse de demande d'autoris ation"

];; Endif;; /* BITMAP */ Let char(16) bitmap;; /* Extraction de la sous-chaine dans la variable à la position

et la longueur donnée */ Set bitmap = Extract (message, 4, 16);; /* Règles de présence de champs du retrait */ If ( Not present(bitmap,2) || Not present(bitmap,3) || Not present(bitmap,4) || Not present(bitmap,7) || Not present(bitmap,11) || Not present(bitmap,12 ) || Not present(bitmap,13) || Not present(bitmap,14 ) )

Then error();; Endif;; If ( field_49 != "978" => "Euro" ) Then If ( Not present(bitmap,6) || Not present(bitmap,1 0) )

Then Error();; Endif;; Endif;; /* BITMAP_EXT */ Let char(16) bitmap_ext;; If ( present(bitmap,16) ) Then Set bitmap_ext = Extract (message, 0, 16);; Endif;;



/* CHAMP_2 */ Let char(16) field_2;; /* Champs obligatoire */ If ( Not present(bitmap,2) ) Then Error("Champs 2 absent");; Endif;; Set field_2 = ExtractLLVAR (message, 0, 16);; /* CHAMP_3 */ Let char(6) field_3;; /* Champs obligatoire */ If ( Not present(bitmap,3) ) Then Error("Champs 3 absent");; Endif;; Set field_3 = Extract (message, 0, 6);; /* Valeurs du champs description de la transaction et

significations */ Let int desc_transc;; Set desc_transc = ExtractINT (field_3, 0, 2);; If ( Not desc_transc in [ 00 => "Achat de biens ou services", 01 => "Retrait sur automate(DAB/GAB)", 10 => "Transaction financière sans délivrance

d'espèces (demande de virement, ...)", 11 => "Quasi-cash", 14 => "Capture de carte", 15 => "Autorisation à délivrer un certificat", 16 => "Réservé CB", 17 => "Retrait au guichet", 18-19 => "Réservé pour usage privé", 20 => "Crédit (retours)", 28 => "Retour Quasi-Cash", 30 => "Interrogation sur disponibilité de

fond", 36 => "Interrogation (duplicata)", 37 => "Restitution de carte", 80 => "Transaction d'alarme", 81 => "Autorisation de rechargement PME", 82-89 => "Réservé CB", 90-99 => "Réservé pour usage privé" ] )Then Error("champs 3 description de la transaction" );; Endif;; /* Valeurs du champs type de compte affecté au débi t et

significations */ Let int type_cpt_d;; Set type_cpt_d= ExtractINT (field_3, 0, 2);; If ( Not type_cpt_d in [ 00 => "Achat sans particul arité de

débit", 30 => "Achat à crédit. Cette valeur n'est

possible qu'en paiement", 33 => "Différé de recouvrement" ] )Then Error("champs 3 type de compte affecté au débit"); ; Endif;; /* Valeurs du champs type de compte affecté au créd it et

significations */ Let int type_cpt_c;;



Set type_cpt_c= ExtractINT (field_3, 0, 2);; If ( Not type_cpt_c == 00 => "Achat sans particular ité de

crédit" )Then Error("champs 3 type de compte affecté au crédit") ;; Endif;; /* CHAMP_4 */ Let int field_4;; /* Champs obligatoire */ If ( Not present(bitmap,4) ) Then Error("Champs 4 absent");; Endif;; Set field_4 = ExtractINT (message, 0, 12);; If ( Not present(bitmap,49) ) Then Error("Champs 4 présent absence du champs 49");; Endif;; /* CHAMP_6 */ Let int field_6;; If ( present(bitmap,6) ) Then Set field_6 = ExtractINT (message, 0, 12);; /* Définit la monnaie */ If ( Not present(bitmap,51) ) Then Error("Champs 6 présent absence du champs 51");; Endif;; Endif;; /* CHAMP_7 */ Let char(10) field_7;; If(question) Then /* Champs obligatoire */ If ( Not present(bitmap,7) ) Then Error("Champs 7 absent");; Endif;; Set field_7 = Extract (message, 0, 10);; If (IsDate(field_7,"MMJJhhmmss"))Then Error("Date champs 7 non valide");; Endif;; Else Set field_7 = Date("MMJJhhmmss");; Endif;; /* CHAMP_10 */ Let char(8) field_10;; Set field_10 = Extract (message, 0, 8);; /* On définit une variable contenant l'exposant */ Let int exp; Set exp = ExtractINT (field_10,0,1);; /* On définit une variable contenant le taux */ Let float taux;

Set taux= ExtractFLOAT (field_10,0,7);;



1.6. Exemple pour une demande d’autorisation de retrait en XML <?xml version='1.0' encoding='UTF-8'?>   <config_trc_desc_FIELD_RCB>  <Field Identifier="IDENT" >  <Syntactic type="FIXE" size="4" format="ASC II" />  <Rules> <Rule type="EQUALS" start="0" size="4"

field="IDENT">  <EQUALS value="0100">Demande

d'autorisation</EQUALS> <EQUALS value="0101">Répétition de demande

d'autorisation</EQUALS> <EQUALS value="0110">Réponse de de mande

d'autorisation</EQUALS>  <EQUALS value="0120">Avis de captu re de carte,

de restitution ou d'autorisation</EQUALS> <EQUALS value="0121">Répétiton d'a vis de

capture de carte, de restitution ou d'autorisation< /EQUALS> <EQUALS value="0130">Réponse d'avi s de capture

de carte, de restitution ou d'autorisation</EQUALS>  <EQUALS value="0300">Demande de ge stion de

fichier (pour les demandes de mise en opposition)</ EQUALS> <EQUALS value="0310">Réponse à dem ande de

gestion de fichier</EQUALS> <EQUALS value="0320">Avis de gesti on de fichier

(pour les avis de mise en opposition)</EQUALS> <EQUALS value="0330">Réponse à avis de gestion

de fichier</EQUALS> <EQUALS value="0340">Initialisatio n de réponse

à autorisation</EQUALS> <EQUALS value="0344">Initialisatio n de demande

d'autorisation</EQUALS>  <EQUALS value="0400">Demande de

redressement</EQUALS> <EQUALS value="0401">Répétition de demande de

redressement</EQUALS> <EQUALS value="0410">Réponse à dem ande de

redressement</EQUALS>



 <EQUALS value="0800">Demande de ge stion de

réseau</EQUALS> <EQUALS value="0801">Répétition de demande de

gestion de réseau</EQUALS> <EQUALS value="0810">Réponse à dem ande de

gestion de réseau</EQUALS>  <EQUALS value="0840">Notification

d’ouverture/fermeture de fichier par le système acq uéreur</EQUALS> <EQUALS value="0844">Notification

d'ouverture/fermeture de fichier par le système rem ettant</EQUALS> </Rule> </Rules> </Field>  <Field Identifier="BITMAP"> <Syntactic type="FIXE" size="16" format="ASCII" /> <Rules>  <Rule type="BITMAP" start="0" size="16" />  <Rule type="PRESENT" field="FIELD_33" /> </Rules> </Field>  <Field Identifier="BITMAP_EXT"> <Syntactic type="FIXE" size="16" format="AS CII" /> <Rules>  <Rule type="BITMAP_EXT" start="0" size="16">

</Rule> </Rules> </Field>  <Field Identifier="FIELD_2"> <Syntactic type="LLVAR" sizeMax="16" format="NUM" /> </Field>  <Field Identifier="FIELD_3"> <Syntactic type="FIXE" size="6" format="NUM" /> <Rules> <Rule type="EQUALS" start="0" size= "2"

field="FIELD_3">



 <EQUALS value="00">Achat de biens ou

services</EQUALS> <EQUALS value="01">Retrait sur

automate(DAB/GAB)</EQUALS> <EQUALS value="10">Transaction fin ancière sans

délivrance d'espèces (demande de virement, ...)</EQ UALS> <EQUALS value="11">Quasi-cash</EQU ALS> <EQUALS value="14 ">Capture de carte</EQUALS> <EQUALS value="15">Autorisation à délivrer un

certificat</EQUALS> <EQUALS value="16">Réservé CB</EQU ALS> <EQUALS value="17">Retra it au guichet</EQUALS> <EQUALS value="18-19">Réservé pour usage

privé</EQUALS> <EQUALS value="20">Crédit (retours)</EQUALS> <EQUALS value="28">Retour Quasi- Cash</EQUALS> <EQUALS value="30">Interrogation s ur

disponibilité de fond</EQUALS> <EQUALS value="36">Interrogation

(duplicata)</EQUALS> <EQUALS value="37">Restitution de

carte</EQUALS> <EQUALS value="80">Transaction

d'alarme</EQUALS> <EQUALS value="81">Autorisation de rechargement

PME</EQUALS> <EQUALS value="82-89">Réservé CB</EQUALS> <EQUALS value="90-99">Réservé pour usage

privé</EQUALS> </Rule> <Rule type="EQUALS" start="2" size="2"

field="FIELD_3">  <EQUALS value="00">Achat sans part icularité de

débit</EQUALS> <EQUALS value="30">Achat à crédit. Cette valeur

n'est possible qu'en paiement</EQUALS> <EQUALS value="33">Différé de

recouvrement</EQUALS> </Rule> <Rule type="EQUALS" start="4" size="2"

field="FIELD_3">  <EQUALS value="00">Achat sans part icularité de

crédit</EQUALS> </Rule> </Rules> </Field>  <Field Identifier="FIELD_4"> <Syntactic type="FIXE" size="12" format="NU M" /> <Rules> 



<Rule type="PRESENT" field="FIELD_49" /> </Rules> </Field>  <Field Identifier="FIELD_5"> <Syntactic type="FIXE" size="12" format="NU M" /> </Field>  <Field Identifier="FIELD_6"> <Syntactic type="FIXE" size="12" format="NU M" /> <Rules>  <Rule type="PRESENT" field="FIELD_51" /> </Rules> </Field>  <Field Identifier="FIELD_7"> <Syntactic type="FIXE" size="10"

format="DATE/MMJJhhmmss" /> </Field>  <Field Identifier="FIELD_8"> <Syntactic type="FIXE" size="8" format="NUM " /> </Field>  <Field Identifier="FIELD_9"> <Syntactic type="FIXE" size="8" format="NUM " /> </Field>  <Field Identifier="FIELD_10"> <Syntactic type="FIXE" size="8" format="NUM" /> <Rules> " ); props.addSpecialSequence( "<" , "<" ); props.addSpecialSequence( ">" , ">" ); props.addSpecialSequence( "ä" , "ä" , caseFlags); props.addSpecialSequence( "Ä" , "Ä" , caseFlags); props.addSpecialSequence( "ö" , "ö" , caseFlags); props.addSpecialSequence( "Ö" , "Ö" , caseFlags); props.addSpecialSequence( "ü" , "ü" , caseFlags); props.addSpecialSequence( "Ü" , "Ü" , caseFlags); props.addSpecialSequence( "ß" , "ß" ); props.addSpecialSequence( "<b>" , "" ); props.addSpecialSequence( "</b>" , "" ); props.addSpecialSequence( "<i>" , "" ); props.addSpecialSequence( "</i>" , "" ); props.addSpecialSequence( "<code>" , "" ); props.addSpecialSequence( "</code>" , "" );



// create the tokenizer Tokenizer tokenizer = new StandardTokenizer(props); FileInputStream stream = new FileInputStream(args[0]); InputStreamReader reader= new InputStreamReader(stream); Token token; int len; try { tokenizer.setSource( new ReaderSource(reader)); // tokenize the file and print basically // formatted context to stdout len = 0; while (tokenizer.hasMoreToken()) { token = tokenizer.nextToken(); switch (token.getType()) { case Token.NORMAL: System.out.print(tokenizer.current()) ; len += token.getLength(); break; case Token.SPECIAL_SEQUENCE: System.out.print((String)token.getCom panion()); break; case Token.BLOCK_COMMENT: if (len > 0) { System.out.println(); len = 0; } break; case Token.WHITESPACE: if (len > 75) { System.out.println(); len = 0; } else if (len > 0) { System.out.print(' '); len++; } break; } } finally { // never forget to release resources and references tokenizer.close(); reader.close(); stream.close(); } } } catch (Throwable throwable) { // catch and print all exceptions and errors throwable.printStackTrace(); } } // end of main } // end of class



3. Dans notre cas : Voici les fichiers que nous devons réaliser et ceux qui seront générés automatiquement :

JTopas est un compilateur un peu plus évoluée que le simple parseur XML SAX de Java

aussi il facilite par sa librairie l’analyse lexicale et syntaxique mais le manque de documentation sur JTopas reste un inconvénient pour son utilisation.



3. PLANNING

3.1. Planning de développement du projet



3.2. Diagramme de Gantt





4. CAHIER DE TESTS SUR RCB

4.1. Tests préliminaires







4.2. Tests approfondis



5. LEXIQUE

STECARD : ( STERIA CARD ) logiciel de gestion des cartes de paiement.

MMB : Monétique et messagerie bancaire.

GDT : Gestionnaire de terminaux, GDG Gestionnaire de GAB Permettent la gestion des distributeurs de billets, TPE, GAB, DAB.

TPE : Terminal de Paiement Electronique, GAB : Guichets Automatiques Bancaires DAB : Distributeurs Automatiques de Billets

C'est une machine qui permet de régler la transaction à l'aide d'une carte de paiement. On y insère la carte , puis on tape son code secret. Elle vérifie le code secret, vérifie si la carte est en liste noire, envoie une requête d'autorisation sur le réseau.

Host : Système central bancaire, SA : Serveur d’autorisation Décide du refus ou de l’acceptation d’une transaction bancaire.

RCB / RSB : Réseau Cartes Bancaires Réseau de services aux banques Le Groupement Cartes Bancaires CB est un GIE (Groupement d’intérêt économique) crée

en décembre 1984 suite à la signature du protocole d'accord sur l'interbancarité. Le Groupement a pour rôle de mettre en oeuvre, coordonner et promouvoir l'interbancarité des cartes bancaires en France. C'est un organisme de conseil et d'études chargé d'établir une coopération technique des banques offrant un système d'information, le SICB (Système d’Information Carte Bancaire), et un réseau de transport des autorisations, le RCB.

A partir de 2004, le Réseau des Cartes Bancaires (RCB) sera progressivement remplacé par le Réseau de Service aux Banques (RSB), afin de prendre en compte l'augmentation du trafic et la diversité des informations échangées.

Buffer FML ( File Mirro List ) : Un buffer FML est un buffer contenant des champs. Chaque champ possède une ou

plusieurs valeurs appelées occurrences. De plus, chaque champ possède un type (char, int, etc.).

Documents

Rapport stage 2005 - nade77.free.frnade77.free.fr/CV/CV_gonord_fichiers/Rapport_stage_2005.pdf · Par la suite, je propose une synthèse sur les différentes étapes qui ont constitué