rapport stage bisgowap.free.fr/fich/stageap2003.pdf · rapport de stage analyse programmeur ......

Ce document est disponible sur mon site : http://gowap.fr.fm/fich/StageAP2003.pdf

AURA Équipements

Rapport de stage

Analyse Programmeur 2002-2003

– — –

Olivier MOUTRET

Stage en entreprise AP 2002-2003 AURA Équipements Olivier MOUTRET

01/09/2003 23:16:00 /42

Préambule Le stage en entreprise, effectué du 8 juillet au 16 septembre 2003, est une période importante pour la validation de la formation. Il m’a permis de mettre en pratique des connaissances acquises au cours de l’année, d’entrevoir une mise en œuvre au travers de cas concrets et ainsi me permettre de rejoindre ce nouveau métier sereinement. Ce présent document est édité avec l’accord préalable de mon entreprise d’accueil.

Remerciement Je remercie Monsieur RUBELE de m’avoir accueilli au sein de son entreprise pour y effectuer mon stage, ainsi que l’ensemble de ces collaborateurs qui ont pleinement participé à m’orienter pour résoudre mes différentes difficultés.

Nomenclature Au cours de ce document, un bouton sera noté entre crochet ce qui donne [ Bouton ]. Vous trouverez aussi des notations en bas de page qui se réfèrent à un mot spécifique marqué d’un nombre en exposant comme ce mot « Courriel1 » qui est suivit d’un petit chiffre un. Vous rencontrerez aussi des résumés de partie dans des encadrés conditionnés par « ¤ ». Je vous souhaite une agréable lecture.


01/09/2003 23:16:00 /42

Sommaire 1 Présentation de l’entreprise ................................................................................................ 4

1.1 Activité dans le temps ................................................................................................ 5 1.2 Les produits................................................................................................................ 5

1.2.1 Technologie Easycom................................................................................................5 1.2.2 Launcher/400.............................................................................................................6 1.2.3 Implantation et concurrence........................................................................................6 1.2.4 Topologie des produits ...............................................................................................7

1.3 Intégrateurs et accords technologiques ...................................................................... 7 1.4 Poste et salariés .......................................................................................................... 8 1.5 Aide au développement .............................................................................................. 9

2 Le projet de stage ............................................................................................................... 9 2.1 Définition du projet .................................................................................................... 9 2.2 Planning prévisionnel des tâches.............................................................................. 10 2.3 Vocabulaire du projet............................................................................................... 11 2.4 Étude de l’existant .................................................................................................... 12

2.4.1 DDSBLD, ce qu’il fait .............................................................................................12 2.4.2 DDSBLD, l’interface ...............................................................................................13 2.4.3 DDSBLD, son évolution / son codage .......................................................................13

2.5 Étude des nouvelles idées......................................................................................... 13 2.6 Étude de quelques solutions ..................................................................................... 14

2.6.1 L’accès aux données de l’analyse..............................................................................14 2.6.2 Correspondance des données ....................................................................................16 2.6.3 Génération des données AS/400................................................................................18 2.6.4 Lecture d’un fichier membre.....................................................................................21 2.6.5 Écriture d’un fichier membre ....................................................................................22 2.6.6 Compilation d’un DDS.............................................................................................23 2.6.7 Arborescence du profil et liste d’information .............................................................24 2.6.8 Vocabulaire pour l’utilisateur ...................................................................................25 2.6.9 Travail hors connexion AS/400.................................................................................26

2.7 Résumé des solutions ............................................................................................... 26 2.7.1 Quelques difficultés techniques rencontrées...............................................................27 2.7.2 Technique du langage ..............................................................................................27 2.7.3 Interface graphique et scénario..................................................................................28

2.8 Bilan de projet .......................................................................................................... 30 2.8.1 Planning réel ...........................................................................................................30 2.8.2 Encodage ................................................................................................................31 2.8.3 Raisonnement sur l’évolution ...................................................................................31

3 Conclusion........................................................................................................................ 31 4 Annexes ............................................................................................................................ 32

4.1 Écran du constructeur actuel (DDSBLD)................................................................. 32 4.2 Type de rubrique en WinDev 7.x............................................................................. 35 4.3 Type AS/400 (en DDS)............................................................................................ 35 4.4 Spécification de la carte A : DDS pour PF et LF ..................................................... 36 4.5 Correspondance de Type WinDev vers Type AS/400 ............................................. 36 4.6 Écran du projet ......................................................................................................... 37 4.7 Structure des Mémos AS/400 avec explication........................................................ 40 4.8 Méthode 1/2 en WinDev.......................................................................................... 41


01/09/2003 23:16:00 /42

1 Présentation de l’entreprise

« AURA Équipements » est une entreprise éditrice de middleware 1 de communication PC2/AS intégrés dans de nombreux outils de développement. Elle est indépendante d’IBM, ce qui lui vaut le titre angliciste d’ISV, sigle de « Independent Software Vendor », terme que nous retrouvons dans la documentation d’IBM signifiant « Éditeur de logiciels indépendant ». « AURA Équipements » a son siége social dans la zone d’activité de Courtabœuf, zone dépendant des villes « Les Ulis » et « Villebon sur Yvette », dans la grande couronne au Sud-ouest de Paris. Elle est située à proximité de l’autoroute A10 (3 minutes d’une sortie), desservie par RER à Orsay ainsi que par les bus de l’Essonne. Elle est dirigée par Fabienne et Sylvain RUBELE, respectivement PDG et Directeur Technique. Ses coordonnées sont les suivantes :

AURA Équipements BP 519, 10, avenue du Québec

ZA de Courtabœuf 91946 Les Ulis Cedex

Téléphone : 01 69 07 01 45

Fax : 01 64 46 29 06 Site : http://www.easycom-aura.com

1 Logiciel intermédiaire effectuant un travail d’interfaçage entre des outils et/ou systèmes disparates. 2 PC pour les ordinateurs PC (Personal Computer) et AS pour désigner AS/400 et iSeries.


01/09/2003 23:16:00 /42

Dans cette partie, je vais vous présenter les activités de l’entreprise par son histoire, ses interactions avec quelques sociétés ; puis, je finirai cette présentation, en énonçant le fonctionnement général interne.

1.1 Activité dans le temps Depuis sa création en 1986, AURA Équipements se consacre au développement d'outils systèmes destinés aux concepteurs d'applications. En 1993, AURA Équipements installait la première version de la Technologie Easycom, middleware Client/Serveur. Les technologies de développement d'applications web sont maintenant intégrées à Easycom, permettant d’en faire une passerelle universelle pour les outils de développement et le monde de l'iSeries. En 1996, LAUNCHER/400 était développé pour permettre aux développeurs AS/400 d'utiliser les ressources de Windows, depuis les environnements de développement natifs de l'OS/400.

¤ AURA Équipements (1986) est éditeur de logiciels systèmes, avec pour spécialité la plate- forme iSeries (AS/400) d’IBM.

1.2 Les produits Les produits phares de l’entreprise sont « Easycom » et « Launcher/400 » que je vais vous présenter succinctement maintenant.

1.2.1 Technologie Easycom Easycom est un middleware Client/Serveur qui permet d’accéder aux données et aux programmes de l’iSeries (AS/400), en mode natif3, depuis des applications sur des postes clients et serveurs web sous Windows, Linux ou OS/400, avec les meilleures performances, et en respectant des règles de sécurité.

Ces particularités sont les suivantes :

o Installation légère, facile (une partie sur le serveur et une sur le poste client),

o Faible encombrement,

o Faible consommation de ressource,

o Interfaces de programmation très complètes et faciles à maîtriser,

o Très haute performance d'accès aux données et aux programmes,

o Respecte les règles de sécurités de l'OS/400, L’installation nécessite un AS/400, avec un OS V3R2 minimum, interconnecté aux PC en TCP/IP (ou APPC4) ; la partie serveur fonctionne sans effectuer aucune écriture de code ou compilation.

3 Accède aux données comme le ferait un programme exécuté sur l’AS/400. 4 L’APPC est une ancienne interconnexion qui n’est plus vraiment utilisée aujourd’hui.


01/09/2003 23:16:00 /42

Ses caractéristiques sont fort nombreuses : la principale est le « lancement de commandes AS/400 avec retour de valeurs » que j’ai beaucoup utilisé.

¤ Easycom est un outil client/serveur permettant l’accès aux programmes et aux données de l’iSeries (AS/400) à partir d’une application PC.

1.2.2 Launcher/400 Laucher/400 est un outil de communication qui permet à partir d’une application AS/400 de bénéficier des fonctions de gestion de documents, d’éditions, d’archivage offert par les outils Windows.

L’iSeries (AS/400) est maître et le PC est utilisé comme serveur de traitement, d’impression… Laucher permet aussi d’atteindre le shell Windows ainsi que, par automation, les applications comme Microsoft Office, Exchange, Lotus Notes… Avec ces API 5 de remplacement, il permet la migration des applications utilisant Office Vision/400 de façon transparente. Un exemple d’utilisation courante est la génération de documents fusionnés utilisant les données de l’iSeries (AS/400).

¤ Launcher/400 permet à l’iSeries (AS/400) de piloter Windows.

1.2.3 Implantation et concurrence Easycom est un produit mondial ; il est vendu directement aux clients finaux ainsi que par l’intermédiaire des distributeurs ; il se retrouve dans de nombreux logiciels qui l’ intègrent. Sa concurrence est limitée aux États-Unis d’Amérique ; il n’y a plus de réelle concurrence en Europe pour ce produit. Launcher/400 connaît la même diffusion. Cependant, sa concurrence est bien plus importante, dont voici quelque exemple européen :

o DTM est un produit Belge pour AS/400, proposant l’importation des documents Office Vision. Les documents convertis sont dans un format propriétaire, comme l’est Office Vision.

o Quick Office, une solution de Traders6, est un produit complémentaire de la gamme QUICK-SOFTWARE-LINE ; il permet l’exportation des documents vers Word, tous en se restreignant aux possibilités d’Office Vision.

¤ La concurrence sur Easycom est très faible en Europe ; pour

Launcher/400, elle est accrue depuis la version 5 de l’iSeries, qui ne supporte plus le produit Office Vision.

5 Une API est un programme soit système, soit de référence, équivalent, dans l’idée, à une DLL de Windows. 6 Société du groupe QSL : http://www.quick-software-line.com


01/09/2003 23:16:00 /42

1.2.4 Topologie des produits Voici un schéma qui résume les interactions permises grâce à ces deux outils.

1.3 Intégrateurs et accords technologiques Les intégrateurs ont trouvé chez AURA Équipements et dans ses solutions, la technologie et les moyens techniques et humains pour mieux unir les mondes AS/400 et micros, sous Windows ou Linux. Avec Easycom, les éditeurs de logiciels sous Windows ont pu approcher le marché de l'AS/400, très rapidement, et sans effort financier important. Les éditeurs de logiciels AS/400 ont pu enrichir leurs applications en améliorant la qualité des documents produits, et l'ergonomie des applications grâce à LAUNCHER/400 et EASYCOM. Les accroissements constants des accords techniques et commerciaux, auprès d’éditeurs d’AGL7, d’outils de développement Internet et d’applications verticales8, permettent à AURA Équipements de voir sa technologie intégrée dans des solutions présentes dans le monde entier. Depuis 1993, le produit MAGIC/400 de « Magic Software Enterprises » utilise la Technologie Easycom. IBM (Rochester) et « Magic Software Enterprises » ont annoncé en avril 1996 leur accord qui relie Magic/400 (via EASYCOM) à l'AS/400 et ont signé un accord de partenariat mondial dans le cadre du programme « Partners of Development ». C’est en 1998 qu’est signé l’accord de distribution international pour Easycom For WinDev de Pc Soft. Ce partenariat se concrétise par une complète intégration d'Easycom dans l’outil

7 Atelier Génie Logiciel ; il intègre des outils permettant le développement de l’analyse au déploiement. 8 Outil qui tend à générer de façon presque transparente des programmes en partant de l’analyse.


01/09/2003 23:16:00 /42

de développement WinDev. Ces accords techniques se poursuivent avec l’intégration d’Easycom dans l’offre WebDev. L'AGL PGU/400 Visual Wizard de l’éditeur allemand « ABATEQ », a choisi la Technologie Easycom pour répondre aux besoins de développement web et Client/Serveur. ML4 de « ML Software » est un environnement de développement d'applications Client/Serveur, et spécialisé dans la modernisation des applications interactives de l'AS/400. Easycom lui apporte la rapidité de traitement, et la garantie de la cohabitation des nouvelles applications avec l'existant. Sur le marché de l'Amérique du nord, la société « MIS Systems » (Nashville TN) distribue Easycom, et contribue à son intégration dans des progiciels applicatifs. LAUNCHER/400 est aussi un outil largement intégré dans des applications verticales, pour aider à la production de documents Word ou Excel, depuis programmes natifs AS/400.

¤ AURA Équipements offre la technologie permettant d’unir les mondes AS/400 et Micros, sous Windows ou Linux.

1.4 Poste et salariés J’ai résumé l’essentiel de la structure d’Aura Équipements à travers la schématisation ci-dessous.

Secrétariat Gestion facture

Distribution d’appel Liaison commerciale

��

Communication ��

Recherche ��

Aide au développement Stagiaire ��

Réception

Département Technique

Support produit Windev ��

Développement ��


01/09/2003 23:16:00 /42

1.5 Aide au développement Lorsque j’ai rejoint le poste d’aide au développement, Aura Équipements intégrait déjà un stagiaire de formation BTS d’informatique de gestion par alternance, qui terminait sa première année. L’aide au développement permet l’accueil, en général d’un stagiaire ; l’intégration d’un second stagiaire est possible mais peu courrant. Par la nature de mon projet, mon travail s’est étendu sur les deux pôles techniques qui sont l’interfaçage WinDev et le développement autour d’un produit. Les outils à ma disposition sont les suivantes :

o Microsoft Office : utilisation de Word pour les dossiers des projets, d’Excel pour les tableaux de données et d’informations.

o Internet : me permet d’obtenir de l’information sur des problèmes de développement sous WinDev via l’accès au forum. L’entreprise est reliée au réseau mondial via une connexion ADSL Professionnel.

o WinDev 7.5 : c’est l’outil de développement de programme dans lequel je code mon projet et sur lequel le projet s’applique. Cet AGL est un produit de Pc Soft.

o AS/400 V4R4M0 et V5R2M0 : ces deux AS/400, respectivement en production et en test, me permettent de valider mes conceptions ; il est à noter quelques évolutions dans cette dernière version que je n’exploiterai pas, excepté le nouveau format binaire long sur 8 octets.

o Un PC sous Windows 2000 relié en réseau Intranet TCP/IP.

o Et surtout, la connaissance des collègues qui n’est pas négligeable.

¤ Mon projet me permettra de collaborer avec les services « Interfacage WinDev » et « Développement ».

2 Le projet de stage

2.1 Définition du projet Le projet consiste à concevoir un outil d’assistance à la programmation permettant de générer, à partir d’une analyse WinDev, les fichiers de données sur l’AS/400. Il prendra en charge, dans sa création, les différentes structures DDS 9 , les fichiers physiques et logiques, les contraintes10 référentielles, les transferts de données ainsi que les journalisations 11. L’outil est destiné plus particulièrement aux non initiés AS/400. Il devra être simple d’utilisation et permettre une prise en charge complète de la migration des fichiers. Pour les programmeurs plus avertis, l’outil permet un paramétrage rigoureux, dans les caractéristiques, globales ou unitaires, des différents types de correspondances aux rubriques WinDev/AS.

9 Le DDS est une Déclaration de Structure de Données pour l’iSeries (AS/400). 10 Règles définissant la cohérence des données à l’intérieur des fichiers. 11 Historique des modifications des données d’un fichier.


01/09/2003 23:16:00 /42

L’outil sera développé sous WinDev complété par le module « Easycom For WinDev » permettant l’accès natif à l’AS/400. Un précédent projet fonctionnel nommé DDSBLD pour « DDS Builder » d’origine WinDev 5.x, et ayant subit de nombreuses évolutions, par différents développeurs, apportera une aide précieuse. Ce projet utilise des appels directs à des entrées de la DLL Easycom qui ne doivent plus être utilisé.

• Additif émis pendant la phase d’analyse : Ce nouveau constructeur permettra la génération de données ainsi qu’une construction automatique dans un déploiement du produit ; c'est-à-dire que la partie interactive du programme pourra fonctionner sans être connectée à un AS/400. La construction sera préparée, emportée puis exécutée sur un autre ordinateur.

2.2 Planning prévisionnel des tâches Dans un premier temps, il m’a été proposé de prendre connaissance du produit Easycom par sa documentation : « Guide technique » et « Manuel de développement sur Easycom For WinDev ». J’ai profité de cette lecture initiatique pour y noter mes difficultés de compréhension et les erreurs potentielles, ce qui a permit de faire évoluer cette documentation. J'en ai aussi profité pour générer les exemples donnés afin de les comprendre et de les valider (les erreurs rencontrées ont été mises en correction). Pendant la deuxième semaine, le projet m’a été proposé. Après avoir étudié le produit existant et compris l’énoncé, j’ai planifié mon travail comme suit :

lun 28/07/03 lun 18/08/03 lun 08/09/03mar 08/07/03 mar 29/07/03 mar 19/08/03 mar 09/09/03mer 09/07/03 mer 30/07/03 mer 20/08/03 mer 10/09/03jeu 10/07/03 jeu 31/07/03 Bilan CCI jeu 21/08/03 jeu 11/09/03ven 11/07/03 ven 01/08/03 WD7.5 ven 22/08/03 ven 12/09/03

lun 14/07/03 lun 04/08/03 lun 25/08/03 lun 15/09/03mar 15/07/03 mar 05/08/03 mar 26/08/03 mar 16/09/03mer 16/07/03 mer 06/08/03 mer 27/08/03jeu 17/07/03 jeu 07/08/03 jeu 28/08/03ven 18/07/03 ven 08/08/03 ven 29/08/03

lun 21/07/03 lun 11/08/03 lun 01/09/03mar 22/07/03 mar 12/08/03 mar 02/09/03mer 23/07/03 mer 13/08/03 mer 03/09/03jeu 24/07/03 jeu 14/08/03 jeu 04/09/03ven 25/07/03 ven 15/08/03 ven 05/09/03

Codagede la

solution+ Test

Codagede la

solution+ Test

+ Recettage

Codage+ Test

+ RecettageDocumentsur Code

Codage+ Test


documentde prog

Etudedoc.

Produiteasycom

Etude doc.Produit

easycom+ Existant

EtudeexistantPrise en

main WD7.5

ExistantWD7.5

Solutiontechnique

Codage WD

Interfacegraphique

etScénario

Ce planning prévisionnel sera complété par un planning réel au paragraphe 2.8.1 en page 30. Ainsi, je prévois dans les grandes étapes :

o Terminer la lecture des manuels,

o Prise en main de WinDev 7.5

o Étude du précédent constructeur DDS,

o Étude WinDev 7.5 et AS/400 : recherche des différents type de données,

o Recherche et test de solution technique (développement de test de faisabilité),


01/09/2003 23:16:00 /42

o Recherche d’une ergonomie à travers les écrans utilisateurs (interface graphique),

o Développement de la solution retenue,

o Test de différents modules,

o Conception d’une documentation et/ou aide en ligne,

o Conception d’une documentation de développement (en parallèle du codage). Au vu du délai imparti et de la charge de travail, la rédaction de la documentation ne sera sans doute pas réalisée. Cependant je documente beaucoup les sources, ce qui permet de trouver l’information. Partant du principe qu’un programme source doit toujours être clair et documenté, j'ai développé en faisant en sorte que la documentation soit facilement récupérable en listant les sources du produit.

¤ Le planning prévisionnel semble déjà très chargé ; il intègre dix phases.

2.3 Vocabulaire du projet Un projet WinDev regroupe un ensemble de déclarations utilisées par le programme en conception et en exécution. Ces déclarations sont diverses, comme les analyses de données à travers un MCD12 et MLD13, les requêtes, les fenêtres, les codes sources, etc. Une analyse WinDev est un fichier spécifique (*.WDD) qui regroupe l’ensemble des définitions des structures de données d’un projet. Une seule analyse peut être active à la fois dans un projet. Elle contient la liste des fichiers avec leurs rubriques et leurs contraintes. Chaque fichier est désigné par un nom logique utilisé dans le programme. Un fichier logique est associé à un physique qui est par défaut de type « HyperFile ». — L’HyperFile est un fichier indexé de format spécifique à WinDev. — Un fichier a des propriétés spécifiques :

o Emplacement de ses données : le fichier de données (Base de données) peut être de différents types. La seule différence utile pour le projet est de savoir s’il est « Natif14 AS/400 » ou non. Dans ce premier cas, le fichier existe sur l’AS/400, et il possède peut-être déjà des données et des contraintes. Il est même peut être déjà utilisé par d’autres programmes !

o Rubrique : c’est un « champ » de données d’un enregistrement. Une rubrique est désignée par un nom et un type de données. Sous WinDev, il existe 28 types de rubriques (format de données) différentes contre 9 pour l’AS/400.

o Clé : une clé est une rubrique permettant d’accéder rapidement à des données. Elle peut être de type « unique », « avec doublons », ou « composée ». La clé composée concatène 15 des rubriques existantes.

o Jounalisation : c’est le fait d’historiser l’ensemble des modifications apportées aux données d’un fichier. Le journal peut permettre de valider ou d’annuler des modifications, et aussi d’offrir une sauvegarde plus rapide des données quotidiennes. Les journalisations de WinDev et AS/400 sont différentes. Actuellement, WinDev ne

12 Méthodologie MERISE : Modèle Conceptuel des Données ; structures et échanges d'information. 13 Méthodologie MERISE : Méthode Logique de Données ; structures de données (fichiers, rubriques, ...) 14 Le fichier logique désigne des données hébergées sur l’AS/400. 15 Regroupe à la suite sous un format de taille fixe.


01/09/2003 23:16:00 /42

permet pas de gérer un journal sur un fichier autre que HyperFile. La gestion d’une journalisation sur l’AS/400 nécessite donc de bonnes connaissances de l’AS/400. C’est pourquoi, cette fonctionnalité ne sera traitée qu’en fin de projet.

Une contrainte (règles de gestion) représente l’interaction à appliquer sur des données liées (clé ou référence) lors d’un ajout, d’une suppression ou d’une modification.

¤ Une analyse regroupe des fichiers logiques et leurs contraintes. Les

rubriques et les clés définissent la structure d’un fichier. Le fichier journal historise les modifications des données d’un fichier.

2.4 Étude de l’existant

2.4.1 DDSBLD, ce qu’il fait Le précédent « constructeur DDS » permettait de créer et de compiler les DDS sur l’AS/400 spécifié dans la configuration de l’environnement d’Easycom. L’utilisateur peut sélectionner l’analyse de son choix, ainsi que les fichiers à traiter. Le paramétrage de l’application est global, ce qui est fort simple, mais aussi très limité. L’ensemble du programme est plus particulièrement orienté vers des utilisateurs ayant déjà quelques compétences AS/400. Le transfert de données complète fort bien ce programme et offre, avec simplicité, une migration entière d’une base de données. La création de la source DDS est effectuée sur l’AS/400 dans une bibliothèque et fichier spécifié ; le nom du membre est créé avec les dix premiers caractères du nom du fichier de l’analyse WinDev, ce qui crée rapidement des conflits. Cependant, l’écrasement d’un fichier source n’est possible qu’après acceptation de l’utilisateur. Si le fichier WinDev utilise un mémo, un DDS source supplémentaire sera créé ; son nom utilisera les huit premiers caractères du membre source suivi des deux underscore « _ ». Vous retrouverez la structure du mémo dans l’annexe « 4.7 Structure des Mémos AS/400 avec explication » en page 40. Si le fichier contient plusieurs mémos, une seule et unique structure de mémo n’est nécessaire. — Nous pouvons remarquer que cette structure pourrait être utilisée pour tous les fichiers d’un projet ; ce qui n’est pas fait ici afin de conserver la structure WinDev. — La création (compilation) du fichier de données n’est possible que si la création du source DDS est effectuée ; elle est générée avec le nom du source dans la bibliothèque spécifiée par l’utilisateur. La création des contraintes est effectuée sans test d’existence (déjà présent) ou d’échec (lors de la création). Cette particularité nécessite davantage de compétence AS/400 et n’est pas activée par défaut. L’activation des contraintes est globale ; c'est-à-dire, soit aucune, soit toutes les contraintes sont créées. De même que pour les contraintes, l’activation du transfert des données est globale. Si l’utilisateur désire utiliser des options unitaires, il sélectionnera un seul fichier et appuiera sur [ Exécuter ].

¤ Ce programme simple ne permet qu’une configuration globale.


01/09/2003 23:16:00 /42

2.4.2 DDSBLD, l’interface Vous trouverez dans l’annexe « 4.1 Écran du constructeur actuel » en page 32, les cinq écrans commentés qui contiennent cette première version.

¤ L’interface graphique utilise la terminologie de l’AS/400, ce qui peut troubler les utilisateurs WinDev.

2.4.3 DDSBLD, son évolution / son codage Cette précédente version provient de la version de WinDev 5.x. La migration en version 7.5 génère un grand nombre de problèmes dans le code (syntaxe et valeur incorrects). Le programme utilise directement les objets graphiques pour mémoriser les données et y fait référence directement. Il n’y a pratiquement aucune informa tion dans le code source, ce qui le rend très difficile à lire. En plus, la plupart des variables sont globales, avec des noms peu explicites, et utilisées de façon temporaire un peu partout. Pour accéder aux informations à traiter, le programme charge l’analyse sélectionnée ; WinDev ne permet qu’une et une seule analyse ouverte à la fois, ce qui ferme automatiquement les fichiers précédemment ouverts et détruit leurs descriptions. Il est donc impossible que le programme utilise un fichier de travail pour y stocker des données. Il utilise à plusieurs reprises l’accès à l’ancienne DLL d’Easycom qui n’est plus d’actualité ; ces fonctionnalités sont maintenant intégrées (en partie16) aux fonctionnalités de WinDev.

¤ L’évolution progressive du constructeur DDS le rend aujourd’hui difficilement maintenable. Proposer une nouvelle mouture comme projet de stage est une très bonne idée.

2.5 Étude des nouvelles idées Afin de proposer un outil d’assistance à l’utilisateur WinDev, je dois réfléchir sur :

o Vocabulaire , orienté utilisateur WinDev et respectant l’environnement AS/400,

o Une assistance de saisie ; par exemple, un explorateur Lib, fichier, membre,

o Un générateur de nom de membres, DB ; méthode 1/2 et tronquer au 10ième caractère,

o Une configuration d’options globales,

o Une sélection d’option unitaire (par fichier, par rubrique, par contrainte),

o Un affichage des traitements (Aperçu DDS, Aperçu membre actuel),

o Une génération d’un script avant traitement,

o L’exécution du script de traitement.

¤ Les nouvelles propriétés sont liées en partie à la configuration unitaire, de chaque élément et opération, des données ainsi qu’à une utilisation orientée vers les utilisateurs WinDev novices de l’AS/400.

16 Seulement les fonctionnalités relatives à WinDev 7.x, ce qui élimine donc certaines fonctions.


01/09/2003 23:16:00 /42

2.6 Étude de quelques solutions Dans ce rapport, je ne peux envisager d’énoncer explicitement l’ensemble du travail effectué sur ce projet. Je vais donc vous énoncer les parties principales en me restreignant aux explications simples, agrémentées de schémas.

2.6.1 L’accès aux données de l’analyse La version actuelle du « constructeur DDS » charge l’analyse à traiter, ce qui ferme automatiquement les accès aux fichiers précédemment utilisés. Il est donc impossible d’utiliser une analyse liée au programme dans cette condition. De ce fait, j’ai recherché une méthode pour obtenir les informations d’une analyse d’une façon externe. Cette recherche m’a permis, entre autre, de me familiariser et d’évoluer dans l’environnement de WinDev 7.5 ; cela m’a aussi apporté un grand nombre de problèmes directement dus à des erreurs du langage. Avec beaucoup de difficulté, j’ai recherché des méthodes indirectes pour atteindre les données convoitées. J’en ai profité pour joindre la plupart des erreurs au service technique de Pc Soft (éditeur de WinDev).

Programme

Analyse à

traiter

Analyse Projet

Programme Analyse

à traiter

Chargement analyse Analyse externe

BDD

Dans la méthode actuelle, pour atteindre les structures, il suffit de charger l’analyse avec la commande WinDev HOuvreAnalyse. Ainsi, les listes des contraintes et des fichiers sont chargées en mémoire et peuvent être directement atteintes en utilisant leurs noms. Pour la nouvelle méthode, nous devons effectuer plusieurs traitements pour obtenir un résultat équivalent. Dans un premier temps, obtenir la liste des fichiers et des contraintes d’une analyse, respectivement avec les commandes HListeFichier et HListeLiaison ; puis dans un second temps, obtenir la liste des rubriques avec la commande HListeRubrique . Avec la commande HListeClé, je récupère l’ensemble des clés du fichier. Pour accéder à la structure et aux propriétés d’un fichier, nous devons effectuer une déclaration externe 17. Voici un exemple sur un fichier logique nommé « FichierExemple » ayant une rubrique « IdEx » qui affiche dans une fenêtre de trace quelques informations :

17 Procédé permettant d’accéder à un fichier qui n’existe pas dans l’analyse courante.


01/09/2003 23:16:00 /42

LOCAL Rt est un booléen // Retour de déclaration EXTERNE FichExterne // Nom d’alias du fichier Rt = HDéclare("FichierExemple", FichierAnalyse,"","FichExterne") SI Rt ALORS Trace("Nom du fichier : "+TAB+FichExterne..Nom) Trace("Nom55 du fichier : "+TAB+FichExterne..Nom55) Trace("Liste des rubriques du fichier : "+TAB+HListeRubrique(FichExterne)) Trace("Nom de la rubrique : "+TAB+{"FichExterne.IdEx"}..Nom) Trace("InfosEtendues de la rubrique : "+TAB+{"FichExterne.IdEx"}..InfosEtendues) HAnnuleDéclaration("FichExterne") FIN Cependant, cela ne permet pas d’accéder directement à toutes les données, car quelques problèmes WinDev viennent corser la solution. Ainsi, l’utilisation de certaines propriétés génèrent des comportements inattendus. On obtient un retour de valeur incorrecte, comme avec la propriété « Abréviation » sur fichier externe, ou alors un plantage, comme avec les propriétés « Libellé » et « Note » aussi bien pour le fichier externe que pour ses rubriques. Ce qui affiche dans ce dernier cas, cette splendide fenêtre très explicite :

J’ai retourné ces erreurs à l’éditeur de WinDev (Pc Soft) qui a identifié leurs origines ; une correction est donc envisagée dans une prochaine version. Dans l’immédiat, j’ai trouvé des solutions alternatives pour récupérer quelques données ; mais pour les autres, je propose de déclarer des fonctions qui retourneront des valeurs arbitraires en attendant les corrections. Une solution pour récupérer le libellé d’un fichier externe est de le rechercher dans la liste des fichiers de l’analyse associée. Cette liste contient les informations sur les libellés et les abréviations. Cependant, le fichier externe ne contient aucune propriété permettant de savoir de quelle analyse il provient ; je devrais donc mémoriser cette information au préalable. J’ai effectué plusieurs tests, afin de vérifier la cohérence des données obtenues ; il en découle que les informations que je n’ai pas réussi à obtenir, même d’une façon alternative, ne sont pas non plus accessibles par un chargement de l’analyse.

¤ L’accès à une analyse externe engendre un ensemble de problèmes qui n’étaient pas prévisibles ; les solutions alternatives permettent d’obtenir toutes les informations possibles.


01/09/2003 23:16:00 /42

2.6.2 Correspondance des données WinDev dispose de 28 types de rubriques différentes que vous retrouvez dans l’annexe « 4.2 Type de rubrique en WinDev 7.x » en page 35. Voici une liste résumant les différents formats :

IdAuto4/8, Texte, Entier 1/2/4/8, EntierNonSigné1/2/4/8, Réel4/8, RéelTurbo, NumEnr, Date6/8, Heure, DateHeure, Durée, Mémo Texte/Binaire/Binaire4, Monétaire, Image, Binaire, Caractère, Booléen.

Les cinq formats soulignés ne semblent plus être utilisés dans l’analyse ; ils ne sont pas non plus documentés dans l’aide. J’ai écris au service technique pour en savoir plus, mais aucune réponse cohérente ne m’a été retournée (le support répond : voir l’aide.). L’AS/400, quant à lui, dispose de 9 types de données, inscrit dans la documentation de la version 4 et 5, que vous retrouverez dans l’annexe « 4.3 Type AS/400 (en DDS) » en page 35, qui sont les suivants :

Alphanumérique, binaire, décimal condensé, décimal étendu, date, heure, virgule flottante, horodatage, hexadécimal.

Sur l’AS/400, ces différents formats sont codés par une lettre, qui sont respectivement les suivantes : A, B, P, S, L, T, F, Z et H. Toute la difficulté, dans la gestion des formats de données, consiste à proposer des correspondantes permettant la restitution parfaite des données écrites ; cette notion est appelée réversibilité. Ainsi, un nombre ne pourra pas être mémorisé dans un format binaire s’il nécessite plus de quatre octets (ou huit depuis la version 5 d’OS/400). De plus, tous les formats de WinDev n’ont pas forcément d’équivalence sur l’AS/400. Pour permettre une restitution fidèle, nous devons utiliser des formats suffisamment grands pour contenir l’information. La portabilité 18 des données peut être souhaité par le développeur, c’est-à-dire, avoir la possibilité d’utiliser les données avec d’autres programmes, qu’ils soient dans un autre projet WinDev ou directement dans l’AS/400. Ainsi, en utilisant le type « Alphanumérique », les données seront traduites par Easycom dans le « jeu de caractères » de l’AS/400. Ceci permet, à partir de l’AS/400, une consultation et/ou une modification des données par la commande DSPPFM19 et/ou « STRDFU20OPTION(5) ». Cependant, l’utilisation de caractères inadaptés à la langue des systèmes Windows et AS/400 peut générer des problèmes. Effectivement, la conversion du jeu de caractère ANSI21 vers le jeu de caractère de l’AS/400, et vice versa, entraîne des pertes. La table de conversion permettant ce transfert n’est pas réversible ; cela est directement dû au codage d’un caractère sur 8 bits et donc qu’une table de conversion ne permet que 256 caractères différents, malgré l’existant de bien plus de 256 caractères distincts à travers les différentes langues.

18 Désigne la possibilité d’utiliser les informations de façon indifférente avec d’autres programmes ou systèmes. 19 Display physical file member : affiche les données d’une table d’un fichier physique. 20 Start DFU : utilitaire de création et de maintenance de fichier. 21 ANSI est la norme des caractères standard Windows. Pour information, OEM est celle des caractères du DOS.


01/09/2003 23:16:00 /42

Voici une représentation du cheminement des données :

Programme WinDev iSeries (AS/400) : Jeu de caractère système (CCSID)

BDD CCSID

JOB Utilisateur CCSID

JOB Easycom

Données Écrites

Easycom For WinDev

Données Lues

1 2 3

Un texte est écrit par une instruction WinDev ; cette instruction transmet ce texte à l’interface Easycom For WinDev qui la transmet à son tour au JOB Easycom sur l’AS/400. Jusqu’ici, aucune modification du texte n’est effectuée. Il faut remarquer que l’AS/400, le JOB utilisateur et la Base De Données (BDD) possèdent chacun un CCSID, c'est-à-dire un code de jeu de caractère propre, même s’ils sont identiques. Ainsi, il y a trois conversions possibles qui s’effectuent successivement dans le transfert des données entre les quatre objets suivants : JOB Easycom, OS/400, JOB Utilisateur et BDD. Le codage brut, c’est le fait de placer des données qui ne sont pas conditionnées (ni converties, ni formatées) et ne peuvent raisonnablement pas être utilisées par un autre système, voir programme, que l’originale ayant écrit ces données. Nous obtenons cette mémorisation par le type de données Hexadécimal. Ainsi, toutes les rubriques WinDev pourraient être mémorisées dans ce format, excepté les rubriques clés. En effet, une rubrique clé est utilisée pour indexer les données et donc ordonner un fichier ; une donnée clé ne peut donc pas être dans un format brut. — Il en résulterait un ordre de lecture inattendu ; l’explication se trouve directement dans la différence de fonctionnement des microprocesseurs Risc et Intel. — Les rubriques Mémos texte ou binaire de WinDev permettent de mémoriser jusqu’à 4Go de données. Dans le cas d’un fichier HyperFile, WinDev crée un fichier supplémentaire pour y stocker les mémos liés à un fichier. Ce fichier additionnel porte le même nom que le fichier de données mais avec une extension « MMO ». C’est dans cette même logique que le produit Easycom For WinDev permet de gérer ces mémos ; un fichier de données supplémentaire est utilisé ; son nom est fabriqué avec les huit premiers caractères du fichier de données suivi des deux caractères underscore « _ ». J’ai saisi un exemple et des informations plus précises sur ce sujet dans l’annexe « 4.7 Structure des Mémos AS/400 avec explication » que vous trouverez en page 40. En général, la limite des données des rubriques WinDev est bien plus importante que celle des types de données de l’AS/400. La limite d’une donnée représente la taille ou la valeur minimale et maximale qu’un format peut autoriser. Ainsi, une rubrique « caractère » de WinDev permet de mémoriser au minimum un caractère et au maximum un caractère. Cela signifie que cette donnée utilisera un seul octet dans le fichier. De même, la rubrique WinDev « texte » permet de mémoriser de 1 à 65536 caractères. Pour l’AS/400, la rubrique texte est limité à 32766 caractères dans son option la plus favorable (données de taille fixe et ignorant la valeur nulle). Pour les nombres, la limite est définie par la taille en nombre de chiffres des parties entières et décimales. Vous retrouverez les informations sur les limites des formats


01/09/2003 23:16:00 /42

dans les annexes « 4.2 Type de rubrique en WinDev 7.x » en page 35 et « 4.3 Type AS/400 (en DDS) » en page 35. Un enregistrement 22 est aussi limité dans sa taille ; cette dernière représente le format de stockage en octet, et donc pouvant être écrit en une seule fois dans le fichier. Ainsi, pour WinDev, l’enregistrement d’un fichier HyperFile peut varier de 16 octets à 2Go, et pour l’AS/400, il peut varier de 1 à 32766 octets. À l’aide de toutes ces informations, j’ai établi un tableau de correspondance que vous trouverez dans l’annexe « 4.5 Correspondance de Type WinDev vers Type AS » en page 36. Nous pouvons y remarquer que les rubriques WinDev de type texte peuvent toutes être écrites dans le format AS Alphanumérique, excepté les rubriques mémo qui sont spécifiques. De même, les rubriques peuvent être codées dans le format brut Hexadécimal, excepté les mémos, la date, l’heure et la durée qui ont des formats spécifiques ou associés.

¤ La portabilité n’assure pas la réversibilité ; il n’est pas raisonnable de placer autre chose que du texte dans un type de donnée Alphanumérique. Les limites de données et d’enregistrement entre WinDev et l’AS/400 sont importantes. Une donnée brute permet de mémoriser presque toutes les rubriques WinDev.

2.6.3 Génération des données AS/400 La récupération des informations de l’analyse va permettre, dans un premier temps, de déclarer la structure du fichier de données.

Avant d’aller plus loin, voici quelques informations sur la structure de fichier de l’AS/400 : Les informations de structure sont contenues dans le membre23 d’un fichier source ; je noterai désormais « source DDS », le conteneur de cette information. Un fichier regroupe un ou plusieurs membres (un peu comme un classeur Excel qui regroupe plusieurs feuilles). Les fichiers sont identifiables par leurs type « *FILE ». Un fichier source aura un attribut « PF-SRC » et un fichier de données l’attribut « PF-DTA ».

La fabrication d’un fichier de données est obtenue par la compilation d’une source DDS ; ce dernier nécessite un ensemble d’information que nous récupèrerons à travers l’analyse WinDev. Cependant, les informations WinDev ne correspondent pas, en général, aux informations utilisables dans la source DDS ; c’est à cause des différents types de données (format, limite et déclaration), ainsi que de la longueur et du format des diverses informations.

22 Un enregistrement représente une ligne de données lorsque le fichier est représenté sous forme de table. 23 Un membre de fichier AS/400 équivaut à une feuille de calcul d’un fichier Excel.


01/09/2003 23:16:00 /42

Pour générer une rubrique, l’AS/400 restreint à 10 caractères les noms des fichiers, des membres, des rubriques (restriction désignée maintenant par nom système 24 ), et à 30 caractères leurs noms étendus (Alias). Les noms respectent une écriture spécifique qui leur est propre ; par exemple, le premier caractère du nom ne peut pas être un chiffre. Voici le masque 25 des caractères autorisés :

o System, 10 caractères : A-Z @ $ # puis A-Z 0-9 @ $ # _,

o Alias, 30 caractères : A-Z puis A-Z ; 0-9 ; _.

Pour concevoir le nom d’une rubrique , nous pouvons nous référer à plusieurs informations WinDev comme le nom de la rubrique et son libellé. Les utilisateurs WinDev utilisent couramment plus de 10 caractères. Les rubriques commencent souvent par des noms presque identiques. « Référence de la région », « Référence du département », « Référence de l’article » et « Référence du client » peuvent être des noms de rubrique d’un même fichier. Dans ce cas, nous ne pouvons pas envisager de générer le nom de la rubrique AS/400 avec les dix premiers caractères. Une autre solution qui m’a été enseigné à la CCI, est d’utiliser une technique que j’ai noté « 1/2 » (1 sur 2). La technique « 1/2 » consiste à utiliser la première lettre du premier mot, les deux premières lettres du second, la première du troisième, etc. Pour l’affiner, nous retirons les mot de liaison tel que « de », « des », « le », « la », « les », « un », « une ». Le dernier mot peut compléter à 10 le nom généré. Par exemple, la rubrique « Nombre d’opération à effectuer par secondes » serait traduit en « NOPESECOND ». Bien entendu, l’utilisateur WinDev peut préférer un autre nom par exemple « NBOPSEC » à « NOPESECOD » ; cela fait partie des nouvelles idées du projet. Pour qu’un fichier puisse être utilisé par un programme RPG, il sera préférable de limiter le nom des rubriques à 8 caractères. Ceci pourra être définit dans les options globales du projet. Le schéma suivant représente d’une façon simplifiée l’origine des informations WinDev utilisées pour générer les déclarations de la source DDS.

24 Le nom système est une information de dix caractères utilisée comme un identifiant (référant) par l’AS/400. 25 En informatique, le mot masque est utilisé pour définir un filtrage d’élément.


01/09/2003 23:16:00 /42

WinDev Rubrique AS/400 Alias [30] Nom Rubrique Nom Rubrique [10] Libellé Entête Colonne [3×20] Infos Étendues Texte [50]

"HFTYPE="+TypeRubrique (ex : HFTYPE=2) Note Note SQL Type de rubrique TypeAS Type Données (N/T) FLTPCN ; si TypeRub Réel

Est une Clé (0/1) TailleData LonChiffreEntier Longueur LonDéc LonDéc Nb Poste

ALWNULL (option)DATFMT(*ISO) TIMFMT(*ISO)

De la même façon, nous utiliserons les informations de l’analyse WinDev pour définir les propriétés d’un fichier de données, d’un journal, d’une clé, d’une contrainte. Nous pourrons aussi transférer les données. Le schéma suivant illustre ce fonctionnement :

WinDev Fichier AS/400 Alias SQL [128] Nom Logique Nom System [10] Libellé Texte du PF [50] Nom sur Disque Infos Étendues Note Note SQL Type de fichier Data Data Journal (liste)

JRN+JRNRCV

Clé(s) (liste)

LF (voir fabrication des clés) LF.Nom = PF.Nom[8]## LF.Texte = Clé # sur PF.Nom

Contraintes Référentiel (liste)

Contraintes Référentiel

¤ La source DDS est basée sur les informations de l’analyse. Les

restrictions sur les différentes déclarations de la structure peuvent déconcerter les utilisateurs novices. Afin de les aider au mieux, des valeurs sont proposées dans tous les champs obligatoires.


01/09/2003 23:16:00 /42

2.6.4 Lecture d’un fichier membre Dans cette partie, je vais vous présenter la méthode d’accès aux données d’un fichier à partir de WinDev.

Avant d’aller plus loin, voici quelques informations complémentaires sur les fichiers AS/400 : Un fichier regroupe un ou plusieurs membres (un peu comme un classeur Excel qui regroupe plusieurs feuilles). Par défaut, Easycom permet d’accéder au premier membre (*FIRST) déclaré dans le fichier. Pour accéder à un autre membre, nous devons substituer le premier membre par le membre désiré ; pour cela, nous utiliserons la commande « OVRDBF » (Override with Database File). Avec la commande « DLTOVR » (Delete Override) nous rétablirons le fonctionnement initial. Voici une représentation schématique de la substitution :

C

B

Programme

(1) accès à A (2) accès à B

A

BDD 1

2

C

B

A

OVRDBF

Pour accéder à l’AS/400, le programme WinDev doit établir une connexion. Cette connexion est ouverte avec la commande « HOuvreConnexion » et fermée avec la commande « HFermeConnexion ». Cette connexion nécessite les informations suivantes :

o Adresse DNS ou TCP/IP du serveur AS/400

o Nom d’utilisateur

o Mot de passe

o Nom de connexion WinDev Le « nom de connexion » permet à WinDev d’identifier de façon unique la connexion parmi toutes celles qui pourraient déjà exister. — Easycom utilise une licence par connexion simultanée. — Une première solution pour accéder aux données d’un fichier consiste à l’importer dans l’analyse associée au programme. Ainsi, à son démarrage, WinDev établi automatiquement la connexion aux fichiers de l’analyse active. Pour lister les données, il suffit au programme de charger séquentiellement les enregistrements et de les afficher.


01/09/2003 23:16:00 /42

Cette importation permet de déclarer la structure. Ainsi, en important un fichier source, la structure est préparée dans l’analyse. Ce qui donne, pour l’exemple du fichier source QDDSSRC, la fenêtre MLD ci-contre.

Grâce à la commande de substitution, nous pourrons obtenir les informations du membre existant désiré. Une autre solution consiste à accéder à un fichier externe provenant de l’AS/400. Cette méthode permet d’obtenir les informations de tous les types de fichiers, quels qu’en soient leurs structures. En effet, une fois la déclaration externe établi, nous pouvons obtenir la liste des rubriques (et leur structure) du fichier avec la commande « HListeRubrique ». Il nous reste plus qu’à lire séquentiellement les données comme dans la première solution.

¤ Les données sont contenues dans le membre d’un fichier. Un fichier peut avoir plusieurs membres, mais par défaut, seul le premier est accessible. Une substitution permet d’atteindre un autre membre.

2.6.5 Écriture d’un fichier membre Nous ne pouvons écrire des données sur l’AS/400 que dans le membre actif26 d’un fichier. Je parle de membre actif, pour les fichiers à membre multiple, car je sous-entends par cette idée qu’une substitution permet de désigner le membre à utiliser. Avant tout, pour écrire des données dans un membre, il faut qu’il existe. Par défaut, un fichier de données possède par sa création un membre. Mais les fichiers sources, qui sont des fichiers à membres multiples, ne possèdent pas forcement de membre. La commande « ADDPFM » permet d’ajouter un membre à un fichier. Celle-ci me sera très utile pour créer les sources DDS. Ce qui donne, pour l’ajout d’une source DDS nommé « TOTO » au fichier source « QDDSSRC », la commande suivante :

ADDPFM FILE(OLIVIER/QDDSSRC) MBR(TOTO) TEXT(TEST) SRCTYPE(PF) Une fois le membre créé, nous pouvons y placer des données. Il suffit simplement d’utiliser les mêmes méthodes que pour la lecture d’un fichier membre, puis d’y écrire des nouvelles données. Il faut remarquer que le membre d’un fichier source (source DDS) possède une structure spécifique qui repose sur les trois rubriques suivantes :

o SRCSEQ, numéro d’ordre des données au format « 9999.99 », sur 6 octets,

o SRCDAT, nombre désignant une date au format AAMMJJ, sur 6 octets,

o SRCDTA, une chaîne de 80 caractères contenant les données, sur 80 octets. Soit un total de 92 octets par enregistrement pour un membre de fichier source standard — La taille du format d’enregistrement est définie lors de la création du fichier source. —. 26 C’est soit le premier membre (*FIRST), soit le membre substitué par la commande OVRDBF.


01/09/2003 23:16:00 /42

L’usage veut que la séquence n’utilise pas la partie décimale ; cela permet à l’utilisateur d’effectuer des insertions de données entre deux autres. La chaîne de donnée d’un membre source ne doit pas recevoir des données au hasard. Pour que l’AS/400 compile la source DDS, la chaîne SRCDTA doit respecter les normes de la carte A. Vous retrouverez ses spécificités dans l’annexe « 4.4 Spécification de la carte A : DDS pour PF et LF » en page 36.

¤ L’écriture de données s’effectue dans un membre ; de ce fait, le membre, ainsi que le fichier, se doivent d’exister. Les membres sources ont une structure particulière ; la rubrique de données SRCDTA est liée à une spécification de carte A.

2.6.6 Compilation d’un DDS Afin de créer un fichier de données, nous avons créé une source DDS à partir des informations extraites de l’analyse WinDev sélectionnée par l’utilisateur. Cette source DDS regroupe la définition des différentes rubriques. Elle peut aussi contenir, suivant les options utilisateur, une clef primaire27 (unique ou non, ordonnée, composée de plusieurs rubriques, associé à une table de séquence de tri). Si le fichier de données n’existe pas, nous pouvons le créer en compilant la source DDS à l’aide de la commande « CRTPF » (Create Physical File) signifiant « créer un fichier physique ». Dans le cas où le fichier de données existe déjà, il est préférable de ne pas détruire les données. La commande « CHGPF » (Change Physical File), signifiant « changement de la structure du fichier de données », permet d’appliquer cette nouvelle description de données. Cette dernière commande est plus délicate à utiliser. En effet, si une rubrique diminue en quantité de stockage de donnée, et de même si elle disparaît, dans la nouvelle déclaration de structure (la source DDS), l’OS/400 affiche une demande de confirmation pour tronquer les données. — Pour répondre à cette question, il faut démarrer la commande en mode interactif, ce qui n’est pas possible par une exécution programme. — Dans ce cas, le programme reçoit une erreur non bloquante d’Easycom. Cette erreur ne permet pas d’obtenir une information précise du problème rencontré, car elle informe simplement que le traitement ne s’est pas terminé. C’est la même erreur qui serait obtenue si la source DDS contient des informations erronées. Une solution consisterait à valider la perte de données par une réponse automatiquement du système ; mais cela entraîne un autre problème, c’est que l’utilisation de réponse automatique est valable pour tous les profils de l’AS/400. Cette solution n’est donc pas envisageable. Je n’ai pas eu le temps de rechercher la faisabilité de quelques autres idées, comme la récupération de l’historique d’erreur, afin de d’atteindre l’avant dernière erreur, et proposer au moins l’affichage à l’utilisateur. Une autre solution consiste à créer un nouveau fichier de données dans la bibliothèque temporaire, puis de lui transférer les données via une commande « CPYF » (Copy File) avec les options qui permettent de perdre/tronquer les données.

27 On désigne par clef primaire une clef d’indexage des données contenues dans le fichier physique.


01/09/2003 23:16:00 /42

¤ La compilation d’une source DDS permet de fabriquer ou de modifier un fichier de données. La modification d’un fichier de données peut entraîner des complications, ce qui oblige actuellement l’utilisateur à effectuer le traitement directement sur l’AS/400.

2.6.7 Arborescence du profil et liste d’information Le projet s’oriente davantage vers les utilisateurs WinDev novice de l’AS/400. Il est fort probable que ces utilisateurs ne connaissent pas vraiment le fonctionnement « Bibliothèque | Fichier | Membre ». Afin de les assister, je propose d’afficher une petite arborescence de sélection comme le propose Windows, mais dans notre cas, sur 1, 2 ou 3 niveaux. Ainsi, si l’utilisateur désire sélectionner une bibliothèque, l’arborescence affichera les bibliothèques utilisateur définies dans son profil (JOBQ). S’il désire sélectionner un fichier source, l’arborescence affichera les bibliothèques et leurs fichiers sources. Le même niveau de développement sera proposé pour la sélection d’un fichier journal (*JRN) et d’un fichier receveur de journal (*JRNRCV). Un niveau trois permettra d’atteindre la liste des membres des fichiers. Pour le premier niveau, la liste des bibliothèques utilisateur du profil doit être récupérable. Il est facile de visualiser cette liste avec la commande interactive « DSPLIBL » (Display Library List) ; cependant, par programme, cette commande n’est pas vraiment utilisable car la sortie vers un fichier n’est pas disponible. Après beaucoup de recherche, et l’aide combiné de plusieurs de mes collègues, il est apparu que les commandes « DSPSYSVAL » (Display System Value) et « RTVJOBA » (Retrieve Job Attributes) permettent d’obtenir aussi des informations relatives au profil. Ainsi, les commandes suivantes permettent d’obtenir des données utilisables :

DSPSYSVAL SYSVAL(QSYSLIBL) DSPSYSVAL SYSVAL(QUSRLIBL) RTVJOBA USRLIBL(&L) RTVJOBA CURLIB(&O)

Avec ces quatre lignes, je peux obtenir la liste des bibliothèques utilisateurs et système spécifier dans le profil, ainsi que le nom de la bibliothèque courante. Il me faut ensuite, pour le niveau 2, obtenir la liste des fichiers de type sources (PF-SRC). Là aussi, j’ai cherché longtemps ; finalement, j’ai trouvé la commande qui me semble appropriée. Voici un exemple sur ma bibliothèque :

DSPFD FILE(OLIVIER/*ALL) TYPE(*BASATR) OUTPUT(*OUTFILE) FILEATR(*ALL) OUTFIILE(OLIVIER/LST) OUTMBR(*FIRST *REPLACE)


01/09/2003 23:16:00 /42

Cette commande écrit dans un fichier temporaire (plus exactement dans le répertoire temporaire du profil) la liste des fichiers. Dans ce fichier, on retrouve une rubrique « TYPEFILE » contenant « S » pour Source et « D » pour Données. Ainsi, j’obtiens à la fois la liste des fichiers sources et fichiers de données. Dans le niveau 2, il me faudra aussi obtenir les journaux et leurs receveurs. Les commandes suivantes me permettent d’obtenir ces informations :

DSPOBJD OBJ(OLIVIER/*ALL) OBJTYPE(*JRN) DSPOBJD OBJ(OLIVIER/*ALL) OBJTYPE(*JRNRCV)

Pour le niveau 3, il me faut la liste des membres d'un objet (fichier source ou de données). Voici un exemple appliqué sur un fichier de données à membre multiple :

DSPFD FILE(OLIVIER/TCLIENT) TYPE(*MBRLIST) OUTPUT(*OUTFILE) FILEATR(*ALL) OUTFILE(QTEMP/LST) OUTMBR(*FIRST *REPLACE)

La dernière liste d’information qui pourrait me manquer est la liste des contraintes associées à un fichier de données. Je n’ai pas encore eu le temps de faire quelques tests sur ce sujet, mais je pense que la commande DSPDBR devrait me fournir déjà quelques pistes.

¤ L’affichage d’une arborescence peut offrir à l’utilisateur novice ou pas une simplification très agréable. L’obtention des informations pour fabriquer cette aide nécessite l’exécution de plusieurs commandes ainsi que la lecture de plusieurs fichiers résultants.

2.6.8 Vocabulaire pour l’utilisateur L’utilisateur WinDev ne connaît généralement pas la terminologie de l’AS/400 et encore moins sont fonctionnement. C’est pourquoi, dans ce projet, je cherche un vocabulaire, simple et suffisamment correct, pour correspondre au mieux à la réalité de l’AS/400. Je n’ai, pour l’instant, pas encore établit de réelle proposition, car l’ensemble du projet doit être multi- langues. Chaque libellé est donc susceptible d’être lier à une touche de raccourci, et donc demander un terme plus approprié. —WinDev ne permet pas l’utilisation d’une même touche de raccourci pour plusieurs objets. — Dans l’immédiat, j’utilise en partie la terminologie WinDev sur les éléments provenant de l’analyse, et celle de l’AS pour les autres. Voici cependant quelques propositions rapides comme l’utilisation de : « Source » pour désigner le « membre », « base de données » pour « fichier physique », « Nom long » pour « Alias ». La plus grande difficulté est dans cette notion de membre qui n’est pas un fichier.

¤ La terminologie AS/400 peut engendrer des confusions pour l’utilisateur novice. Le choix d’un vocabulaire cohérent considérant la terminologie Windows, WinDev et AS/400 est très difficiles à obtenir.


01/09/2003 23:16:00 /42

2.6.9 Travail hors connexion AS/400 Le projet doit permettre à un utilisateur de générer un fichier que je nommerai le script. Ce fichier pourra être utilisé par la suite, sur un autre ordinateur, pour effectuer la génération des sources DDS, la création des fichiers et contraintes, l’association des journaux et receveurs. Dans cette optique, un utilisateur peut travailler sans être connecté à l’AS/400 devant recevoir les fichiers de données. Une autre utilisation intéressante du script est de pouvoir l’utiliser dans le déploiement d’application. Ainsi, le « constructeur DDS » n’est plus qu’une interface graphique de configuration du traitement ; il génère ce fichier script qu’il donne à l’interpréteur. Ce dernier sera intégré au « constructeur DDS » ; nous pourrions tout à fait envisager de développer un programme séparé. Dans l’interface graphique, le travail hors connexion va inhiber 28 une bonne partie des assistants comme les accès à l’arborescence (voir le paragraphe « 2.6.7 Arborescence du profil et liste d’information » en page 24), les tests d’existences des différents éléments AS/400, l’aperçu du membre actuel et d’autre.

¤ Le travail hors connexion permet à un développeur de préparer le traitement d’implantation des bases de données.

2.7 Résumé des solutions Analyse : la principale solution est celle de l’accès aux informations de l’analyse par des méthodes externes. Cela permet de conserver l’analyse courant au projet et ainsi d’accéder à des fichiers de travail. Accès au membre source : l’utilisation d’une déclaration intégrée à l’analyse simplifie la programmation. Interpréteur : dans l’immédiat, l’interpréteur de script sera intégré au projet. Vocabulaire : ce point n’a qu’une importance limitée ; il sera traité en finalisation de projet. Propriété absente : la propriété « Notes » ne peut pour l’instant être atteinte par programmation. Une fonction retournant une valeur vide sera créée. Elle pourra facilement être corrigée lorsque WinDev le sera. Compilation DDS sur fichier existant : récupérer si possible l’erreur de deuxième niveau pour l’afficher à l’écran est la solution retenue pour l’instant. Nom système (10 caractères) : les propositions générées, par la routine basée sur la méthode 1/2 (voir l’annexe « 4.8 Méthode 1/2 en WinDev » en page 41), par le libellé tronqué à 10 caractères, sont proposées à l’utilisateur qui pourra en saisir une autre.

28 Désactiver et parfois cacher.


01/09/2003 23:16:00 /42

¤ Ces solutions forment la base de l’écriture de code du programme. Si elles devaient être changées, il est fort possible qu’une grande partie des codes déjà écrits ne puissent plus être utilisés. Certains choix orientent un projet de manière irréversible (sauf si on recommence tout).

2.7.1 Quelques difficultés techniques rencontrées Pour valider les méthodes d’accès et de traitement des données, j’ai codé quelques programmes de tests qui, pour certains, m’ont apporté quelques petits soucis.

• ouverture de connexion Problème : l'accès à un fichier AS/400 (via WinDev) génère un blocage de 30 secondes de mon programme. Une double connexion à l'AS/400 génère ce problème. Analyse : En effet, la deuxième connexion attend que la première ait fini son temps de travail (Timeout de 30s du côté serveur) pour avoir la main. Cela entraîne le même problème en réutilisant la première connexion. Solution : N’utiliser qu'une seule connexion par machine. Cela ce traduit sous WinDev de n'avoir qu'une seule connexion ouverte à la fois, ou utiliser une connexion unique par projet (même nom, même compte).

• Accès au fichier multi membres Problème : lors des tests d'accès en lecture à des membres sources, même avec un « OVRDBF », je n'accédais qu'au premier (*FIRST) membre. Analyse : l'appel de la fonction ASAppel utilise la première connexion (dynamique) ; de ce fait, l'exécution des commandes travaille dans l'environnement de cette connexion. Il n'est pas possible de désigner la connexion. Solution : utiliser un même environnement par poste de travail. Rappel : chaque connexion utilise une licence.

2.7.2 Technique du langage Libellé et note : les objets graphiques (sauf les éléments des sélecteurs et interrupteurs qui m’ont générés des problèmes) possèdent la propriété « note » et « libellé ». Le libellé représente le texte affiché à l’écran, et note une chaîne mémorisée à la disposition du développeur. — On retrouve cette propriété « note » dans un grand nombre de langage Microsoft et Borland. — WinDev possède aussi une fonction « ChaîneConstruit » qui permet de remplacer les « %1 », « %2 », etc, par des paramètres. Afin d’éviter de créer une liste exorbitante d’intitulés dans le source du programme, j’utilise une technique qui me permet simplement de mettre à jour les libellés avec des paramètres. La méthode est la suivante :

o Si la note de l’objet est vide, l’affecter par le contenu du libellé.

o Affecter le libellé avec la valeur « construite » de la note et des paramètres. Cette méthode apporte un grand nombre d’avantages. Dans ce projet WinDev, l’ensemble des objets sont dans un environnement en langue multiple. Ainsi, le simple fait de choisir une langue met automatiquement à jour les libellés dans l’éditeur. Si une langue doit être ajoutée, il est plus simple d’effectuer la traduction dans l’interface graphique. De plus, WinDev dispose d’un outil de traduction extérieur qui est indépendant du code source. Grâce à cette méthode, le code source est indépendant de la langue affichée.


01/09/2003 23:16:00 /42

Code dynamique : WinDev permet d’interpréter dynamiquement du code source en W-Langage. Cela m’a permis de fabriquer des fonctions travaillant sur des informations passées en paramètres. Par exemple, l’accès à des objets numérotés comme « Mn1 », « Mn2 », « Mn3 ». Il suffit de passer le numéro, et l’interprétation dynamique permet de reconnaître le contenu d’une chaîne comme étant du code source. Liste : WinDev propose la commande « ExtraitChaîne » pour travailler sur des listes de données codées dans une chaîne. Une liste est une succession de données conditionnées par un séparateur. Son utilisation est simple et très courrante. J’ai donc à mon tour utilisé les listes dans de nombreux codes. Le W-Langage est la base de la programmation de WinDev. Au début, il est assez déconcertant vu qu’il est en français et aussi qu’un grand nombre de commandes ne respectent aucun format. Ainsi, j’ai trouvé couramment des instructions comme « ExtraitChaîne » et « ChaîneConstruit » ; je m’attendais à une syntaxe telle que toutes les commandes travaillant sur des chaînes commencent ou terminent par le mot « chaîne ». Cependant, depuis la version 7.x, l’éditeur WinDev propose la complétion29 automatique. Grâce à cela, je me permets d’écrire des noms de variables et de sous-programmes plus longs et plus explicites.

¤ L’utilisation de la propriété « note » permet au code d’être indépendant de la langue affichée. Les listes sont très souvent utilisées, et forment pratiquement un standard de programmation sous WinDev.

2.7.3 Interface graphique et scénario Un programme fonctionnant sous Windows ne conçoit pas son interface comme sous DOS ou sous AS/400. En effet, l’utilisateur Windows a l’habitude d’obtenir sur une fenêtre principale l’ensemble des informations. Le fonctionnement événementiel bouscule aussi l’utilisation stricte de la programmation procédurale. Afin de conserver les habitudes de l’utilisateur Windows, je dois prendre en charge le fonctionnement de la souris et afficher les données sur une même fenêtre (autant que possible, en utilisant des onglets si nécessaire). Il ne faut pas non plus entrer dans l’excès de la souris et oublier de prendre en charge l’utilisation du clavier. Ainsi, l’idée générale est de permettre, pour chaque sélection d’un élément, l’affichage de données dans une autre zone de la fenêtre. Le projet travaille sur les fichiers d’une analyse. Chaque fichier a ses propriétés, une liste de rubriques et de contraintes (il y a aussi les données associées et la possibilité d’un journal). Chaque rubrique a ses propriétés. Une rubrique peut aussi être une clé. Toutes les propriétés et listes doivent être affichées à l’utilisateur. Chacune de ces informations peuvent être modifiées à l’unité (activée, désactivée, renommée). La création des différentes fenêtres respecte l’ensemble de ces conditions. Vous les retrouverez dans l’annexe « 4.6 Écran du projet » en page 37, dans l’état actuel de mon travail.

29 La complétion est l’affichage d’une liste de mot commençant par les lettres saisies.


01/09/2003 23:16:00 /42

Le projet utilise actuellement cinq fenêtres ; l’image ci-dessous schématise leurs interdépendances. Elles prennent en charge les tâches suivantes : DDSBLD : fenêtre principale qui affiche la liste des fichiers à traiter et leur rubrique. Les propriétés de chacun sont contenues dans différents onglets. MireConnexion : permet d’ouvrir une connexion sur un AS/400 en spécifiant l’adresse du serveur, le nom et le mot de passe du profil à ut iliser. Selection_Fichier : sélectionne la liste des fichiers d’une analyse (en cours ou venant d’être sélectionnée sur le disque) et présente leur rubrique. Config : regroupe le paramétrage global de l’application : réponse et valeur par défaut, environnement.

Arbo : visualise suivant les niveaux d’appel la liste de bibliothèque utilisateur, les fichiers de données / source / journal / receveur, les membres. D’autres fenêtres sont en prévision, comme par exemple, une demande d’action à faire sur l’existence d’un objet (source DDS ou fichier de données). Le fenêtre « DDSBLD » est la plus difficile à concevoir (elle est aussi la plus difficile à programmer). Elle regroupe l’ensemble des informations que l’utilisateur peut modifier. Pour la concevoir, j’ai préalablement dessiné plusieurs possibilités. WinDev comptabilise le temps de travail des différents éléments d’un projet. Ce qui donne :

Type Nom du composant DuréeProjet DDS_AS400 12j 03h 25m Collection Procedures globales de DDS_AS400 10j 22h 34m Fenêtre Arbo 03h 29m Fenêtre Config 15h 11m Fenêtre DDSBLD 03j 07h 15m Fenêtre Fen_Confirmer 02h 03m Fenêtre Gestion Fichier sur AS 11h 08m Fenêtre Listage 04j 19h 40m Fenêtre MireConnexion 10h 06m Fenêtre RunCL 01j 08h 56m Fenêtre Selection_Fichier 13h 39m Fenêtre TraceAS 04h 09m Requête Requete1 23h 43m Requête Requête2 01j 00h 08m


01/09/2003 23:16:00 /42

2.8 Bilan de projet Ce projet est particulièrement intéressant pour les points suivants :

o Projet émis à partir d’un ancien produit avec des idées nouvelles,

o Prise de connaissance (obligatoire) du « constructeur DDS » et d’Easycom,

o Étude des limitations de WinDev et de l’AS/400,

o Établir un projet, son analyse et un planning de développement,

o Créer une interface utilisateur (multi- langue),

o Mettre en œuvre le développement,

o Faire les tests et les recettages30. La phase d’analyse, bien que longue et complexe, m’a permis d’affiner les exigences du produit. L’ensemble des connaissances, pour travailler sur ce projet, dépasse largement mon estimation initiale. Les problèmes rencontrés sont multiples, et parfois insurmontables, comme les impossibilités de WinDev. Ce projet m’a permis de travailler sur des parties proches du système et ainsi rechercher, sur Internet ou auprès de mes collaborateurs, des méthodes et instructions nouvelles. Il est complet, très proche d’un projet « professionnel » tel que je serai amené à en avoir.

2.8.1 Planning réel J’ai n’est pas respecté le planning prévisionnel ; cela est dû en partie aux éléments suivants :

o L’étude des manuels s’est prolongée jusqu’à la troisième semaine,

o La prise de connaissance du code source du constructeur DDS fut difficile,

o WinDev 7.5 contient des erreurs qui m’ont fait perdre beaucoup de temps,

o J’ai recherché beaucoup d’information : entre autre, des commandes AS/400,

o L’interface graphique fut difficile à établir, et contient encore des imperfections.

Voici un résumé du planning réel. Les trois dernières semaines conservent leur caractère prévisionne l vu que ce rapport doit être remis pour septembre. Ce qui donne :

lun 28/07/03 lun 18/08/03 lun 08/09/03mar 08/07/03 mar 29/07/03 mar 19/08/03 mar 09/09/03mer 09/07/03 mer 30/07/03 mer 20/08/03 mer 10/09/03jeu 10/07/03 jeu 31/07/03 Bilan CCI jeu 21/08/03 jeu 11/09/03

ven 11/07/03 ven 01/08/03 WD7.5 ven 22/08/03 ven 12/09/03

lun 14/07/03 lun 04/08/03 lun 25/08/03 lun 15/09/03mar 15/07/03 mar 05/08/03 mar 26/08/03 mar 16/09/03mer 16/07/03 mer 06/08/03 mer 27/08/03jeu 17/07/03 jeu 07/08/03 jeu 28/08/03

ven 18/07/03 ven 08/08/03 ven 29/08/03

lun 21/07/03 lun 11/08/03 lun 01/09/03mar 22/07/03 mar 12/08/03 mar 02/09/03mer 23/07/03 mer 13/08/03 mer 03/09/03jeu 24/07/03 jeu 14/08/03 jeu 04/09/03

ven 25/07/03 ven 15/08/03 ven 05/09/03

Etudedoc.

Produiteasycom

Etude doc.Produit

easycom+ Existant

Etude doc.EasycomexistantWD7.5

ExistantWD7.5

ExistantSolution

WD<->ASInterface

SolutionInterface

graphiqueScénario

InterfaceSolutionCodage+ Test

+ Recettage

InterfaceSolutionCodage+ Test

+ Recettage

Codage+ Test


Codage+ Test


documentde prog

30 Vérifier qu'un produit est bien conforme aux spécifications théoriques définies au début du projet.


01/09/2003 23:16:00 /42

2.8.2 Encodage L’encodage, c’est à dire la programmation, du projet n’est encore pas très avancé. Les fenêtres « MireConnexion » et « Selection_Fichier » sont en partie achevées. La fenêtre « Config » voit son code évoluer au fur et à mesure de l’avancement de la programmation de la fenêtre principale « DDSBLD ». La partie des menus gérant l’historique d’ouverture d’analyse et de connexion AS/400 est terminée. Il reste encore beaucoup à faire. Estimation de l’état de projet en fin de stage : en regardant le temps déjà utilisé pour le codage actuel, je crains de ne pas avoir un projet très avancé ; cependant, les procédures globales déjà effectuées me permettent enfin d’avancer plus facilement.

2.8.3 Raisonnement sur l’évolution Beaucoup d’idées sont apparues pendant la phase d’analyse du projet. Certaines pourraient facilement compléter le projet, d’autres obligeraient de repenser le projet dans sa globalité. Par exemple, le constructeur DDS permet de générer sur l’AS/400 la structure de fichier, avec les paramètres choisis par l’utilisateur. Toute cette configuration pourrait être mémorisée et liée à une analyse. Ainsi, l’ensemble des analyses des multiples projets pourrait être suivit par le constructeur. Cependant, cela n’est possible que si aucune modification n’ait été effectuée directement sur l’AS/400 ; ce qui est délicat, vu que la modification de la structure d’un fichier de donnée (CHGPF) peut forcer l’utilisateur à intervenir sur le serveur. Un autre exemple serait de concevoir un constructeur de fichier de données utilisant le langage SQL. En effet, l’AS/400 permet avec son SQL 400 la création et la maintenance des fichiers de données. Cela sera peut-être la procha ine étape.

3 Conclusion

Ce stage fut très intéressant. Il m’a permis de travailler avec le produit Easycom, développé par la société d’accueil, qui est connu par la plupart des développeurs multi-systèmes utilisant l’AS/400. Le projet qui m’a été demandé est très complet ; il m’a permis de développer sous WinDev, tout en continuant à utiliser l’AS/400. Pendant cette période qui m’a semblé très courte, j’ai exploré l’ensemble de tâches qu’un projet nécessite, comme l’analyse du besoin et des données, l’élaboration d’un planning, la validation de solutions techniques, la conception d’une interface utilisateur, un cahier des charges puis le développement et les tests du programme… Je suis très content de l’accueil et de l’aide qui m’a été apportée, et j’espère avoir laissé un souvenir professionnel de mon passage. — Je suis aussi content d’avoir terminé ce rapport écrit qui aura totalisé 3360 minutes de saisie sous Word. —


01/09/2003 23:16:00 /42

4 Annexes

Les annexes qui suivent sont pour la majorité des documents de travail que j’ai établi au fur et à mesure que je déterminais les axes du développement.

4.1 Écran du constructeur actuel (DDSBLD) Le constructeur actuel est très simplifié ; les quelques paramétrages possibles sont les suivants :

o Désignation de la bibliothèque d’objet et de membre (avec son fichier source),

o Activation ou non de : la création DDS, la compilation DDS, la génération des contraintes et du transfert de données,

o Spécification du code avec : *LIBL, l’ordre logique et des noms des clés composées,

o Option supplémentaire des commandes de création et de tri,

o D’une façon globale, correspondance des différents formats de données. Pour cela, l’environnement nécessite cinq fenêtres commentées ci-dessous. 4.1.1 – Sélection des fichiers Cet écran permet de charger un fichier d’analyse avec [ Parcourir ] et par son tableau de désigner d’une sélection multiple les fichiers à traiter.


01/09/2003 23:16:00 /42

4.1.2 – Sélection du traitement Cet écran permet d’atteindre :

o par le bouton [ Contraintes ] la configuration des contraintes liée aux fichiers à traiter,

o par le bouton [ Préférences ] la fenêtre de configuration globale « Préférence »,

o par les coches la liste des actions de traitement et de spécification de code. Le bouton [ Exécuter ] lance le traitement sur le fichier affiché. Avec le bouton [ Exécuter Tous ] tous les fichiers sont traités.

4.1.3 – Préférence globale des données Dans la fenêtre des préférences onglet « Types de données », l’utilisateur peut spécifier la correspondance des données WinDev et AS/400.


01/09/2003 23:16:00 /42

4.1.4 – Préférence globale des options Dans la fenêtre des préférences onglet « Options des fichiers », l’utilisateur définit les options supplémentaires des commandes de création et peut aussi définir des spécifications de champs et d’objet.

4.1.5 – Contraintes Cette dernière fenêtre permet de sélectionner les règles AS/400 à appliquer sur la contrainte de fichier.


01/09/2003 23:16:00 /42

4.2 Type de rubrique en WinDev 7.x TypeHF ConstanteHF Désignation de rubrique - Fr Désignation - US Type Format Limite Min Limite Max

0 hRubInvalide Type de rubrique invalide Invalid heading -1 hRubIdAuto Identifiant automatique (8 octets) AutoId N Id. automatique 0 9.22337E+182 hRubTexte Texte (X octets) Text T Texte 1 Car. 65536 Car.

3 hRubEntier2 Entier signé sur 2 octets Integer on 2 bytes NNumériqueSélecteur, liste, combo

-32768 32767

4 hRubEntier1 Entier signé sur 1 octet Integer on 1 bytes N NumériqueSélecteur, liste, combo

-128 127


-2147483648 2147483647

6 hRubRéel4 Réel sur 4 octets Real on 4 bytes N NumériqueSélecteur, liste, combo

-3.40E+38 3.40E+38

7 hRubRéel8 Réel sur 8 octets Real on 8 bytes N NumériqueSélecteur, liste, combo

-1,79e+308 1,79e+308

8 hRubNumEnr Numéro d'enregistrement Record number

9 hRubEntierNonSigné2 Entier non signé sur 2 octets Unsigned interger on 2 bytes N NumériqueSélecteur, liste, combo

0 65536

10 hRubDate6 Date sur 6 Date on 611 hRubHeure Heure (hhmm) (4 octets) Time T Heure (hhmm) 00:00 23:59

12 hRubEntierNonSigné1 Entier non signé sur 1 octet Unsigned interger on 1 bytes NNumériqueInterrupteur

00

2561

13 hRubRéelTurbo Réel turbo Turbo real14 hRubDate8 Date sur 8 Date on 8 T Date 01/01/0001 31/12/999915 hRubMémoTexte Mémo texte (8 octets) Text memo T Texte 0 4Go Car.16 hRubMémoBinaire4 Mémo chaîne binaire (4 octets) Binary memo17 hRubMonétaire Monétaire (10 octets) Currency T Monétaire -6.04463E+17 6.04463E+1718 hRubMémoBinaire Mémo binaire (8 octets) Binary memo (8 bytes) N Son, image, binaire… - -


-9.22337E+18 9.22337E+18

20 hRubEntierNonSigné8 Entier non signé sur 8 octets Unsigned interger on 8 bytes NNumériqueSélecteur, liste, combo

0 1.84467E+19

21 hRubImage Image Image

22 hRubEntierNonSigné4 Entier non signé sur 4 octets Unsigned interger on 4 bytes NNumériqueSélecteur, liste, combo

0 4294967296

23 hRubBinaire Chaîne binaire (X octets) Binary string N Son, image, binaire… 1 Car. 65533 Car.24 hRubDateHeure Date/Heure (8 octets) Date and time T Date 01/01/0001 00:00 31/12/9999 23:5925 hRubDurée Durée (8 octets) Time duration N Date -9.22337E+18 9.22337E+1826 hRubCaractère Caractère (1 octet) Char N Texte 1 Car. 1 Car.

27 hRubBooléen Booléen (1 octet) Boolean NBooléenInterrupteur

0 1

28 hRubIdAuto4 Identifiant automatique (4 octets) AutoId on 4 bytes N Id. automatique 0 2147483648 J’ai surligné en jaune les rubriques qui ne sont plus documentées ; elles semblent à priori impossibles à obtenir avec l’éditeur d’analyse de WinDev 7.x, mais rien n’indique clairement que ces valeurs ne pourraient pas être lues dans une analyse de WinDev 5.x.

4.3 Type AS/400 (en DDS)

n° Désignation 30…34 35 36.37 38 45…80 Taille1 Character 1 à 32766 Car. A - Nb Car.

1 à 32765 Car. A - ALWNULL Nb Car.1 à 32740 Car. A - VARLEN Nb Car.1 à 32739 Car. A - VarLen AlwNull Nb Car.

2 Binary 1 à 9 Chiffres (V4) B 0 à 9 2, 41 à 18 Chiffres (V5) B 0 à 18 2, 4, 8

3 Packed decimal 1 à 31 Chiffres P 0 à 31 (NbC\2)+14 Zoned decimal 1 à 31 Chiffres S 0 à 31 Nb Chiffres5 Date 6, 8 ou 10 Car. L - 6, 8, 10 Car.6 Time 8 Car. T - 8 Car.7 Floating-point 1 à 9 Chiffres F 0 à 9 4 Oct.8 1 à 17 Chiffres F 0 à 17 FLTPCN 8 Oct.9 Timestamp 26 Car. Z - 26 Car.

10 Hexadecimal 1 à 32766 Octets H - Nb Oct. Les types numériques P, S et B inclus le signe. (V4) et (V5) désigne la version de l’OS/400. Le « Timestamp » (26 octets) est du format "YYYY-MM-DD-hh.mm.ss.uuuuuu".


01/09/2003 23:16:00 /42

4.4 Spécification de la carte A : DDS pour PF et LF Le format de la déclaration de structure de données répond à une norme désignée sous le terme « carte A ».

Position Désignation FR Valeur Info1…5 Numéro d'ordre " " / chiffre Indiquez un nombre d'ordre pour chaque ligne. Facultatif, n'est utilisé qu'a titre inficatif.

6 Type de carte " ", A Placez A pour indiquer une spécification de DDS. Facultatif, n'est utilisé qu'a titre indicatif.7 Commentaire " ", * Ligne de commentaire (positions 8 à 80). Un interligne (rien de 7 à 80) = commentaire.

8…16 Traitement " " Laisser blanc17 Type / Spécifications R, " ", K, S, O, J, H Identifie le type de nom (19 à 28) ou de spécification.18 Réservé " " Laisser blanc

19..28 Nom Nom de format / champ.29 Référence " ", R Référence de format

30..34 Taille Spécifie le nombre de caractère ou de chiffre entier35 Type de donnée P, S, B, F, A, H, L, T, Z Sélectionne de type de donnée.

36..37 Position décimale " ", 0..31 (¤) Spécifie le nombre de décimal.38 Utilisation " ", B, I, N Définit une zone en entrée-seule, entré et sortie, ou ni l'un ni l'autre.

39..44 Localisation " " Laisser blanc45..80 Mot clef Voir liste Spécification du champ (36 caractères)

(¤) Nombre de Décimal <= Nombre de Chiffre ; +n et -n peuvent être utilisé pour ajouter ou réduire la position par rapport à une description par référence (R en 29).

4.5 Correspondance de Type WinDev vers Type AS/400 Ce tableau synthétise la liste les types des données AS/400 pouvant être utilisée pour stoker des rubriques WinDev. Les Identifiants Automatique ne doivent pas être en Hexa (§ Easycom) ; de même pour toutes les rubriques clef.

TypeHF ConstanteHF Cha

ract

er

A

1

Bin

ary

B

2

Pac

ked

P

3

Zone

d

S

4

Dat

e

D

5

Tim

e

T

6

Floa

ting

F

7/8

Flo

atin

g D

ou

ble

Z

9

Hex

adec

imal H

10

0 hRubInvalide1 hRubIdAuto d LenChiffre,P,0, ¤ LenChiffre,S,0,2 hRubTexte d TailleData,A,, ¤ TailleData,P,0, ¤ ,L,,DATFMT(*##) ¤ ,T,,TIMFMT(*ISO) ¤ TailleData,H,,

3 hRubEntier2 ¤ LenChiffre,B,, d LenChiffre,P,0, ¤ LenChiffre,S,0, TailleData,H,,

4 hRubEntier1 ¤ LenChiffre,B,, d LenChiffre,P,0, ¤ LenChiffre,S,0, ¤ TailleData,H,,

5 hRubEntier4 ¤ LenChiffre,B,, d LenChiffre,P,0, ¤ LenChiffre,S,0, TailleData,H,,

6 hRubRéel4 d LenChiffre,P,LenDec, ¤ LenChiffre,S,LenDec, ¤ 9=,F,9=,FLTPCN(*single) TailleData,H,,

7 hRubRéel8 d LenChiffre,P,LenDec, ¤ LenChiffre,S,LenDec, ¤ 17=,F,17=,FLTPCN(*double)TailleData,H,,

8 hRubNumEnr d TailleData,H,,

9 hRubEntierNonSigné2 ¤ LenChiffre,B,, d LenChiffre,P,0, ¤ LenChiffre,S,0, ¤ TailleData,H,,

10 hRubDate6 ¤ TailleData,A,, d ,L,,DATFMT(*YMD) TailleData,H,,11 hRubHeure ¤ TailleData,A,, d ,T,,TIMFMT(*ISO)

12 hRubEntierNonSigné1 ¤ LenChiffre,B,, d LenChiffre,P,0, ¤ LenChiffre,S,0, ¤ TailleData,H,,

13 hRubRéelTurbo d TailleData,H,,14 hRubDate8 ¤ TailleData,A,, ¤ 8,P,0, ¤ 8,S,0, d ,L,,DATFMT(*ISO)15 hRubMémoTexte ¤ 9,B,, d 10,P,0, 10,S,0,16 hRubMémoBinaire4 ¤ 9,B,, d 10,P,0, ¤ 10,S,0, TailleData,H,,17 hRubMonétaire ¤ TailleData,A,, d 24,P,NbDec, ¤ 24,P,NbDec, ¤ TailleData,H,,18 hRubMémoBinaire ¤ 9,B,, d 10,P,0, ¤ 10,S,0,

19 hRubEntier8 ¤ V5:LChiffre,B,, d LenChiffre,P,0, ¤ LenChiffre,S,0, TailleData,H,,

20 hRubEntierNonSigné8 ¤ V5:LChiffre,B,, d LenChiffre,P,0, ¤ LenChiffre,S,0, TailleData,H,,

21 hRubImage d TailleData,H,,

22 hRubEntierNonSigné4 ¤ LenChiffre,B,, d LenChiffre,P,0, ¤ LenChiffre,S,0, TailleData,H,,

23 hRubBinaire d TailleData,H,,24 hRubDateHeure ¤ TailleData,A,, ¤ TailleData,P,0, ¤ TailleData,S,0, ¤ TailleData,Z,,25 hRubDurée TailleData,A,, d TailleData,P,0, ¤ TailleData,S,0, TailleData,H,,26 hRubCaractère ¤ TailleData,A,, d TailleData,H,,

27 hRubBooléen d TailleData,P,0, ¤ TailleData,S,0, ¤ TailleData,H,,

28 hRubIdAuto4 d LenChiffre,P,0, ¤ LenChiffre,S,0, ¤ = compatible, d = par défaut LenChiffre = Nombre de chiffre total (partie entière + partie décimale) TailleData = Nombre d'octet (<= 32Ko sur AS) LenDec = Nombre de chiffre dans la partie décimale Format = Taille, Type AS/400, Décimal, Fonction


01/09/2003 23:16:00 /42

4.6 Écran du projet Ce paragraphe regroupe les captures d’écrans des fenêtres qui composent actuellement mon projet. — Certaines images sont découpées pour les réduire. — 4.6.1 DDSBLD C’est la fenêtre principale du projet ; elle est la seule à contenir des menus.


01/09/2003 23:16:00 /42

4.6.2 MireConnexion C’est la fenêtre qui permet de renseigner les informations de connexion.

4.6.3 Selection_Fichier Permet la sélection des fichiers d’une analyse.


01/09/2003 23:16:00 /42

4.6.4 Config Regroupe le paramétrage global.

4.6.5 Fen_Confirmer Cette fenêtre permettra de confirmer l’écrasement d’une source DDS.


01/09/2003 23:16:00 /42

4.7 Structure des Mémos AS/400 avec explication Lorsqu’un fichier de données utilise une rubrique WinDev du type mémo, le constructeur DDS génère un fichier supplémentaire qui mémorise les données par paquet (un peu comme le fait une disquette) dans la forme standard reconnue par le produit Easycom. Ce fichier mémo est un fichier PF de nom NomPF[8]+'__', où NomPF est le nom du fichier de données (physique) associé. Il n’existe qu'un seul fichier mémo par physique car sa structure l'identifie (numéro de mémo). Voici un exemple pour un fichier de données nommé « Aliment ». ALIMENT (PF) A* DDSBLD : FICHIER 'ALIMENT ' DE L Analyse HyperFile '...Mon_Analyse_1.w A R RALIMENT A IDALIMENT 9P 0B COLHDG('Identifiant de' 'Aliment') TEXT('HFTYPE=28') A NOM 30A B COLHDG('Nom') TEXT('HFTYPE=2') A INFOGENERA 18P 0B COLHDG('Mémo texte') ALIAS(INFOGENERAL) TEXT('HFTYPE=15') A PREPARATIO 18P 0B COLHDG('Mémo binaire') ALIAS(PREPARATIONCULINAIRE) TEXT('HFTYPE=18') ALIMENT__ (PF) A* DDSBLD : MEMO DU FICHIER HYPERFILE 'ALIMENT ' A UNIQUE A R RALIMENT A IDMEMO 18P 0B COLHDG('NUMERO DU MÉMO') A IDBLOC 4P 0B COLHDG('NUMERO DE BLOC') A TAILLE 18P 0B COLHDG('TAILLE TOTALE') A DONNEE 512H B VARLEN COLHDG('DONNÉES') A K IDMEMO A K IDBLOC WinDev déclare dans son aide qu’une rubrique « mémo » indexe sur 8 octets. Easycom accède aux rubriques du fichier mémo (ici ALIMENT__) par leur nom, permettant une liberté dans la définition de leur format. Dans cet exemple, chaque mémo peu contenir 4×512 = 2048 caractères. La taille de tous les champs est paramétrable. Remarque : pour une rubrique WinDev, la taille maximale d'une rubrique mémo (texte ou binaire) ne peut atteindre que 4 Go. Le type de données d’un mémo WinDev peut être texte ou numérique. Les seuls types AS/400 permettant de coder dans une grande taille sont Alpha et Hexa. Ainsi, la déclaration DDS de la rubrique « DONNEE » sera alpha (A) ou hexadécimale (H).


01/09/2003 23:16:00 /42

4.8 Méthode 1/2 en WinDev // Retourne un nom système (10 caractères) possible en fonction de la chaîne donnée // La validation des caractères AS est effectuée en premier // Le nom est généré sur texte avec espace et récupère successivement le 1er caractère du 1er mot, // les 2 premiers du secondes, le 1 du 3ième, les 2 du 4ième ... Complété à 10 avec le dernier mot. // // "Méthode" spécifie le procédé de création du nom // 1;2 sans liaisons (espace) ; supprime les mots de liaisons (un, des, les, la, le, de, du...) // 1;2 sur "_" ; consiste à remplacé les "_" par des espaces ; puis trait en espace // 1;2 sur Capitales ; recherche les lettres capitales et place un espace devant ; puis trait en espace //constante, voir en début de code // SepEsp = " " // Séparateur espace // SepUnd = "_" // Séparateur caractère de soulignement UnderScore // MotLiaison = "un des les la le de du pour par" // Mot de liaison détectable // nsParMot = 0x00 // Traitement NomSystemAS Par Mot en 1;2 // nsSansLiaison = 0x01 // en supprimant les mots de liaisons // nsUnderscore = 0x02 // avec Undersore comme séparateur de mots // nsCapitale = 0x04 // avec Capitales comme séparateur de mots // nsTous = 0x0F // Traitement avec toutes les méthodes intégrées FONCTION NomSystemAS(LOCAL Txt est une chaîne, LOCAL methode = nsTous, RemplirEspace=Faux) LOCAL StNomSys est une chaîne = "" // Chaîne générée qui sera retourné RgMot est un entier // Scanne la chaîne par mot RgCar est un entier // Scanne la chaîne caractère par caractère StTmp est une chaîne = "" // Récupère le traitement en cours StMot est une chaîne = "" // Récupère le mot en traitement StResteMot est une chaîne = "" // Mémorise le reste du mot (pour compléter) CarTmp est un caractère // Récupère le caractère en cours CarOld est un caractère // Mémorise le caractère précédent NbCar est un entier // Nombre de caractère utile (pour l'assemble des mots) StNomSys=AnsiVersAS(Txt,cAvecBlanc+cNomSystem) // Filtre les caractères AS invalider //--- sur capitale, metre des espaces SI ETBinaire(methode, nsCapitale) ALORS StTmp = "" // Chaîne de réception du traitement initialisée CarOld=SepEsp // Pas de caractère précédent POUR RgCar = 1 A Taille(StNomSys) // Scanne toute la chaîne CarTmp = Milieu(StNomSys,RgCar,1) SI Majuscule(CarTmp)=CarTmp ET CarTmp<>SepEsp ... // Majuscule ET CarOld<>SepEsp ALORS StTmp+=SepEsp // Place un séparateur StTmp+=CarTmp CarOld = CarTmp // Mémorise l'ancien, évite les doubles espaces FIN StNomSys = SansEspace(StTmp) FIN //--- sur "_", remplacer "_" en " " SI ETBinaire(methode, nsUnderscore) ALORS StNomSys = Remplace(StNomSys, SepUnd, SepEsp, SansCasse) // "_", " " FIN


01/09/2003 23:16:00 /42

//--- sans mot de liaison SI ETBinaire(methode, nsSansLiaison) ALORS StTmp = "" // Chaîne de réception du traitement initialisée RgMot = 1 StMot = ExtraitChaîne(StNomSys,RgMot,SepEsp) // Premier mot TANTQUE StMot<>EOT // Scanne toute la chaîne // recherche dans mot de liaison s'il existe RgCar = Position(MotLiaison, StMot,1, MotComplet+SansCasse) SI RgCar=0 ALORS StTmp +=StMot+SepEsp // Non ? conserver le mot RgMot++ StMot = ExtraitChaîne(StNomSys,RgMot,SepEsp) // Mot suivant FIN StNomSys = SansEspace(StTmp) FIN //--- Assemble les mots en 1;2 StTmp = "" // Chaîne de réception du traitement initialisée RgMot=1 StMot = ExtraitChaîne(StNomSys,RgMot,SepEsp) // Premier mot TANTQUE StMot<>EOT // Scanne toute la chaîne StMot = Minuscule(StMot) // Le mot en minuscule StMot[[1]]=Majuscule(StMot[[1]]) // Premier caractère en majuscule NbCar = 2 - ETBinaire(RgMot,1) // ################### paire=0 donc 2 caractères // Méthode codée en dure, pourrait être paramétrable StTmp+=Gauche(StMot,NbCar) // Extraction de caractères StResteMot=Milieu(StMot,NbCar+1) // Reste du mot RgMot++ StMot = ExtraitChaîne(StNomSys,RgMot,SepEsp) // Mot suivant FIN StNomSys = SansEspace(StTmp+StResteMot) //--- 10 caractères en capitale complétée d'espace StNomSys = Complète(StNomSys,10,SepEsp) // Retourne 10 caractères SI PAS RemplirEspace ALORS StNomSys=SansEspace(StNomSys) RENVOYER StNomSys