Formation Web Services

Adonix

www.adonix.fr
 Sommaire
 1. Présentation

 2. Principe de fonctionnement

 3. Installation & configuration

 4. Mise en œuvre

 5. Intégration dans l’application cliente

www.adonix.fr Groupe ADONIX // 2

 Formation Web Services
Adonix
1. Présentation

1.1. Généralités sur les services web

1.2. Les services web ADONIX

1.3. Méthodes des services web ADONIX

1.3.1. Le Service Web Objet

1.3.2. Le Service Web Sous programme
1.3.3. Le Service Web Liste
1.3.4. Méthode commune
www.adonix.fr
1.1 Généralités sur les services web

 Qu’est-ce qu’un service web ?

• Un service web est une technologie qui permet à une application

de s’ouvrir vers l’extérieur pour proposer des fonctionnalités à
d’autres applications, en dialoguant à distance via Internet. Ceci,
indépendamment des plates-formes et des langages sur
lesquelles elles reposent.

• Chaque service web propose un ensemble de fonctionnalités (leur

savoir-faire) appelé méthodes.

• Les services Web s'appuient sur un ensemble de protocoles

(SOAP) standardisant les échanges.

• La technologie des Services Web est aujourd'hui de plus en plus

incontournable, cette technologie englobe de nombreux concepts
et tend à s'imposer comme le nouveau standard en terme
d'intégration et d'échanges B2B et B2C.

www.adonix.fr Groupe ADONIX // 4

1.2 Les Services web ADONIX

 Les services web adonix repose sur des standards définis et non
sur un protocole propriétaire. Ils remplacent la version ADAPI de
la V130. Ils permettent à d’autres application de communiquer
avec X3.

 Ces applications peuvent couvrir de nombreux domaines :

 Site Internet E-Commerce
 Application métier
 Application commerciale déportée de type terrain
…

 Chacune des ces applications ont des points communs :

 Un fort besoin d’interactivité avec l’ERP :
 Mise à disposition d’informations « up to date »
 Mise à jour de l’ERP en temps réel
 Une sécurité accrue
 Pas de fichier ASCII transitant sur des disques durs

www.adonix.fr Groupe ADONIX // 5

1.3 Méthodes des services web ADONIX

 Les services web adonix sont au nombre de trois :

1. Service Web Objet : permet d’accéder à X3 via les

objets « métier » du progiciel.

2. Service Web Sous Programme : permet l’exécution de

programmes développés dans X3.

3. Service Web Liste : permet la consultation

d’informations basées sur le paramétrage des objets
« métier »
(liste gauche des objets).

www.adonix.fr Groupe ADONIX // 6

1.3.1 Le Service Web Objet / Description

 Le Service Web Objet permet d’accéder aux objets « métier »

du progiciel. Tels que :

 Commandes de ventes
 Articles
 Clients
 … Tout objet X3 est éligible

 L’objet des commandes de vente est le seul certifié par

Adonix comme étant totalement compatible avec ce mode
d’utilisation.
 Les autres objets sont adaptables à la demande. La contrainte
principale est que l’ensemble des informations saisies doivent
l’être dans la fenêtre principale de l’objet, aucune ouverture
complémentaire de fenêtre n’est possible.
 Ce service WEB est unique quelque soit l’objet utilisé, il
sera toujours disponible même si l’objet évolue ( patch,
changement de version … )

www.adonix.fr Groupe ADONIX // 7

1.3.1 Le Service Web Objet /Méthodes

 Voici les méthodes proposées dans ce service WEB.

1. Lecture d’enregistrements : read(objet,clé)

 On demande à X3 de lire un enregistrement, on donne la ou les
valeurs de clé. Cela revient à consulter une fiche dans une gestion
objet, l’enregistrement n’est cependant pas verrouillé.
 X3 nous répond en nous donnant les valeurs de l’ensemble des
champs des écrans de l’objet concerné.

2. Création d’enregistrements : save(objet,flux)

 On demande à X3 de créer un enregistrement, on lui transmet tous
les champs nécessaires ainsi que ceux rendus obligatoires dans les
écrans. L’ensemble des contrôles applicatifs sont déclenchés. C’est
l’équivalent du bouton créer de la gestion objet.
 X3 nous répond en nous donnant la valeurs de tous les champs des
écrans et les messages d’erreurs éventuels, on sait si la création a
été effectuée ou non.

www.adonix.fr Groupe ADONIX // 8

1.3.1 Le Service Web Objet /Méthodes

3. Suppression d’enregistrements : delete(objet,clé)

 On demande à X3 de supprimer un enregistrement, on lui transmet
les valeurs de clés. L’ensemble des contrôles applicatifs est
déclenché. C’est l’équivalent du bouton supprimer de la gestion objet
 X3 nous répond en nous donnant les messages d’erreurs éventuels,
on sait si la suppression a été effectuée ou non.

4. Mise à jour d’enregistrements : modify(objet,clé,flux)

 On transmet à X3 les valeurs de clé ainsi que les champs devant être
mis à jour.
 X3 effectue la mise à jour nous répond en nous donnant les
messages d’erreurs éventuels. Les tables annexes sont mise à jours.
C’est l’équivalent du bouton enregistrer de la gestion objet.

5. Exécution d’option : actionObject(objet,option,flux)

 On va demander à X3 d’effectuer une fonction liée à un menu ou un
bouton ajouté à un objet. Par ce biais on peut exécuter une tâche
particulière comme valoriser la commande sans la créer.
 X3 nous répond en nous donnant le contenu de chaque champ de
l’écran de l’objet concerné.

www.adonix.fr Groupe ADONIX // 9

1.3.2 Le Service Web Sous Programme /
Description
 Le Service Web Sous Programme permet d’exécuter des
traitements L4G
 Ex :
 Demander un prix
 Obtenir la photo d’un produit
 Interroger le stock
 Mettre à jour des réservations client …
 … Tout sous programme X3 est éligible

 Une fois la description du sous programme enregistré dans

le dictionnaire X3, celui – ci peut être déclenché dans X3
par ce web service.
 Un contrainte existe cependant : il ne doit pas nécessiter
l’intervention de l’utilisateur pour s’exécuter. Il doit être
autonome avec les paramètres transmis lors de son appel.

www.adonix.fr Groupe ADONIX // 10

1.3.2 Le Service Web Sous Programme /
Méthodes
 Ce service WEB propose la méthode runXml(sous
programme, flux des paramètres). Celle-ci demande
l’exécution d’un sous programme X3.
 Exemple sur une demande de tarif.

 On demande à X3 d’exécuter le sous programme « TARIF » en

transmettant le code de l’article, le code du client.
 X3 nous répond en nous transmettant tous les paramètres du sous
programme décrits dans le dictionnaire : code de l’article, code du
client et enfin le prix.
 Il ne reste plus qu’a exploiter ce prix dans l’application cliente

www.adonix.fr Groupe ADONIX // 11

1.3.3 Le Service Web Liste / Description

 Le Service Web Liste permet la consultation d’informations basées

sur le paramétrage des listes gauches.
 Ex :
 Demander la liste des commandes d’un client
 Demander la liste des articles d’une catégorie donnée

 Toutes les listes gauches des objets peuvent être interrogées par
ce service web.
 Les critères utilisés pour construire le filtre sont cependant limités
aux colonnes présentes dans le paramétrage de la liste gauche.
 La liste interrogée est la liste principale de l’objet, les autres
tiroirs ne sont pas disponibles.

www.adonix.fr Groupe ADONIX // 12

1.3.3 Le Service Web Liste / Méthodes

 Ce service WEB propose la méthode query(objet,clé,nombre

de lignes). Celle-ci interroge la liste gauche d’un objet dans
X3.
 Exemple sur la liste gauche des articles :

 On demande à X3 de nous donner le contenu de la liste gauche de

l’objet des articles. On lui transmet les critères d’interrogation de
cette liste :
 Article commençant par L : L*
 De la catégorie « fragile » : FRL
 X3 nous répond en nous transmettant un tableau avec toutes les
colonnes paramétrées dans la liste gauche dont les lignes
correspondent aux critères demandés.

www.adonix.fr Groupe ADONIX // 13

1.3.4 Méthode commune

 Chacun de ces trois service web propose une méthode particulière

 Il s’agit de la méthode GetDescription(objet ou sousprogramme)

 Cette méthode permet :
 De vérifier si un objet, une liste ou un programme a été publié
en mode WEB Service.
 De recharger la dernière version de la publication dans le
cache du serveur WEB
 D’obtenir un certains nombre d’information :
 Pour une liste, les noms et type des colonnes
 Pour un objet les noms et type des champs des écrans
 Pour un sous programme les nom et type des paramètres

www.adonix.fr Groupe ADONIX // 14

En résumé …

 Si l’on désire gérer des enregistrements dans X3, en tenant compte des
règles de gestion et des contrôles applicatifs.
 L’utilisation du service web objet est tout a fait indiqué.
 La contrainte essentielle est bien entendu que l’objet existe dans X3
et que celui-ci n’ouvre pas de fenêtre complémentaires.
 Aucun développement n’est à priori nécessaire dans X3, seule la
conformité de l’objet est a vérifier dans ce mode d’exploitation.

 Si l’on désire consulter des listes en tenant compte des restrictions liées
au paramétrage des habilitations utilisateurs et des rôles
 L’utilisation du service web liste est une des solutions possibles.
 Il y a deux contraintes :
 Les informations devant être consultées par l’application tierce
doivent être paramétrées dans préalablement dans X3.
 Et celle-ci doivent exister sous la forme d’un objet
 Un nouvel objet peut cependant être créé uniquement pour sa liste
gauche

www.adonix.fr Groupe ADONIX // 15

En résumé …

 Si l’on désire exécuter des tâches particulières n’étant pas

disponibles sous la forme d’objet dans X3
 Le service web sous-programme est le seul permettant de
répondre cette demande.
 La contrainte principale est que le sous programme doit être
autonome ( pas d’interaction avec l’utilisateur )
 Et bien entendu qu’il soit décrit dans le dictionnaire X3

www.adonix.fr Groupe ADONIX // 16

 Formation Web Services
Adonix

2. Principe de fonctionnement
2.1. Architecture de la solution ADONIX & connexion cliente
2.2. Zoom sur le serveur WEB
2.3. Traitement d’une requête web / service
2.4. Fonctionnement du pool de connexion

www.adonix.fr
2. Principe de fonctionnement

Notion de « solution »
 Avec la 140 est arrivé la notion de solution, les web services sont liés a ce nouveau
concept :

 Une installation Adonix comprend un et un seul dossier mère et n dossiers fils qui
héritent des éléments définis dans les dossiers de niveau supérieur selon les
règles de propagation Adonix.
 Chaque dossier de l’arborescence possède des tables dans la base de données et
un ensemble de répertoires sur disque. Il est possible de localiser les éléments
sur disque sous différentes racines en utilisant le concept d’adxvolume.
 Pour chaque installation le nom de dossier est discriminant, mais il est possible
d’avoir sur la même machine (ou sur des machines différentes) des installations
différentes comportant des dossiers de même nom que l’on souhaite publier sur
le même serveur Web.
 Il convient donc de différencier ces éléments en caractérisant chaque
« installation ».
 Une installation prend pour nom une solution Adonix et est caractérisée par un
code alphanumérique défini au niveau de la console.
 Ce code est stocké dans le fichier de configuration solution.xml qui se trouve au
dessus du répertoire racine du dossier mère (classiquement dans le répertoire
DOSSIERS sur une installation Windows)

www.adonix.fr Groupe ADONIX // 18

2.1 Architecture solution Adonix &
connexion cliente
Solution
Adonix
Serveur de Serveur Serveur d’application
données Serveur(s) de
connexion X3
Base oracle / sql

X3
DEMO
Dossiers
…

Connexion
cliente Serveurs
Client lourd complémentaire
s

Client
légers

Serveur Serveur
Client WEB
W/S d’édition

www.adonix.fr Groupe ADONIX // 19

2.2 Zoom sur le serveur WEB
Serveur WEB X3
Conteneur de servlets

Servlets
Serveur de cache
Serveur de session
Connexion sur X3
Serveur de connexion
Tomcat Serveur de web service

Pool de connexion

Sérialisation XML
Dé sérialisation XML Connexion
application tierce

Serveur HTTP
Apach
e

www.adonix.fr Groupe ADONIX // 20

2.3 Traitement d’une requête Web
Service
Serveur d’application X3 Protocole Adonix Serveur
WEB
3
5 Pool de connexion
4
1. L’internaute demande une page du site
2. Le site web invoque le service WEB X3
H
3. Le serveur WEB X3 contacte le serveur X3
T
4. Le serveur X3 exécute le traitement 2 6 T
5. Le serveur X3 donne le résultat au serveur WEB X3 P
6. Le serveur WEB transmet la demande au site WEB
7. Le site WEB actualise la page et la transmet à l’internaute
Internaut
es 1 7
1
Internet / 7
Intranet

Site WEB

www.adonix.fr Groupe ADONIX // 21

2.4 Traitement d’une requête Web
Service détail des échanges
1. L’internaute demande une page du site
• Il demande une page dans laquelle il y a une interaction avec X3 ( création d’une commande,
consultation d’un tarif … )
2. Le site web invoque le service WEB X3
• Pour répondre à la demande de l’internaute, il faut dans le code du site WEB avoir au
préalable intégré un des services WEB X3, on l’invoque en faisant varier les paramètres des
méthodes qu’il contient.
• L’invoquer reviens à construire le message SOAP et le mettre dans une requête HTTP à
destination du serveur WEB X3
3. Le serveur WEB X3 contacte le serveur X3
• Le serveur WEB X3 décode le message et le met sous une forme compréhensible par le
serveur X3, il lui transmet l’information via l’une des connexions déjà établie.
4. Le serveur X3 exécute le traitement
• Le serveur X3 exécute un programme wrapper qui se charge de garnir les champs des écrans
et de déclencher le scénario objet ou d’exécuter le programme demandé
5. Le serveur X3 donne le résultat au serveur WEB X3
• Pour le serveur X3 il n’y a pas de différence entre une connexion de ce type et une connexion
de type client/serveur classique, il dialogue avec le serveur WEB comme il le fait avec le
client graphique X3.
6. Le serveur WEB transmet la demande au site WEB
• Le serveur WEB encode la réponse d’X3 pour la mettre sous la forme d’un message SOAP
• Le message SOAP est encapsulé dans une requête HTTP et envoyé au site WEB
7. Le site WEB actualise la page et la transmet à l’internaute

www.adonix.fr Groupe ADONIX // 22

2.5 Fonctionnement du pool de connexion
 Le pool de connexion est le système qui permet :
• D’établir les connexions sur le serveur X3
• De gérer les files d’attentes des demandes

Étape 1 - Démarrage du pool de connexion

• Soit automatique lors du démarrage du serveur WEB
• Soit par une demande de démarrage explicite

Serveur WEB
X3
Serveur Pool de
X3 connexion
Entrée APP
Dossier APP

Dossier TEST Entrée TEST

Dans cet exemple le pool de connexion démarre et lance 4 sessions sur le serveur X3
sur le dossier APP et 1 sur le dossier TEST.
Au total 5 licences de type web service sont consommées

www.adonix.fr Groupe ADONIX // 23

2.5 Fonctionnement du pool de connexion

Étape 2 – Le pool est sollicité, une ou plusieurs requêtes sont arrivées

Serveur Serveur de web Site WEB

X3 3 service
Pool de connexion 1
Requête 1
Requête 1
Requête 2
Requête 2
Requête 3
2 Requête 4
Requête 5

Requête 3
Requête 4
Requête 5

1. Plusieurs requêtes arrivent en même temps du site web

2. Le pool de connexion va distribuer les requêtes selon les connexions disponibles
• Si aucune connexion n’est disponible le pool empile la requête
• Les requêtes sont dépilées (FIFO) au fur et à mesure de la disponibilité des connexions
3. Le serveur WEB X3 utilise une des connexions pour traiter la demande
• Le nombre de connexion dépend du paramétrage du serveur de web service
• Et du nombre total de licence web service disponible sur le serveur X3
www.adonix.fr Groupe ADONIX // 24
 Formation Web Services
Adonix
3. Installation & configuration
3.1. Installation du serveur
3.2. Configuration du serveur
3.3. La page technique du serveur de web service

www.adonix.fr Groupe ADONIX // 25

3 Installation & configuration

Le serveur de web service est une des applications du serveur WEB X3

(servlet), il faut donc que le serveur WEB X3 soit préalablement installé.
Son installation consiste à :
• Sur le serveur Web Adonix
• Installation des composants freeware
 Java Software Development Kit version 1.4.2_03
 Apache Tomcat version 4.1.27
 Apache HTTP Server version 2.0.48

• Dépose de l’application Web 140

• Sur le serveur d’application X3
• Installation Apache HTTP Server version 2.0.48
• Configuration à faire depuis la Console
 Publication de la solution
 Déclarez le nom de l’Alias de la solution à publier
 Spécifiez le chemin d’installation du serveur HTTP installé sur le
serveur d’application X3
 Configuration du serveur Web

www.adonix.fr Groupe ADONIX // 26

3.1 Installation du serveur

 Une fois le serveur WEB installé

 Si le dossier était déjà accessible en mode WEB il faudra juste
s’assurer de sa version.
 Il faut publier les différents dossiers, en configurant le serveur WEB
 Cette opération est à réaliser en utilisant la console ( cf. cours
installation )
 Version minimum pour utiliser les web services
 Applicatif X3 :Version 143 Liste de patch N°11
 Serveur WEB : 14W20
 Runtime X3 : 14R318
 Console : 14S25

 Licence Web service

 Le décompte des licences se fait séparément
des sessions primaires

www.adonix.fr Groupe ADONIX // 27

3.2 Configuration du serveur

Le serveur de web service doit être au préalable configuré pour être

utilisé, cette opération est a réaliser depuis la console de configuration

La console de configuration

 Le concept de déposez – cliquez

 Paramétrage facilité des composants Raccourci
bureau
 Assemblage et administration centralisés et simplifiés
 d’une architecture intégrée (un portable par exemple)
 à une architecture multi-tiers élaborée

www.adonix.fr Groupe ADONIX // 28

3.2 Configuration du serveur

1 Lancer la console de configuration et choisir « Serveurs WEB »

2 Choisir le serveur concerné

3 Choisir la solutions concernée

4 Cliquer sur l’onglet « Webservice »

5 Choisir le dossier sur lequel les web services seront utilisés

www.adonix.fr Groupe ADONIX // 29

3.2 Configuration du serveur

6 Cliquer sur « + » pour ajouter un nouveau groupe de

connexion

Alias : Nom donné au groupe de connexion

7 Renseigner les paramètres suivants :
Libellé : Intitulé du groupe de connexion
Langue : Code langue X3 utilisé pour le démarrage du groupe
Utilisateur Adonix : Code user X3 utilisé pour le démarrage du grou
Mot de passe Adonix : Mot de passe user X3 utilisé pour le démarrage du gr
Utilisateur système : Code de l’utilisateur réseau ( compte window
Mot de passe système : Mot de passe du user réseau
Taille du groupe : Nombre de connexion simultanée maximum pos
Taille initiale du groupe : Nombre de connexion ouverte dès le démarrage d
Connexion automatique : Démarrage automatique du groupe de
connexion
Entrée réservée : Obligation de signer chaque requête

8 Cliquer sur Enregistrer, la console configure le serveur de WEB

www.adonix.fr service Groupe ADONIX // 30
3.3 La page technique du serveur

Pour vérifier que le serveur de web service est opérationnel, il faut :

 ouvrir la page technique avec l’url :http://localhost:1898
 et cliquer sur l’onglet Serveur de Web Service
 Une page comme celle ci doit apparaître :

www.adonix.fr Groupe ADONIX // 31

 3.3 La page technique du serveur

Le démarrage des groupes d’entrées peut se faire depuis cette page …

Mais le verrouillage et le
redémarrage du groupe
ne peuvent se faire que
depuis la console
… ou depuis la console
www.adonix.fr Groupe ADONIX // 32
3.3 La page technique du serveur

Identification du numéro de
processus adonix Gestionnaire des
tâches
sur le serveur X3

Identification session W

Nombre total de licence

WEB service
Nombre total de
licences
Web Service
consommées
Etat du groupe de
connexion

Etat du pool de
connexion

www.adonix.fr Groupe ADONIX // 33

Web Services Adonix
4. Mise en oeuvre
4.1. La modélisation dans X3
4.1.1. Modélisation des sous-programmes
4.1.2. Modélisation des objets

4.2. Publication des WEB services

4.2.1. Le générateur de WEB services
4.2.2. Description XML générée
4.2.3. Règles de génération

4.3. Gestion de la cohérence

4.4. La mise au point
4.4.1. Règles de développement
4.4.2. Tests avec l’applicatif
4.4.3. Tests avec le serveur web
4.4.4. Testeur java
4.4.5. Debugger les web services

4.5. Les tests de charge

www.adonix.fr Groupe ADONIX // 34
4.1 La modélisation dans X3

Pour utiliser des fonctions d’X3 dans le mode web services, il faut au
préalable que ces fonctions soit modélisées.
Les modèles compatibles avec les web service sont :
 Les sous-programmes
 Les objets
 Celui-ci permet l’utilisation des services web Objet et Liste
 Ce modèle permet d’être indépendant du mode d’utilisation :
 Client windows
 Client Internet explorer
 Import de données
 Web Service

www.adonix.fr Groupe ADONIX // 35

4.1.1 Modélisation des sous-programmes

Case à cocher
WEB service :
Indique que le
sous programme
est utilisable dans ce mode

La description est stockée dans un dictionnaire :

• Nom du traitement
• Nom du sous programme
• Nom, type et longueur de chaque paramètre
Les paramètres peuvent être passés par valeur ou par adresse
Si ils sont passés par adresse X3 peut transmettre des informations à l’application tierce
www.adonix.fr Groupe ADONIX // 36
4.1.1 Modélisation des sous-programmes

Les informations gérées

 Les sous-programmes destinés à être publiés sous forme de Web

services sont cochés « Web ».
 Les variables définissant l’interface du sous-programme sont
automatiquement retrouvées dans le sous-programme
 Déclarer une variable par ligne dans le sous-programme pour
garantir la récupération automatique.
 Les informations successives de même cardinalité sont
automatiquement rassemblées dans le même groupe, sauf si on
leur associe des noms de groupe différents.
 La colonne longueur permet de dimensionner les variables de type
caractère, blob et clob, définissant ainsi une taille de réceptacle
pour les blob et clob. Ceci permet à l’application cliente d’effectuer
un contrôle supplémentaire.
 Un bouton « publication » permet de se débrancher directement sur
la fonction de publication.

www.adonix.fr Groupe ADONIX // 37

4.1.1 Modélisation des sous-programmes

La gestion des messages en sous-

programme

Des sous-programmes permettent de gérer de multiples messages pour

l’exécution des sous-programmes en web services (jusqu’à 50 messages)
 Call MESSAGE(MESSAGE) from GESECRAN Ajoute un message
d’information
 Call ADDMESSWARN(MESSAGE) from AWEB Ajoute un message
d’avertissement
 Call ERREUR(MESSAGE) from GESECRAN Ajoute un message d’erreur

Les messages sont transmis dans le flux XML de réponse et sont exploitables dans
l’application cliente.

www.adonix.fr Groupe ADONIX // 38

4.1.1 Modélisation des sous-programmes

Les limites

 50 variables au maximum pour un sous-programme, mais toutes les

variables peuvent être dimensionnées.
 La table de description des sous-programmes est une table système
(c’est la même pour tous les dossiers de la solution).
 50 messages maximum.
 Les programmes qui sont modélisés ne doivent pas ouvrir de
fenêtre pour faire saisir des informations à l’utilisateur. Il doit être
autonome avec les paramètres fournis.
 Toutes les instructions liées aux affichages sont à proscrire, en
revanche toutes les instructions de lecture et de mise à jour de la
base de données sont bien entendu disponibles.

www.adonix.fr Groupe ADONIX // 39

4.1.2 Modélisation des objets

 Les objets X3 sont bien entendu eux aussi stockés dans des
dictionnaires dans lesquels on retrouve :
 La description de la liste gauche
 La description de chacun des écrans qui le compose
 La description des options particulières
 La table principale à mettre à jour
 Les traitements L4G qui sont liés à cet objet
 Le dictionnaire n’est, à priori, pas à compléter. Si l’objet est disponible
en client/serveur il l’est aussi en mode web service. Cependant de
légères adaptation peuvent être nécessaire pour accéder aux écrans
de saisie complémentaires ( adresse dans la commande par
exemple ).
 L’objet est le modèle le plus couramment utilisé dans X3, les fonctions
qui n’ont pas été développées avec ce modèle sont en générale
encapsulable dans un sous programme à réaliser en spécifique.

www.adonix.fr Groupe ADONIX // 40

 4.1.2 Modélisation des objets
Mode d’affichage des champs
 Une zone peut être :
 Saisie
 Que ce soit en web service ou en C/S la zone sera transmise au client
 Affichée
 Que ce soit en web service ou en C/S la zone sera transmise au client
 Invisible
 En C/S la zone n’est jamais transmise au client, en web service cela
dépend du mode de publication ( zone invisible oui/non )
 Technique
 Que ce soit en web service ou en C/S la zone ne sera jamais transmise
au client

Les zones non transmises au client sont bien entendus

Disponible dans la classe [M]
Cela évite de grossir inutilement les flux client/serveur

www.adonix.fr Groupe ADONIX // 41

4.1.2 Modélisation des objets
Mode d’exécution des actions
 Une action peut être exécutée
 Interactive
 Action exécutée uniquement en C/S
 Toujours
 Que ce soit en web service ou en C/S l’action est exécutée
 Import / Web service
 Action exécutée uniquement en web service et en import

 Ne sont jamais exécutées :

 Les actions avant bouton
 Les actions BoutonN
 Les actions de sélection
 Clic sur une icône

www.adonix.fr Groupe ADONIX // 42

4.1.2 Modélisation des objets
Les différents types de connexions

 A la connexion dans toute application développée en technologie

Adonix on distingue les types de connexion suivants :
 Session primaire adxtyp=1 (C/S) ou 9 (Web)
 Session secondaire adxtyp=2 (C/S) ou 10 (Web)
 Batch adxtyp=3
 Terminal VT adxtyp=5
 Web service adxtyp=12

 En fonction des droits portés par la clé Adonix, la connexion est

autorisée ou non. En particulier le serveur de Web services ne
pourra pas démarrer si la clé n’autorise pas au moins 1 connexion.

 En mode Web service la variable globale numérique GWEBSERV est

égale à 2

www.adonix.fr Groupe ADONIX // 43

4.1.2 Modélisation des objets
Les écrans liste / détail

 Modélisés dans le dictionnaire (exemple adresses)

 Donnent lieu à une génération particulière, mais doivent respecter :
 une normalisation des noms de champs (nom champ
détail=« constante »+ nom champ invisible dans bloc tableau -
exemple XBPADES=« X »+BPADES)
 Le dernier champ de type numérique ( C ) et invisible du bloc détail
est considéré comme la variable de contrôle du numéro de ligne dans
le tableau et est initialisée en tant que telle par le programme
wrapper lors de l’appel de chaque ligne
 Seuls les champs du tableau sont exportés en XML. Les champs invisibles
du bloc tableau sont automatiquement ajoutés.
 Le programme de contrôle déverse les lignes du tableau dans le bloc
détail ligne par ligne et effectue les contrôles sur champ définis dans
l’écran
 Attention :
 les actions du tableau ne sont pas exécutées
 Il faut en cas d’action MODIFY, et de modification dans ce tableau,
charger la zone précisant le nombre de lignes du tableau (exemple
NBADR dans les adresses), faute de quoi c’est le plus grand numéro
de ligne indiqué qui est pris comme dimensionnement du tableau

www.adonix.fr Groupe ADONIX // 44

4.1.2 Modélisation des objets
Les écrans complémentaires

 Dans le dictionnaire Objet, il est possible de définir de 0 à 8 écrans

complémentaires avec une abréviation associée.
 Ces écrans vont être
 Pris en compte dans la structure XML produite lors de la
génération du Web service, comme des écrans de la fenêtre
 Ouverts par le programme automatique associé à la fenêtre
 Déclarés comme des onglets de la fenêtre lors de l’ouverture de
la fenêtre dans l’instruction Inpbox
 Chargés dans les variables du flux XML de réponse du Web
service
 Chargés via une instruction Saizo à partir des informations
envoyées par le Web service lors d’une action de CREATE ou
MODIFY
 L’applicatif devra assurer dans le contexte Web service
(GWEBSERV=2)
 Le chargement des masques complémentaires (étiquette lien)
 La mise à jour des tables à partir des masques lors de l’écriture

www.adonix.fr Groupe ADONIX // 45

4.1.2 Modélisation des objets
Les écrans complémentaires : exemple
 Une évolution a été faite pour illustrer le principe de fonctionnement
des écrans complémentaires. Elle concerne l’objet SOH.
 Cette évolution permet de récupérer en lecture/écriture :
 Les adresses de commande, livraison, facturation
 Les textes entête et pied de la commande
 Pour la mettre en œuvre il faut
 Récupérer le source SPESOH livré à titre d’exemple et soit le
mettre en ligne, soit inclure son contenu dans le SPESOH existant
 Définir 5 masques complémentaires comme suit dans l’objet SOH
 ADRBPC ADB1
 ADRBPC ADB2
 ADRBPC ADB3
 ACLOB ACL1
 ACLOB ACL2

www.adonix.fr Groupe ADONIX // 46

4.2 Publication des WEB services

 Une fois l’objet ou le sous programme décrit dans le dictionnaire, il faut

le publier.
 La publication permet de générer un flux XML décrivant l’objet ou le
sous programme.
 Ce flux sera utilisé ensuite par le serveur web pour décoder les
requêtes émanant de l’application tierce.
 Les web service X3 étant génériques, les éléments variables tels que
les noms des champs pour un objet ou les paramètres pour un sous
programme, sont passés sous la forme d’un flux XML, la structure de
celui-ci est déterminé par la description donnée dans le dictionnaire.
 La publication génère aussi un programme wrapper en L4G adonix
 Celui – ci constitue une interface entre le développement X3 et le
serveur de Web services. Il gère
 Les paramètres d’entête
 Les messages
 Le flux montant et descendant de données

 Les programmes wrapper sont appelés par le serveur de Web services

dont le rôle est de sérialiser / désérialiser le flux soap de / vers les
paramètres attendus.

www.adonix.fr Groupe ADONIX // 47

4.2.1 Le générateur de WEB services

Utilitaires / Divers / Génération Web services

www.adonix.fr Groupe ADONIX // 48

4.2.1 Le générateur de WEB services
Fonction de publication

 Cette fonction permet de publier des objets avec pour chacun le choix
 de la transaction (si cet objet a des variantes)
 de la publication ou non des champs invisibles (les champs de type
technique ne sont jamais publiés)
 Il est également possible :
 de choisir le nom de publication ( nom public de l’objet ou du sous
programme)
 de lister les éléments publiés
 de dé-publier des éléments précédemment générés
 de générer tous les Web services d’un dossier ( bouton publication
globale )
 Il est à noter que lorsqu’un nom de publication a été donné à un élément
(objet ou sous-programme), ce nom est systématiquement re-proposé lors
des générations suivantes. Il n’est pas possible de publier 2 fois le même
couple objet-variante avec deux noms différents, ni de publier un couple
objet-variante avec et sans les champs invisibles.

www.adonix.fr Groupe ADONIX // 49

4.2.1 Le générateur de WEB services
Fonction de publication

 Le programme de publication crée :

 une structure XML de nom « Nom de publication ».xml qui est
stockée dans le répertoire X3_PUB/ « Nom du
dossier »/GEN/ALL/WEBS
 un programme wrapper en L4G
 Avec chaque programme wrapper un programme de test automatique
est crée qui permet d’appeler un sous-programme publié et d’appeler un
objet par une des quatre méthodes proposées (lecture, création,
modification, suppression) et par la méthode liste.
 Les éléments générés sont horodatés et un contrôle est effectué par le
serveur de Web services avant tout appel à un programme wrapper pour
s’assurer que la version publiée et utilisée est bien la plus à jour.

www.adonix.fr Groupe ADONIX // 50

4.2.2 Description XML générée

Le fichier XML produit est écrit en codage UTF8, ce fichier XML peut être
demandé par l’application cliente ( méthode GetDescription ) qui peut
l’exploiter, pour générer des écrans par exemple.
L’entête du document est décrite dans le nœud ADXDOC.
Ses propriétés sont les suivantes :

www.adonix.fr Groupe ADONIX // 51

4.2.2 Description XML
générée
Nœud <ADXDOC>
Entête du fichier XML OBJET :
<ADXDOC PNA=“OBJSOH“ Nom de publication de l’objet
NAM="WOSOHSTD“ Nom de la fenêtre associée à l’élément
TIM="20060109111503" Horodatage de génération
OBJ="SOH" Nom de l’objet généré
TRA="STD" Nom de la transaction choisie
FOL="DEMOFRA" Nom du dossier
SOL=“SOLX3" Nom de la solution Adonix
WRP="WJSOHSTD" Nom du programme wrapper
USER="ADMIN" Utilisateur X3 ayant déclenché la génération
VER="3.20051028" Version du générateur
HEAD="1"> Version du protocole d’encapsulation

Entête du fichier XML Sous programme :

<ADXDOC PNA="STOCKSITE“ Nom de publication du sous programme
TIM="20060208121856„ Horodatage de génération
PRG="ZSTOCK" Nom du programme publié
SPG="STOCK" Nom du sous programme publié
FOL="DEMOFRA" Nom du dossier
SOL="SOLX3" Nom de la solution Adonix
USER="ADMIN" Utilisateur X3 ayant déclenché la génération
VER="3.20051028" Version du générateur
HEAD="1" Version du protocole d’encapsulation
WRP="WRSTOCKSITE" Nom du programme wrapper
C_FRA="Recherche de Stock"> Désignation du sous programme

www.adonix.fr Groupe ADONIX // 52

4.2.2 Description XML
générée
Nœud <GRP>
Le nœud GRP décrit soit un bloc d’écran soit un
groupe de paramètres d’un sous programme :

Exemple bloc de type liste :

<GRP NAM="SOH0_1" Code écran et numéro de bloc

TYB="List" Type de bloc (valeurs possibles : Table, List, Pict, Text, Hidden)
DIM="1"> Nombre de lignes maximum Toujours 1 dans les bloc de type liste

Exemple bloc tableau :

<GRP NAM="SOH4_1"
TYB="Table" Bloc de type tableau
DIM="200" Nombre de lignes maximum
IDTAB="SOH4~NBLIG" Code écran + variable de bas de tableau
OPT="IAD"> Option du bloc écran : Insertion, Annulation, Suppression

Exemple groupe de paramètres pour un sous programme :

<GRP
NAM="G1" nom du groupe dans le dictionnaire des sous programmes
DIM="1"> Nombre d’occurences des paramètres contenus dans ce groupe

www.adonix.fr Groupe ADONIX // 53

4.2.2 Description XML
générée
Nœud <FLD>
Le nœud FLD décrit soit un champ d’un écran soit
un paramètre d’un sous programme :
Description d’un champ d’un écran :

<FLD NAM="ORDSTA" Nom du champ

TYP="Integer" Type du champ ( integer, char, blob, clob,date, decimal )
MOD="Display" Mode d’affichage du champ ( input, display, hidden )
LEN="3" Longueur du champ, si le champ est menu local l’attribut LEN n’est pas décrit
DIM="2" Nombre d’occurrences du champ, si =1 l’attribut DIM n’est pas présent
MEN="415" Numéro du menu local
C_FRA="Devise" /> Intitulé du champ le nom de l’attribut est C_+code langue

Description d’un paramètre :

<FLD NAM="STOCK" Nom du paramètre

TYP="Decimal" Type du paramètre ( integer, char, blob, clob,date, decimal )
PAR="Adr" Mode de transmission du paramètre ( Adr : par adresse, Value : par valeur )
MOD="Input" Toujours input
C_FRA="Stock article" /> Désignation du paramètre

www.adonix.fr Groupe ADONIX // 54

4.2.2 Description XML générée
Nœuds <ADXKEY> <ADXMEN>
Le nœud ADXKEY décrit une liste gauche
<ADXKEY> Liste gauche
<GRP NAM="LEFTLIST" Attribut fixe
DIM="10000"> Attribut fixe
<FLD NAM="SOHNUM" Code du champ de la liste gauche
MOD="Display" Attribut fixe
TYP="Char" Attribut fixe
LEN="30" Attribut fixe
C_FRA="No commande" /> Intitulé de la colonne
</GRP>
</ADXKEY>

Le nœud ADXMEN décrit les menus locaux

<ADXMEN> Liste des menus locaux
<MNU NO="1"> Numéro du menu local
<VAL IND="1" C_FRA="Non" /> Numéro et désignation de l’item du menu local
<VAL IND="2" C_FRA="Oui" />
</MNU>
<ADXMEN>

www.adonix.fr Groupe ADONIX // 55

4.2.2 Description XML générée
Nœuds <ADXSER> <ADXREAD>
Le nœud ADXSER décrit les actions possibles sur un objet
<ADXSER> Liste des boutons et options disponibles
<MET ID="READ" C_FRA="Lire" /> L’attribut ID est fixe les intitulés sont par langue
<MET ID="CREATE" C_FRA="Créer" />
<MET ID="MODIFY" C_FRA="Modifier" />
<MET ID="DELETE" C_FRA="Supprimer" />
<MET ID="LIST" C_FRA="Liste" />
<MET ID="V" C_FRA="Valorisation" /> Option code « V » du dictionnaire des fenêtres
</ADXSER>

Le nœud ADXREAD donne le champ clé

<ADXREAD TAB="SORDER"> Nom de la table X3
<FLD NAM="SOHNUM" Code du champ clé
TYP="Char" Type du champ clé
LEN="15" Longueur du champ clé
C_FRA="No commande" /> Désignation du champ clé
</ADXREAD>

www.adonix.fr Groupe ADONIX // 56

4.2.3 Règles de génération

 Une fonction déjà publiée doit garder le nom initial de publication (si
on désire en changer, il faut la dépublier et relancer la publication)
 Les éléments publiés sont nativement multi-langue et la structure
XML est stockée dans le répertoire WEBS du dossier sous
X3_PUB/GEN/ALL
 Tous les éléments générés sont automatiquement horodatés,
mémorisent la version du générateur utilisé et le nom de
l’utilisateur X3 qui a lancé la génération (GUSER)
 La description d’un objet ou d’un sous programme indique que celui-
ci peux être utilisé par une une application tierce, en revanche rien
n’oblige à utiliser ce fichier dans l’application cliente.

www.adonix.fr Groupe ADONIX // 57

4.2.3 Règles de génération

 Si la description XML du Web service appelée n’est pas à jour, elle

sera automatiquement rafraîchie par le serveur de Web services qui
récupérera la nouvelle description XML et mettra à jour ses
structures.
 Pour forcer l’utilisation de la nouvelle version du programme
wrapper une instruction de flush mémoire adxmpr=adxmpr est
provoquée sur les différentes entrées du pool.
 Le serveur de Web services assure la sérialisation / désérialisation
des paramètres et la mise à jour des structures publiées
 Pour qu’un web service bénéficie de la modification d’un
programme L4G alors que celui-ci a déjà été exécuté, il faut
republier l’objet.
 L’utilisateur X3 web service ne doit pas avoir le serveur batch en
démarrage automatique à la connexion

www.adonix.fr Groupe ADONIX // 58

4.3 Gestion de la cohérence

 Lors de la lecture d’une fiche objet, si les champs UPDDAT, UPDTIM et

UPDUSR sont définis dans la table principale de l’objet ces
informations sont retournées dans le flux XML de réponse dans le
groupe ADXTEC
 WW_MODSTAMP Horodatage de la dernière mise à jour
 WW_MODUSER Code utilisateur X3 du dernier modifieur
 Lors de l’envoi d’un flux de données pour modification ou
suppression :
 Si et uniquement si la zone WW_MODSTAMP est valorisée (avec le
contenu obtenu lors de la lecture), le programme va contrôler si
l’enregistrement a été modifié depuis ce timestamp.
 Dans ce cas un message d’erreur sera envoyée donnant le
nouveau timestamp, et les modifications seront refusées avec le
message : « Enregistrement modifié depuis la dernière lecture » +
timestamp de la modification + utilisateur ayant modifié (si
disponible )

www.adonix.fr Groupe ADONIX // 59

4.4 La mise au point

 Une fois la modélisation terminée il faut tester

pour vérifier si les objets et les sous programmes
publiés sont bien compatibles avec le mode web
service.
 En standard seul l’objet des commandes de vente est
certifié.
 Pour les autres objets des test sont nécessaires, en
fonction des paramétrage propre à chaque dossier,
les objets peuvent réagir de manière différentes
(ouverture de fenêtre complémentaire … ) .
 Les objets complètement spécifiques sont eux aussi à
tester.
 Des règles de développement sont à respecter.

www.adonix.fr Groupe ADONIX // 60

4.4.1 Les règles de développement

Les contraintes principales sont liées à des problèmes

d’affichage :
 L’instruction infbox ne bloque pas le web service mais elle
ne ne permet pas de renvoyer un message à l’application
cliente
 L’utilisation de la syntaxe #@ pour accéder aux postes client
n’est pas compatible, attention aux imports silencieux !
 L’envoie de mail : instruction Send. Utiliser le meladx pour
faire un workflow serveur.
 Les éditions : instruction Report. Toujours utiliser avec un
serveur d’édition
 Interruption du programme par l’ouverture d’une fenêtre :
Call DIALWIN(W_OK,mess(113,188,1),"ACOPIE") From GESECRAN
N’est pas compatible en mode web service
 L’instruction inpbox hors modélisation objet est à proscrire

www.adonix.fr Groupe ADONIX // 61

4.4.2 Test avec l’applicatif

Programmes wrapper

 Ils sont générés lors de la publication d’un objet ou d’un sous

programme
 WJ »Nom d’objet » « nom de variante » pour les objets sans
publication des champs invisibles
 WJ « Nom d’objet » « nom de variante »_I pour les objets
avec publication des champs invisibles
 WR « Nom de publication » pour les sous-programmes

 Ils constituent une interface entre le développement X3 et le

serveur de Web services. Ils gèrent
 Les paramètres d’entête
 Les messages
 Le flux montant et descendant de données
 Les programmes wrapper sont appelés par le serveur de Web
services dont le rôle est de sérialiser / désérialiser le flux soap de /
vers les paramètres attendus.

www.adonix.fr Groupe ADONIX // 62

4.4.2 Test avec l’applicatif

Paramètres des programmes wrapper

 Les paramètres sont normalisés en variables d’entête et flux de données. Les variables
d’entête servent à contrôler les flux émis et reçus. Leur description est la suivante :
 WW_OK Integer Statut de retour 1=OK , 0=KO
 WW_ZONE Character Zone de sortie en cas d’erreur
 WW_STAT Integer Nombre de messages
 WW_GRAVE Integer(1..50) Gravité de message (1= Info, 2=Warning,
3=Bloquant)
 WW_MESS Character(1..50) Texte du message
 WW_ACTION Character Code action (ID de l’action à exécuter)
 WW_IDENT Character Identifiant (Cle1~Cle2~Cle3 …)
ou clé début, ou critères de sélection rapide si liste
 WW_NB Integer Nombre d’enregistrements à lire / retournés
 WW_HORDAT Character Horodatage de l’élément
 WW_TAB Character Identifiant de tableau (pour futures actions
SUPLIG at INSLIG)
 WW_PAR Character Identifiant de lignes (idem WW_TAB)
 WW_TRACE Clbfile Trace à renvoyer au serveur de Web
services.
Paramètres de mise en œuvre du debugger

www.adonix.fr Groupe ADONIX // 63

4.4.2 Test avec l’applicatif

Lors de l’appel d’un Web service, le serveur de Web service transmet au programme
wrapper l’horodatage de sa structure locale. Le serveur X3 vérifie si cet horodatage est
conforme à celui stocké sur le serveur. Si oui il répond à la requête, si non il renvoie une
erreur et le serveur de Web service envoie une requête technique pour récupérer la
dernière version.
La génération du programme wrapper est une des étapes de la génération du Web service.
A l’intérieur du programme wrapper on trouve un programme de test qui permet de valider
le fonctionnement de l’objet ou du sous-programme en mode Web service, en simulant
une exécution, sans avoir à tester depuis l’application tierce.
Le mode opératoire consiste à développer un programme de test spéparé du programme
wrapper, car toute modification de celui-ci sera perdue lors de la republication de l’objet.

www.adonix.fr Groupe ADONIX // 64

4.4.2 Test avec l’applicatif
Test liste gauche
###############################
## Test liste gauche
###############################
Call TEST_LISTE ( 10 ) # Nombre de lignes maximum Trace du résultat
End

Subprog TEST_LISTE(NBLISTE)
Value Integer NBLISTE
Call OUVRE_TRACE("") From LECFIC
Gosub DEFLISTE From WJSOHSTD
WW_ACTION="LIST" # Action liste gauche
WW_IDENT="~DIS001~~~~~~“# Critère : commande du
client DIS001
Gosub WEBLISTE From WJSOHSTD # Déclenchement de la
liste
Gosub ANALRESOBJ From WJSOHSTD # Analyse du résultat
For indice=1 To WW_NB
If indice=1
Call ECR_TRACE(mess(223,123,1),0) From GESECRAN
Call ECR_TRACE("----------",0) From GESECRAN
Endif
Call ECR_TRACE(num$(indice)+":"
& -WW_SEL1(indice)
& -WW_SEL2(indice)
& -WW_SEL3(indice)
& -WW_SEL4(indice)
& -WW_SEL5(indice)
& -WW_SEL6(indice)
& -WW_SEL7(indice),0) From GESECRAN # Affichage de
la liste
Next indice
Call ECR_TRACE("-----------------",0) From GESECRAN
Call FERME_TRACE From LECFIC
www.adonix.fr Groupe ADONIX // 65
4.4.2 Test avec l’applicatif
Test lecture objet
L’étiquette Gosub DETAILRES permet d’afficher dans une
trace :
Le statut global
l’enregistrement qui a été lu ou écrit (tous les
champs des blocs liste et la première ligne de
chaque tableau)
La liste des messages
#########
## Test de lecture
#########
Call TEST Trace du résultat
End

Subprog TEST
Local Char TEXTE(20)
Local Integer I , J , K
Call OUVRE_TRACE("") From LECFIC
Gosub DEFVAR From WJSOHSTD : # Appel programme
wrapper
WW_ACTION = "READ" : # READ, CREATE, MODIFY,
DELETE
WW_IDENT = "NOR1204TOU00001" : # Clé de
l'objet Val1~Val2
Gosub WEBSERV From WJSOHSTD : # Simulation web
service
Gosub ANALRESOBJ From WJSOHSTD : # Affichage du
statut
www.adonix.fr Groupe ADONIX // 66
4.4.2 Test avec l’applicatif
Test création objet

Trace du résultat

###########
## Test de création
###########
Call TEST
End

Subprog TEST
Local Char TEXTE(20)
Local Integer I , J , K
Call OUVRE_TRACE("") From LECFIC
Gosub DEFVAR From WJSOHSTD
WW_ACTION = "READ" :# On commence par lire
WW_IDENT = "NOR1204TOU00001" : # Clé de l'objet
Val1~Val2
Gosub WEBSERV From WJSOHSTD : # Simulation
lecture
WW_ACTION = "CREATE" : # Maintenant on crée
Gosub WEBSERV From WJSOHSTD : # Création
Gosub ANALRESOBJ From WJSOHSTD : # Analyse du
résultat
Gosub DETAILRES From WJSOHSTD : # Affichage des
champs
www.adonix.fr Groupe ADONIX // 67
4.4.2 Test avec l’applicatif
Test de sous programme
Subprog STOCK ( ITEM, STO, SITE )
Variable Char ITEM Dans le programme wrapper un sous-
Variable Decimal STO programme de test est intégré.
Variable Char SITE
Ce sous-programme appelle une
Local File ITMMVT [ITV] étiquette INITWS avant l’appel du sous-
Local File ITMMASTER [ITM]
Read [F:ITM]ITM0=ITEM
programme et une étiquette RESULTWS
If fstat après l’appel
Call ADDMESSWARN("Article inexistant.") From AWEB
Ceci
Else permet à l’intérieur même du
STO=0 programme à publier de prévoir des
For [ITV] Where ITMREF=ITEM and STOFCY=SITEséquences de test (elles ne seront
STO+=[ITV]PHYSTO appelées que par le programme de test
Next De charger des variables avant l’appel
Endif
intégré avec le wrapper) afin :
D’écrire des résultats dans la trace après l’appel (l’écriture
End
des messages est gérée automatiquement par le
programme de test)
$INITWS : # Etiquette pour les tests
ITEM="CD10"
SITE="ASN"
STO=0
Return
Trace du résultat
( Run WRSTOCK )
$RESULTWS : # Etiquette pour afficher le résulat
Call ECR_TRACE("ITEM="-ITEM,0) From GESECRAN
Call ECR_TRACE("SITE="-SITE,0) From GESECRAN
Call ECR_TRACE("STO="-num$(STO),0) From GESECRAN
Return
www.adonix.fr Groupe ADONIX // 68
4.4.3 Test avec le serveur WEB

 Le serveur WEB inclus un testeur de web service, celui ci permet de

valider le fonctionnement des objets modélisés dans X3.
 Il s’agit d’un client web service, il accessible depuis la page
technique

 Saisie des paramètres de

connexion

 Mémorisation du contexte

www.adonix.fr Groupe ADONIX // 69

4.4.3 Test avec le serveur WEB

Choix du web service

Choix de l’objet Choix de la méthode

invoquée
Choix des clés
Information sur l’exécution de la méthode
Réponse XML du serveur web
Trace de l’exécution de la méthode invoquée

Données XML transmises au serveur

www.adonix.fr Groupe ADONIX // 70

4.4.4 Le testeur JAVA

 Le testeur java est un outil de validation technologique muni d’une interface

de contrôle et de saisie, il permet de s’affranchir dans un premier temps de la
problématique de constitution des flux XML

Cet outil,
 Implémente les
trois web service
 Affiche les traces
d’exéctuion
Affiche les flux
XML de la réponse
 Donne les temps
d’exécution
Construit les flux
XML
automatiquement
 Implémente un
outil de test de
charge
www.adonix.fr Groupe ADONIX // 71
4.4.4 Le testeur JAVA

L’onglet trace et message d’erreur donne des informations sur l’exécution du

web service invoqué
Dans cet onglet on peut :

 Afficher la trace du serveur web

 Afficher le flux renvoyé par le

serveur

 Affiche les flux XML de la

réponse

 Avoir des informations sur les

temps

 Afficher la trace

www.adonix.fr  Groupe ADONIX // 72

4.4.4 Le testeur JAVA

 La génération des
écrans appelle le web
service getdescription et
ajoute un onglet dans
l’interface

 L’interface permet
d’invoquer les autres
web services

www.adonix.fr Groupe ADONIX // 73

4.4.5 Debugger les web service

Pour debugger en mode web service il faut utiliser le

debugger java
 Il est a télécharger depuis le serveur web
 Puis à lancer

www.adonix.fr Groupe ADONIX // 74

4.4.5 Debugger les web service

 Une fois le debugger lancé il faut invoquer un web service en précisant dans la
chaine de connexion :  Le nom du serveur du debugger

 Le numéro de port ( défaut 1789 )

Le debuggeur s’arrête dans le traitement AWEB puis sur chacun

des dbgaff ajoutés dans le code.
www.adonix.fr Groupe ADONIX // 75
4.5 Les tests de charge

 Une fois la mise au point terminée, il faut vérifier la performance globale du

système web service. Cela implique d’avoir au départ des informations sur le
nombre maximum de requête envoyée sur le serveur WEB X3. Il faut se
concentrer sur les pics d’activité du site web par exemple.
 Il faut savoir qu’une création d ’enregistrements par le biais du web service
objet est moins rapide qu’un import.
Les tests de charge permettent aussi de déterminer le nombre de licence
nécessaire pour avoir des temps de réponse acceptable.
 Ils permettent d’avoir une idée de la charge CPU et de la consommation
mémoire sur le serveur web et sur le serveur X3. Le parsing des fichiers XML est
consommateur de ressosurces.
 Les tests de charge peuvent être réalisés par le testeur JAVA qui permet de
simuler une activité utilisateur en fonction d’un scénario donné et pour nombre
simultané d’utilisateur paramétré.

www.adonix.fr Groupe ADONIX // 76

4.5 Les tests de charge

Nom public de l’objet : Nom de publication dans X3

Flux modèle : flux xml envoyé au serveur
Champ clé : Nom du champ clé de l’objet
Nombre de thread : Nombre d’utilisateurs simultanés
Nombre maxi de requête : Nombre de demande pour
chaque utilisateur ( envoyée séquentiellement )
Interval de temps : Temps d’attente entre chaque
utilisateur supplémentaire
Durée minimum : Durée au delà de quelle le test se
termine automatiquement
Répertoire des fichiers log : Répertoire disque où sera
mis le fichier du résultat

www.adonix.fr Groupe ADONIX // 77

4.5 Les tests de charge
Le résultat
 L’exécution du stresseur produit un fichier csv exploitable sous excel :

Process : Numéro de l'utilisateur rowInDistribStack : Rang d’empilage dans la file d’attente à l’arrivée de la requête
N° : Numéro de la requête pour un utilisateur nbDistributionCycle : Nombre de test effectué avant de trouver une connexion
disponible
Info : Indique l'objet du web service
poolEntryIdx : N° de l’entrée dans le pool de connexion
Error : Si = 1 une erreur s'est produite
T0 : Time stamp de la demande
poolDistribDuration : Temps de recherche d’une connexion libre

T1 : Time stamp de la réponse poolExecDuration : Temps d’exécution du traitement ADONIX

T1-T0 : Temps d'attende poolWaitDuration : Temps d’attente de la requête avant d’être en tête de la liste d’attente
poolRequestDuration : Temps total de la demande de traitement
www.adonix.fr Groupe ADONIX // 78
Mise en œuvre des WEB service X3

En résumé … Pour utiliser les services

WEB X3 il faut :

 Installer et configurer le serveur WEB X3

 Rapide et simple à faire peu de paramètres à renseigner
tout est automatique
 Développer en L4G les sous programmes
 A faire uniquement si la tâche a réaliser n’est pas
modélisée sous forme d’objet
 Publier les objets et les sous programmes concernés
 Il faut décrire au préalable les sous programme dans le
dictionnaire
 C’est une opération très rapide à réaliser
 S’assurer de leur compatibilité dans ce mode d’utilisation
 Sur l’objet des commandes de vente rien est à faire
 Pour les autres objets seul des tests peuvent donner une
idée du travail à accomplir, notamment en ce qui concerne
le spécifique

www.adonix.fr Groupe ADONIX // 79

Mise en œuvre des WEB service X3
Les évolutions prévues

 Appel d’un web service depuis le L4G

 Possibilité de supprimer et d’insérer des lignes dans un tableau
 Possibilité d’effacer un champ

www.adonix.fr Groupe ADONIX // 80

Travaux pratiques

Exercice 1

( voir annexe )

 Publication et tests sur les web services

 Objet
 Liste
 Sous programmes

 Test de ces objets pour chacune des méthodes

www.adonix.fr Groupe ADONIX // 81

 Formation Web Services
Adonix

5. Intégration dans l’application cliente

5.1. Flux XML reçu
5.2. Flux XML émis
5.3. Application cliente en JAVA
5.4. Application cliente DOTNET

www.adonix.fr
5 Intégration dans l’application cliente

 L’objectif est d’invoquer les web service X3 depuis une application

tierce.
 Le standard web service comporte une norme qui décrit le service
WEB, il se présente sous la forme d’un fichier XML. Ce fichier
(*.wsdl) décrit les méthodes et les propriétés fournies par le service.
 Mais dans le contexte où l’application serveur est un ERP qui n’est
pas figé dans sa structure il n’est pas possible de fournir un service
web immuable.
 Pour ne pas avoir à modifier les applications clientes parce qu’on a
ajouté un champ dans un écran, nous proposons des services web
génériques où seules les méthodes sont fixes.
 La partie variante est constituée des paramètres à transmettre à
ces méthodes. Ceux – ci sont transmis via un flux XML qui est a
coder et à décoder dans les applications clientes.
 De nombreuses librairies sont disponibles dans différents langages
pour effectuer ce travail.

www.adonix.fr Groupe ADONIX // 83

5.1 Flux XML reçu
 On obtient un flux résultat suite à :
 Lecture d’un objet
 Modification ou création d’un objet
 Suppression d’un objet
 Exécution d’une option
 Exécution d’une liste gauche
 Exécution d’un sous programme
 Le flux est compris dans un nœud RESULT

<RESULT>
</RESULT>
 Dans le flux on peut recevoir :
 Des groupes de champs ( bloc liste ou paramètre de sous programme)

<GRP ID="ITM0_1">
</GRP>

 Des tableaux de champs ( bloc tableau ) size donne le nb de lignes

<TAB DIM="4" ID="ITM5_2" SIZE="4">
</TAB>
 Les tableaux contiennent des lignes, num donne le numéro de la ligne
<LIN NUM="3">
</LIN>

www.adonix.fr Groupe ADONIX // 84

5.1 Flux XML reçu

 Dans les nœuds GRP et LIN on peut avoir :

 Des champs simples
<FLD NAME="ITMREF" TYPE="Char">
CD100
</FLD>
 Des champs de type menu local, MENULAB contient l’intitulé du menu

<FLD MENULAB="Actif" MENULOCAL="246" NAME="ITMSTA" TYPE="Integer">

1
</FLD>

 Dans le noeud GRP on peut avoir aussi :

 Des champs dimensionnés :

<LST NAME="TSICOD" SIZE="1" TYPE="Char">

<ITM>JOU</ITM> (1ère occurrence)
<ITM></ITM> (2nd occurrence)
<ITM>ECR</ITM> (3ème occurrence)
</LST>

 Pour un sous programme on a :

 Des champs simples si la dimension = 1
 Un ou plusieurs tableaux regroupés en cardinalité homogène
 Pour une liste gauche on a un seul tableau

www.adonix.fr Groupe ADONIX // 85

5.2 Flux XML envoyé

 On doit transmettre un flux pour

 Créer un objet
 Modifier un objet
 Exécuter un sous programme
 Le flux est compris dans un nœud PARAM
<PARAM>
</PARAM>

 Le flux à transmettre est identique au flux reçu, mais il peut être

plus souple :
 Si le champ peut être identifié sans ambiguïté, il n’a pas besoin
d’être dans un nœud groupe
 Les types de données ne sont pas à préciser
 Les intitulés des menus locaux sont inutiles
 Seuls les champs modifiés sont à transmettre
 Indiquer le nombre de lignes des tableaux est facultatif
 Indiquer pour chaque ligne d’un tableau son numéro est
facultatif

www.adonix.fr Groupe ADONIX // 86

5.3 Application cliente en JAVA
5.3.1 Préparation de l’environnement

Les fichiers WSDL

 Il existe un standard de description des web services, la description

est stockée dans un fichier WSDL ( Web Service Description
Langage )
 Ce fichier donne des informations sur les méthodes proposées par le
service web ainsi qu’une description des paramètres à passer pour
les utiliser
 Sur le serveur WEB vous trouverez 3 fichiers WSDL aux URL
suivantes :
 http://webserver/adxwsvc/services/CAdxSubProgramXml?wsdl
 http://webserver/adxwsvc/services/CAdxObjetctXml?wsdl
 http://webserver/adxwsvc/services/CAdxObjectListXml?wsdl
 Dans une application client java ces fichiers peuvent être
directement utilisés pour générer le code java permettant l’appel
aux web services respectifs

www.adonix.fr Groupe ADONIX // 87

5.3 Application cliente en JAVA
5.3.1 Préparation de l’environnement

Solution 1 : intégration du WSDL et génération des classes stubs

Plate forme de
Serveur de web développement Java Site de téléchargement
service

Récupération des fichiers WSDL Téléchargement des packages ANT

http://webserver/adxwsvc/services/CAdxSubProgramXml?wsdl et AXIS
http://webserver/adxwsvc/services/CAdxObjetctXml?wsdl
http://webserver/adxwsvc/services/CAdxObjectListXml?wsdl

Génération des classes stubs

www.adonix.fr Groupe ADONIX // 88

5.3 Application cliente en JAVA
5.3.1 Préparation de l’environnement

Solution 2 : téléchargement des classes stubs depuis le serveur WEB

Plate forme de
Serveur de web développement Java Site de téléchargement
service

Récupération des classes stubs Téléchargement des packages AXIS

www.adonix.fr Groupe ADONIX // 89

5.3 Application cliente en JAVA
5.3.1 Préparation de l’environnement
 L’objectif est de constituer un flux SOAP qui soit conforme à ce que le serveur
web attend, c’est à dire conforme à la description donnée dans le fichier wsdl.
Les étapes pour y parvenir sont les suivantes :
1. Chaque requête envoyée doit contenir un header, celui – ci est à
constituer manuellement, il doit contenir les informations suivantes:
 Code langue X3
 Code utilisateur X3
 Mot de passe X3
 Pool de connexion : il s’agit de l’alias donné dans la console
 Serveur web
 Chaine de configuration : indique les différents niveaux de trace pour la mise
au point
2. Les méthodes appelée nécessitent des paramètres ceux-ci sont regroupés dans un
paramètre unique qui contient en réalité l’ensemble des paramètres d’un sous
programme ou l’ensemble des champs d’un objet.
 Ce paramètre est à construire manuellement dans l’application cliente, il doit
se présenter sous la forme d’un flux XML.
3. Une fois la méthode exécuté, celle – ci retourne des paramètres, ceux – ci sont
regroupés en un seul.
 Ce paramètre est à décoder, il est présenté sous la forme d’un flux XML qu’il
faudra parser pour récupérer les informations

www.adonix.fr Groupe ADONIX // 90

5.3 Application cliente en JAVA
5.3.2 Import des packages

/* Packages utilisés pour parser les flux XML */

import java.io.StringReader;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import org.xml.sax.InputSource;
/* Packages utilisés pour manipuler le flux xml */
import org.w3c.dom.Document;
import org.w3c.dom.NamedNodeMap;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;
/* Packages utilisés pour appeler les web services */
import javax.xml.rpc.ServiceException;
import javax.xml.soap.SOAPElement;
import org.apache.axis.message.SOAPHeaderElement;
/* Classes générées pour appeler le web service sous programme */
import com.adonix.awss.stubs.CAdxSubProgramXml;
import com.adonix.awss.stubs.CAdxSubProgramXmlServiceLocator;
import com.adonix.awss.stubs.CAdxResultXml; // Classe générée contenant la réponse du serveur
de web service
import com.adonix.awss.stubs.CAdxMessage; // Classe générée pour lire les messages retournés par
l'applicatif

www.adonix.fr Groupe ADONIX // 91

5.3 Application cliente en JAVA
5.3.3 La requête de configuration
 Il s’agit d’une chaîne de caractères qui fait partie du header à
transmettre dans le flux soap, chaque paramètre est séparé par « & »
 Elle est constituée des éléments suivants :
 adxwss.trace.on=(on/off ) : active la trace du serveur WEB
 adxwss.trace.size=16384 : taille maximum de la trace ( ne pas
changer )
 adonix.trace.on=(on/off) : active la trace du serveur X3
 adonix.trace.level=(1/2/3) : niveau de trace ( paramètre en entrée,
sortie, E/S )
 adonix.trace.size=8 : taille maximum de la trace ( taille du clob, ne pas
changer )
 adonix.debug.on=(on/off) : activation du debugger
 adonix.debug.host=localhost : machine où est lancé le debugger
 adonix.debug.port=1789 : port du debugger
 Deux façons de procéder
 Fabrication d’une chaîne de caractères en dur :
String RequestConfigDebug = "
adxwss.trace.on=on&adxwss.trace.size=16384&adonix.trace.on=on&adonix.trace.level
=3&adonix.trace.size=8”; ou si pas de debug du tout :
String RequestConfigDebug = " adxwss.trace.on=off&adonix.trace.on=off”;
 La reconstruire à chaque appel pour activer la trace ou pas

www.adonix.fr Groupe ADONIX // 92

5.3 Application cliente en JAVA
5.3.4 Constitution du header SOAP
 L’objectif est de construire un entête qui sera ajouté au message SOAP,
ce header (CAdxCallingContext) doit contenir les nœuds suivants :
 Code langue, code utilisateur, mot de passe, pool de connexion et
requête de configuration
public static SOAPHeaderElement BuildHeader(String Lan, String User, String Pwd, String Pool,
String RequestConfig)
{
SOAPHeaderElement HeaderSoap;
HeaderSoap = new SOAPHeaderElement("http://www.adonix.com/WSS",
"CAdxCallingContext");
SOAPElement Element = HeaderSoap.addChildElement("codeLang");
Element.addTextNode(Lan);
Element = HeaderSoap.addChildElement("codeUser");
<soapenv:Header>
Element.addTextNode(User); <ns1:CAdxCallingContext>
Element = HeaderSoap.addChildElement("password");
<ns1:codeLang>FRA</ns1:codeLang>
Element.addTextNode(Pwd); <ns1:codeUser>ADMIN</ns1:codeUser>
Element = HeaderSoap.addChildElement("poolAlias");
<ns1:password></ns1:password>
Element.addTextNode(Pool);
<ns1:poolAlias>DEMO_P</ns1:poolAlias>
Element = HeaderSoap.addChildElement("requestConfig");
<ns1:requestConfig></ns1:requestConfig>
Element.addTextNode(RequestConfig);
</ns1:CAdxCallingContext>
return HeaderSoap;
}
</soapenv:Header>

Extrait du message SOAP correspondant

www.adonix.fr Groupe ADONIX // 93
5.3 Application cliente en JAVA
5.3.5 Constitution du flux XML

 Deux façons de procéder

 Fabrication d’une chaîne de caractères
String Parametre = "<PARAM><GRP ID=\"G1\"><FLD NAME=\"ITEM\">" + Item +
"</FLD></GRP></PARAM>";
 Construction manuelle d’un flux XML à l’aide des librairies
DOM et parsing du flux pour obtenir une chaîne de caractères.

www.adonix.fr Groupe ADONIX // 94

5.3 Application cliente en JAVA
5.3.6 Instanciation du web service
 L’objectif est de déclarer et de préparer le web service en vue de son
exécution, pour cela deux étapes sont nécessaires :
 Déclarer un « locator » ( url de destination )
 Instancier le web service ( utilisation des classes stubs générées )

CAdxSubProgramXmlServiceLocator SubProgLocator; // Url pour contacter le serveur WEB

CAdxSubProgramXml X3SubProg; //Le web service "sous programme" adonix

SubProgLocator = new CAdxSubProgramXmlServiceLocator(); // Instanciation de l’url

// On précise l'url de connexion ( seul le nom du serveur varie )
SubProgLocator.setCAdxSubProgramXmlEndpointAddress("http://" + Server +
"/adxwsvc/services/CAdxSubProgramXml");
try
{
X3SubProg = SubProgLocator.getCAdxSubProgramXml(); // Instanciation du web service sous programm
((org.apache.axis.client.Stub) X3SubProg).setHeader(HeaderSoap); // On positionne le header soap
return X3SubProg; // On retourne le web service crée
}
catch (ServiceException e)
{
e.printStackTrace();
return null;
}
www.adonix.fr Groupe ADONIX // 95
5.3 Application cliente en JAVA
5.3.7 Appel du web service

 L’objectif est d’invoquer le web service, cela revient à envoyer une requête HTTP
contenant le flux SOAP à destination du serveur web X3
 Exemple avec d’appel d’un sous programme :

CAdxResultXml ReponseWebService; // Réponse du serveur web suite à l'appel du web service

String ResultatXML; // Réponse sous la forme d'une chaine xml
try
{
ReponseWebService = Subprog.runXml("STOCK", Param );
}
catch (RemoteException e)
{
e.printStackTrace();
return null;
}
ResultatXML = ReponseWebService.getResultXml(); // On récupère la chaine xml de la
réponse du serveur

www.adonix.fr Groupe ADONIX // 96

5.3 Application cliente en JAVA
5.3.8 Décodage du résultat
 Lors du retour du web service le résultat est stocké dans une classe (CadxResultXml) qui permet de :

 Récupérer le flux de la réponse

String Result = ReponseWebService.getResultXml();
 Récupérer le statut
Int Statut = ReponseWebService.getStatus();
 Récupérer les messages
CAdxMessage[] Messages = ReponseWebService.getMessages();
for ( int i = 0; i<Messages.length; i++ )
System.out.println("Message "+i+" "+Messages[i].getMessage());
 Récupérer une structure avec les temps et les traces
CadxTechicalInfo = ReponseWebService.getTechnicalInfos();

www.adonix.fr Groupe ADONIX // 97

5.4 Application cliente en .NET
5.4.1 Préparation de l’environnement

 Tout comme java il y a une étape d’intégration de fichier wsdl, appelé

référence web en environnement dot NET.
 Cependant pour des soucis d’interopérabilité entre le serveur axis et le
client dot NET, l’intégration directe du fichier WSDL n’est pas possible
pour générer les classes stubs.
 Adonix met à disposition une dll qui contient déjà les classes stubs
packagées pour être directement utilisable dans le projet dot NET.
 Donc on ne fait pas une intégration d’une référence web mais
l’intégration de la DLL WAWSVCSERVER_CLIENT_LIB.dll
 Une autre référence est à ajouter : System.Web.Sercice.dll, qui elle
permet d’utiliser les web service en .NET

www.adonix.fr Groupe ADONIX // 98

5.4 Application cliente en .NET
5.4.1 Préparation de l’environnement

 Ajouts des DLL :

 WAWSVCSERVER_CLIENT_LIB.
dll
 System.Web.Sercice.dll

www.adonix.fr Groupe ADONIX // 99

5.4 Application cliente en .NET
5.4.2 Import des classes

 Exemple commenté en C#

/* Classes de base */
using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;
/* Classes utilisées pour appeler des web services */
using System.Web.Services;
/* Classes contenues dans la dll */
using com.adonix.wsvc;
using com.adonix.wsvc.spgm;
using com.adonix.wsvc.obj;
using com.adonix.wsvc.list;

www.adonix.fr Groupe ADONIX // 100

5.4 Application cliente en .NET
5.4.3 La requête de configuration
 Sa constitution ne diffère pas de l’exemple montré en java :
 Elle est constituée des éléments suivants :
 adxwss.trace.on=(on/off ) : active la trace du serveur WEB
 adxwss.trace.size=16384 : taille maximum de la trace ( ne pas
changer )
 adonix.trace.on=(on/off) : active la trace du serveur X3
 adonix.trace.level=(1/2/3) : niveau de trace ( paramètre en entrée, sortie,
E/S )
 adonix.trace.size=8 : taille maximum de la trace ( taille du clob, ne pas changer
)
 adonix.debug.on=(on/off) : activation du debugger
 adonix.debug.host=localhost : machine où est lancé le debugger
 adonix.debug.port=1789 : port du debugger

www.adonix.fr Groupe ADONIX // 101

5.4 Application cliente en .NET
5.4.4 Constitution du header SOAP
 L’objectif est de construire un entête qui sera ajouté au message SOAP, ce header (CAdxCallingContext) doit contenir les nœuds suivants :
 Code langue, code utilisateur, mot de passe, pool de connexion et requête de configuration
 Une fonction est mise à disposition dans la DLL pour le construire :

CAdxCallingContext Context= CAdxCallingContext.buildCallingContext (

null,
null, // Classe pour tracer la dll ( peut être à la valeur null )
X3LAN.Text, // Code langue ( String )
X3USER.Text, // Code utilisateur ( String )
X3PWD.Text, // Mot de passe ( String )
POOL.Text, // Alias du pool de connexion ( String )
CONFIGREQUEST.Text); // Requête de configuration ( String )

www.adonix.fr Groupe ADONIX // 102

5.4 Application cliente en .NET
5.4.5 Constitution du flux XML

 On procède de la même façon qu’avec JAVA :

 Fabrication d’une chaîne de caractères
String Parametre = "<PARAM><GRP ID=\"G1\"><FLD NAME=\"ITEM\">" + Item +
"</FLD></GRP></PARAM>";
 Ou construction manuelle d’un flux XML à l’aide de
System.xml

www.adonix.fr Groupe ADONIX // 103

5.4 Application cliente en .NET
5.4.6 Instanciation du web service
 L’objectif est de déclarer et de préparer le web service en vue de son exécution, pour cela deux étapes sont nécessaires :
 Construire l’URL de connexion
 Instancier le web service
 Pour cela une méthode est disponible pour chaque web service dans la DLL, exemple pour les sous programmes :

CServiceAdxSubProgram SubProgram = new CServiceAdxSubProgram

(null, // Classe pour tracer la dll ( peut être à la valeur null )
SPPNA.Text, // Nom public du sous programme
URL.Text, // Url de connexion ( String )
Context); // Contexte de connexion ( CadxCallingContext )

www.adonix.fr Groupe ADONIX // 104

5.4 Application cliente en .NET
5.4.7 Appel du web service

 L’objectif est d’invoquer le web service, cela revient à envoyer une requête HTTP
contenant le flux SOAP à destination du serveur web X3
 Exemple avec d’appel d’un sous programme :

// Appel du web service

com.adonix.wsvc.CAdxResultXml wAdxResultXml = SubProgram.execRun(
XMLDATA.Text); // Flux XML des paramètres ( String )

www.adonix.fr Groupe ADONIX // 105

5.4 Application cliente en .NET
5.4.8 Décodage du résultat
 Lors du retour du web service le résultat est stocké dans une classe (CadxResultXml) qui permet de :
 Récupérer le flux de la réponse
String Result = wAdxResultXml.resultXml;
 Récupérer le statut
Int Statut = wAdxResultXml.status;
 Récupérer les messages
com.adonix.wsvc.CAdxMessage[] messages = wAdxResultXml.messages
for (int i=0; i<messages.Length; i++)
{ if (i>0) wSB.Append("\n");
if (messages[i].type.Equals("1")) wSB.Append("INFORMATION : ");
if (messages[i].type.Equals("2")) wSB.Append("AVERTISSEMENT : ");
if (messages[i].type.Equals("3")) wSB.Append("ERREUR : ");
wSB.Append(messages[i].message); }
 Récupérer une structure avec les temps et les traces
com.adonix.wsvc.CAdxTechnicalInfos Info = Result.technicalInfos;

www.adonix.fr Groupe ADONIX // 106

Travaux pratiques

Exercice 2

( voir annexe )

 Développement d’une maquette

 Objet
 Liste
 Sous programmes

 Récupération des traces dans l’application cliente

www.adonix.fr Groupe ADONIX // 107