La webisation en pratique

Un exemple de webisation : DISTRILOG

DISTRILOG est une application de distribution, d’approvisionnement et de logistique pour des véhicules neufs.
Infotel a réalisé la webisation de cette application et partage cette expérience.

L’objectif

DISTRILOG est une application développée en Cobol/CICS, dont la webisation est motivée par :

• une volonté de déployer plus largement l’application, notamment à l’étranger (les mainframe utilisent un réseau spécialisé de terminaux)
• une ergonomie conviviale rendant l’application plus pratique et facile à appréhender
• la gestion automatique du multilinguisme

Cette stratégie définit plusieurs axes que doit respecter le projet :

• conserver la localisation des données et traitements
• ouvrir l’interface de l’application au navigateur
• offrir des prises de services sur les données et traitements

L’intégration d’Info-Wink

L’architecture existante

10 000 utilisateurs accèdent à cette application comprenant 250 écrans.
L’affichage est géré en 15 langues.

L’architecture mise en place par Infotel

Webisation

Les fichiers BMS sont utilisés pour générer les JSP et les fichiers XML.
Il y a autant de BMS que de langues gérées , durant la génération des JSP, les intitulés sont extraits dans toutes les langues de manière à n’avoir qu’une seule JSP multilangue par écran.

1.- Envoi d’un code transaction à CICS.
2.- Réception du message d’entrée du 1er écran de la transaction.
3.- Décodage du message d’entrée à l’aide du masque XML d’entrée, instanciation du bean grâce au message décodé, et passage du nom de l’écran demandé par CICS au contrôleur.
4.- Détermination de la JSP à afficher.
5.- Envoi de la page JSP au navigateur.
6.- Validation de la page JSP par l’utilisateur.
7.- Mise à jour des attributs du bean.
8.- Encodage du message de sortie à l’aide du masque XML de sortie.
9.- Envoi du message de sortie à CICS.

Amélioration des écrans

Pour élaborer la charte graphique, Infotel prend en compte les recommandations techniques et définit les règles de constitution des écrans, des polices de caractère à la taille des images.
La charte graphique mise en place respecte les chartes Internet/Intranet du client. Le positionnement des informations est identique au 3270 et la mise en forme des pages est gérée par une feuille de style.

Des objets Web sont ajoutés : calendrier, listes déroulantes, check box… mais également des fonctionnalités plus spécifiques :

• l’aide à la saisie : L’objectif de cette fonctionnalité est de faciliter la saisie de données pour un utilisateur. Un clic sur un bouton d’aide à la saisie permet d’ouvrir une fenêtre. Celle-ci contient des informations utiles pour saisir une information dans un champ. Le texte de l’aide provient d’une transaction mainframe et est fonction des informations remplies par l’utilisateur dans la page.
• le menu contextuel : Celui-ci contient sous la forme de liens Web, les informations de navigation pour un écran donné.
  Les liens associés à ces menus sont générés dynamiquement via l’appel d’une transaction CICS aveugle qui renvoie les occurrences associés à la liste.

Intégration des normes de sécurité

Info-Wink utilise l’API d’accès à l’annuaire LDAP fournie par le client. Elle fournit les classes et les méthodes nécessaires à l-authentification des utilisateurs et à la récupération de leurs groupes.
Info-Wink intègre donc l’ensemble des normes de sécurité du système.

Ce principe assure une sécurité complète dans des environnements hétérogènes.

La démarche de webisation

La démarche de webisation suit six étapes :

• Déterminer le périmètre à webiser
• Aider à l’expression des besoins utilisateurs
• Intégrer le framework Info-Wink dans le système d’information existant
• Générer les ressources Web
• Enrichir les écrans grâce à Info-Wink Editor
• Déployer l’application

1 - Déterminer le périmètre à webiser

Cette étape consiste à définir de manière précise le périmètre de l’opération.
D’une part, déterminer la charge de webisation :

• le nombre d’applications à webiser
• le nombre d’écrans à afficher

La charge de réalisation est ainsi estimée.

Dans un second temps, évaluer la charge de l’application :

• le nombre d’utilisateurs
• le nombre de transactions par seconde
• le taux d’utilisation de l’application

Ces informations aideront à définir l’architecture à mettre en place.

2 - Aider à l’expression des besoins utilisateurs

Une fois les fonctionnalités de la solution Info-Wink présentées, les utilisateurs spécifient leurs besoins fonctionnels, et déterminent plus particulièrement l’IHM souhaitée et les différents profils utilisateurs avec leur spécificité (les droits d’accès à l’application, les aspects visuels des écrans, les langues et les monnaies… ).

La ou les chartes graphiques ainsi que les objets Web à intégrer aux écrans sont définis lors de cette phase.

3 - Intégrer le framework Info-Wink dans le système d’information existant

Développer les composants logiciels spécifiques :

• objets Web sur mesure
• intégration du système de sécurité client

4 - Générer les ressources Web

Les fichiers de description des écrans JSP et de description des données dynamiques XML sont générés à partir des fichiers BMS (pour un projet CICS) et MFS (pour un projet IMS).

Les fichiers XML ne demandent aucune modification ultérieure dans le cadre de la webisation (si l’application évolue, les fichiers XML sont susceptibles d’être modifiés).
Les fichiers JSP peuvent demander une modification manuelle afin d’améliorer l’ergonomie des pages affichées.
Info-Wink Editor répond alors à cette problématique.

5 - Enrichir les écrans grâce à Info-Wink Editor

Une fois l’application webisée, les écrans peuvent être enrichis par Info-Wink Editor, pour :

• améliorer la mise en page finale des écrans
• gérer le multilinguisme
• ajouter des écrans many to one
• créer des Web services

6 - Déployer l’application

Le déploiement de l’application constitue la dernière étape dans la démarche de webisation.

Il s’agit de rassembler les composants logiciels spécifiques, le framework Info-Wink et les ressources générées à partir d’Info-Wink Editor (many to one, multilinguisme, Web services…).

Une série de tests est ensuite effectuée pour vérifier :

• la stabilité et la cohérence des interfaces et interactions de l’application
• la fiabilité et la performance de l’ensemble du système
• la sécurité, l’utilisation des ressources et les performances

Si les tests donnent toute satisfaction, l’application est livrée au client.