Developpez.com - 4D
X

Choisissez d'abord la catégorieensuite la rubrique :


4D Webtools : outil de test des serveurs Web fait en 4D

Date de publication : Avril 2004

Par Chiheb NASR (Ingénieur Contrôle Qualité, 4D SA)
 

Dans cette note technique, nous vous présentons 4D Webtools, un outil de test des serveurs web fait en 4D. Il vous permet de tester et contrôler le fonctionnement des Web serveurs en cours de développement ou bien ceux en production. Cette note est également une introduction aux 4D Internet Commands avec une approche bas niveau.

I. Introduction
II. Le plug-in 4D Internet commands et son approche bas niveau
III. Utilisation du protocole HTTP
Les requêtes HTTP
Les réponses HTTP
IV. Fonctionnement de la base de démo
Lancer un projet de test
Utiliser des requête simples
V. Exemple de requête sécurisée avec SSL
VI. Conclusion
VII. Bases exemples


I. Introduction

Dans cette note technique, nous vous proposons un outil de test et de contrôle des serveurs web fait en 4D et le plug-in 4D Internet commands. 4D Webtools est un outil qui vous sera de grande utilité aussi bien pendant la phase de développement que pour contrôler les serveurs Web en production. Nous commencerons dans cette note par introduire le plug-in 4D Internet commands et son approche bas niveau. Ensuite, nous présenterons des notions fondamentales sur le protocole, les requêtes et les réponses http, indispensables pour la compréhension du fonctionnement de cet outil. Enfin nous décrirons le fonctionnement de la base de démo.


II. Le plug-in 4D Internet commands et son approche bas niveau

Les Internet Commands est un plugin 4D gratuit qui doit être copié dans le dossier Mac4dx sous MacOs et dans le dossier Win4dx sous Windows. Ces dossiers peuvent être placés dans deux emplacements différents : d'abord à coté de la structure de la base de données dans ce cas le plugin sera disponible uniquement pour la base de données en question, ou dans le dossier de l'application 4D ou 4D serveur pour être disponible pour toutes les bases ouvertes par cette application. La documentation du plugin, disponible en deux langues française et anglaise, est très complète et comporte plusieurs exemples bien commentés. Les routines des ICs sont des fonctions qui renvoient un entier. Si la routine s'exécute correctement la valeur retournée est égale à zéro. Dans le cas contraire un code d'erreur est retourné.

Pour pouvoir utiliser les Internet commands il faut disposer d'une couche IP active sur la machine. Etant donnée que les ICs n'utilisent pas les composants réseaux TCP/IP de 4D, la commande IT_MacTCPinit  permettant d'initialiser le gestionnaire TCP doit être appelée avant toute autres routines. Contrairement à ce que son nom l'indique, cette commande doit être appelée aussi bien sous Mac que sous Windows.

Les ICs offre la possibilité d'utiliser l'approche bas niveau en proposant un certain nombre de routines préfixées par "TCP_ ". Ces routines vont nous permettre de :

  • Ouvrir et fermer une connexion (TCP_Open ,TCP_Close) ;

  • Envoyer ou recevoir des données (TCP_Send, TCP_SendBLOB, TCP_Receive, TCP_ReceiveBLOB) ;

  • Se mettre en attente d'une connexion entrante (TCP_Listen) ;

  • Connaître le statut d'une connexion (TCP_State).


Le principe de cette note technique est simple et consiste à établir une connexion avec un serveur Web et de lui demander une page HTML ou autre type de document  (image, vidéo, pdf...). La réponse à notre requête sera reçue dans un BLOB. Il est ensuite de notre ressort de parcourir le BLOB, après l'avoir converti en texte, pour en extraire les données par analyse des balises HTML et séparer le corps et l'entête de la réponse.

Plus concrètement, cette interrogation du serveur web peut être décrite par la séquence suivante :

  • Ouverture de la connexion avec TCP_Open ;

  • Envoi d'une requête http par la routine TCP_Send ;

  • Réception des données dans un BLOB par la routine TCP_RceiveBLOB avec contrôle de l'état de la connexion par la routine TCP_State ;

  • Enfin fermeture de la connexion par la routine TCP_Close.


Il est important de noter qu'à partir de la version 681 des ICs, la commande TCP_Open  permet d'ouvrir des connexions sécurisées et de choisir si le Scheduler de 4D continue d'être appelé au cours de la session (Mode asynchrone ou synchrone) :

TCP_Open (Nom ServeurPort DistantTCP_ID{ ; Paramètres Session}) -> Code d'erreur

Avec :
         Nom Serveur : (Alpha) correspond au Nom ou adresse IP du serveur
         Port Distant : (Entier) correspond au Port distant auquel se connecter (0 = indifférent) 
         TCP_ID : (Entier long) correspond à la référence de la session TCP ouverte
         Paramètres Session : (Entier) correspond au Paramètre de la session TCP (0,1,2 ou 3)
                        0 = Synchrone (valeur par défaut si omis) 
                        1 = Asynchrone
                        2 = Utilisation SSL, synchrone
                        3 = Utilisation SSL, asynchrone
         Code d'erreur : (Entier)

Le paramètre Paramètres Session  permet de choisir les paramètres de la Session TCP qui seront appliqués à chaque commande TCP tout au long de la session. Sa valeur par défaut est 0 (Synchrone sans SSL). En mode asynchrone, le Scheduler 4D prend la main sans attendre que les processus de connexion en cours soient finis. En revanche, en mode synchrone le Scheduler 4D reprend le contrôle uniquement lorsque le processus de connexion est terminé. L'erreur 10089 est retournée lorsque l'on passe le paramètre 2 ou 3 et que la connexion SSL ne peut être ouverte (par exemple si le 4DSLI.DLL n'est pas chargé). Par conséquent, pour se connecter à un site en https il faudra s'assurer que ce DLL est correctement installé puis ouvrir une connexion en utilisant le numéro de port 443 :

$Erreur := TCP_Open (Nom Serveur; 443; TCP_ID;2).


III. Utilisation du protocole HTTP

Les messages échangés entre notre base de données et le serveur Web ne sont que des requêtes et des réponses http. Le protocole HTTP (HyperText Transfer Protocol) est un protocole sans état et rapide permettant le transfert de données, au-dessus d'un protocole type TCP. Il est basé sur la notion de Requête/Réponse. Un client établit une connexion avec un serveur, envoie une requête au serveur sous la forme d'une méthode, un URL (ou URI d'une façon générale Uniform Resource Identifier RFC 1738 et 1808) et une version du protocole suivie d'un ensemble de modificateurs et éventuellement un corps de message. Le serveur répond sous la forme d'une ligne, dite de statut, indiquant la version du protocole et un code de succès ou d'échec, suivie de modificateurs contenant des informations relatives au serveur et au corps éventuel du message. Une fois la réponse retournée, le serveur ferme la connexion. Cette communication se passe en général au-dessus d'une connexion TCP, le port par défaut est le port 80 en http et 443 en https (communication sécurisé).


Les requêtes HTTP

Dans notre cas le plug-in 4D Internet Commands envoie une requête de document qui consiste en une ligne écrite en caractères ASCII se terminant par "CR LF" "Retour chariot + Fin de ligne" c'est-à-dire "Caractere(13) + Caractere(10)" dans le langage 4D. Cette requête dans le cas le plus simple est du type "GET", un espace et l'adresse du document mais la syntaxe générale d'une requête est du type :

   Requête = Commande <URL> Version_Du_Protocole <CR, LF>
               [Entêtes]
               <CR, LF>
               [Corps_De_La_Requête]

La version de Version_Du_Protocole est HTTP/1.0 ou HTTP/1.1 et URL est la chaîne identifiant l'objet sur l'Internet.

Les principales commandes d'une requête http sont :

GET Demande l'envoi des données identifiées par l'URL.
POST Permet l'envoi des données d'un formulaire.
HEAD Identique à GET mais retourne seulement les entêtes HTTP sans le corps du document.
PUT Transmet un fichier au serveur.


Post ou Get 
La différence entre ces deux types de requêtes réside dans la façon suivant laquelle le navigateur web envoie les données du formulaire et la quantité des données que ce formulaire pourrait contenir. Pour le GET, les champs du formulaire sont packagés et envoyés sous la forme d'un seul Url. Généralement, il n'y a pas une longueur limite de l'Url formé mais certains navigateur web la limitent à 1 k octets environ. Dans le cas d'un POST, les champs du formulaire Web sont également packagés mais envoyés à la fin de la requête http. Il n'y a, également, pas de longueur limite pour les données envoyées mais certains navigateurs la limitent quand même à 6 k octets caractères maximum par zone de texte. Il est également important de noter qu'il n'y a que le POST qui permet d'envoyer (Upload) un document via le Web (pas le GET).

HEAD et PUT dans 4D 
Dans les versions actuelles le serveur Web 4D ne supporte pas la commande PUT et supporte partiellement la commande HEAD. Par exemple, en interrogeant via la commande HEAD un serveur web sur Internet autre que 4D on obtient une réponse comme ci-dessous :

Pictures 0564x0148



Alors qu'avec un serveur Web 4D 2003 on obtient ce qui suit :

Pictures 0558x0073



Par ailleurs, on peut personnaliser notre requête en lui ajoutant des entêtes permettant de fournir des informations plus précises au serveur Web. En pratique il existe une cinquantaine d'entêtes possibles des requêtes et qui ont toutes le format  "Mot-clé : Valeur". On peut citer parmi les plus utilisées :

From Adresse mail de l'utilisateur
If-modified-since La page n’est transférée que si elle a été modifiée depuis la date précisée
Referer URL d’origine de la page contenant le lien à partir duquel le navigateur a trouvé l’URL
User-agent Précise le nom et la version du navigateur
Accept Types MIME visualisables par le navigateur


Voici un exemple de requête :

   GET /index.html HTTP/1.0
   Accept : text/html
   User-Agent : Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)


Les réponses HTTP

La réponse envoyée par le serveur web se compose d'une première ligne précisant la version du protocole, un code (ou statut) de réponse et un message précisant la réponse. Suivent éventuellement des entêtes (avec le même format que pour la requête), une ligne vide et le corps de la réponse. On peut présenter une réponse de la manière suivante :

   Réponse  = HTTP/<Version> <Status> <Commentaire Status>
               [< Champ d 'entête >: <Valeur>]
               Ligne blanche
               Document

A chaque réponse du serveur Web correspond un code ou statut d'erreur ou de succès. Le tableau suivant récapitule l'ensemble de ces codes :

Code Type Signification
1xx Informationnel La commande a été reçue – le traitement est en cours.
2xx Succès La commande a été reçue correctement, comprise et acceptée.
3xx Redirection La commande ne peut pas être exécutée telle quelle ; il faudra faire autre chose pour la gérer totalement (par exemple aller chercher le document ailleurs)
4xx Erreur client La commande n'est pas correcte syntaxiquement ou ne peut pas être traitée.
5xx Erreur serveur Le serveur n'a pu traiter correctement une commande apparemment correcte.



Types de code de réponse

Ci-dessous un exemple de réponse d'un serveur Web 4D 2003  :
HTTP/1.0 200 OK
Server: 4D_WebStar_D/7.3
MIME-Version : 1.0
Content-type : text/html
Content-length : 1055
Date: Wed, 28 Jan 2004 19:43:27 GMT
Last-Modified: Tue, 14 Sep 1999 08:12:52 GMT

<HTML>
<HEAD>
<TITLE>
Exemple de document HTML
</TITLE>
</HEAD>
<BODY>
(Corps du document)
</BODY>
</HTML>

IV. Fonctionnement de la base de démo

La base exemple traduisant 4D Webtools est composée de deux dialogues principaux. Le premier permet de lancer un projet complet de test d'un serveur Web et le deuxième propose une requête simple mais complètement paramétrable.


Lancer un projet de test

Un projet de test permet d'une part de contrôler le fonctionnement d'un serveur Web ainsi que de tester sa montée en charge en le bombardant par un certain nombre de requêtes prédéfinies. Le dialogue suivant propose à l'utilisateur un projet de test à paramétrer :

Pictures 0528x0341



Les paramètres d'un projet de test sont les suivants :

  • Adresse du serveur Web : dans cette zone il faudra saisir l'adresse du serveur web soit en passant l'adresse littérale du site par exemple "www.4d.fr" ou bien son adresse IP.

  • Numéro du port serveur Web : le numéro de port par défaut pour le protocole http est le 80 mais ceci peut bien évidement changer selon la configuration utilisée.

  • Utilisation du proxy : ce paramètre nous permet de s'adresser au proxy lorsqu'on ne peut pas se connecter à l'Internet directement. C'est le cas par exemple d'un réseau d'entreprise. Dans ce cas de figure, il convient à l'utilisateur de cocher la case "Passer par le proxy" et saisir l'adresse exacte du proxy dans la zone de saisie qui s'active.

  • Communication sécurisée ou non sécurisée : Il s'agit de choisir entre le protocole sécurisée https ayant le numéro de port par défaut 443 et celui non sécurisée http avec le numéro de port par défaut 80.

  • Nombre de Users : Il s'agit du nombre de clients web lancés par la base de démo. En effet, pour chaque client web correspondra un process 4D qui fera tourner la méthode projet HTTP_Multi_Requetes.

  • Nombre de requêtes par secondes : cette valeur correspond au nombre de requêtes envoyées par secondes au serveur web. Les process 4D traduisant les clients web seront endormis plus ou moins longtemps en fonction de la valeur donnée à cette propriété.

  • Liste des urls : c'est une zone de texte où on doit saisir, à raison d'un par ligne, tous les URLs à envoyer au serveur web. La méthode projet GEN_TexteVersTableau transformera cette variable texte en un tableau texte d'urls et bien entendu toutes les lignes vides seront supprimées.

  • Ordre d'envoi des urls : les deux cases à cocher "Dans l'ordre"  et "Aléatoirement" permettent de définir l'ordre d'envoi des urls respectivement dans l'ordre ou aléatoirement.

  • Bouton "Enregistrer le projet"  permet de stocker tous les paramètres d'un projet sur disque sous forme d'un fichier texte. L'enregistrement des projets est assuré par la méthode GEN_Vars_vers_Blob et la commande BLOB VERS DOCUMENT.

  • Bouton "Charger le projet" fait exactement l'inverse du bouton "Enregistrer le projet" c'est-à-dire charger un projet à partir du disque. Une vérification de la validité du projet est bien entendu effectuée avant chaque chargement de projet. L'ouverture d'un projet existant est assurée par la méthode GEN_Blob_vers_Vars et la commande DOCUMENT VERS BLOB.

  • Enfin pour lancer le projet de test il suffit de cliquer sur le bouton "Démarrer" ou utiliser le raccourci clavier SHIFT+D.


Une fois le projet de test défini et lorsque l'on clique sur le bouton "Démarrer", on passe sur la deuxième page du dialogue qui présente en temps réel les résultats des tests. Voici un aperçu des résultats obtenus :

Pictures 0493x0388



Dans cette page de dialogue on retrouve en haut de la page les principales informations sur le projet de test en cours. Puis les résultats de chaque client web sont représentés sous forme de tableaux groupés. Enfin, en bas de la page, on affiche les résultats globaux.

Les résultats des tests sont les suivants :

  • Liste des clients Web (Nom Client Web) : c'est la liste des process 4D qui simulent les client Web. On suffixe chaque nom par un indice qui nous renseigne sur le numéro de client web ainsi que sur le nombre total.

  • Nombre des requêtes : La deuxième colonne présente le nombre de requêtes envoyées par chaque client Web. Le nombre total des requêtes est affiché en bas de la liste.

  • Données envoyées en octets : La troisième colonne nous donne la taille des données envoyées par chaque client Web. La taille totale des données envoyées est affiché en bas de cette colonne.

  • Nombre des réponses : La quatrième colonne présente le nombre de réponses reçues par chaque client Web. Le nombre total des réponses est affiché en bas de la colonne.

  • Données reçues en octets : La cinquième colonne nous donne la taille des données reçues par chaque client Web. La taille totale des données reçues est affiché en bas de cette colonne.

  • Nombre d'erreurs : La sixième colonne affiche le nombre d'erreurs reçues par chaque client Web. Le nombre total des erreurs est affiché en bas de la colonne.

  • Pourcentage d'erreurs : La septième colonne affiche le pourcentage d'erreurs pour chaque client Web. Le pourcentage total des erreurs est affiché en bas de la colonne.


Pour arrêter le test en cours il suffira de cliquer sur le bouton "STOP" ou d'utiliser le raccourci-clavier  SHIFT +S.


Utiliser des requête simples

Le principe dans cette partie est d'établir une connexion avec un serveur Web et de lui demander une page HTML particulière ou tout autre type de document  (image, vidéo, pdf...). La réponse à notre requête sera reçue dans un BLOB qui sera converti en texte, pour en extraire les données par analyse des balises HTML. Cette analyse consiste à séparer le continu de la page et l'entête de la réponse pour donner une réponse claire à l'utilisateur sur le déroulement de la requête, les informations reçues et le contenu du document afin de lui donner la possibilité de stocker le document sur le disque ou dans le fichier de données. En ce qui concerne le dernier point et afin de pouvoir stocker le document il sera indispensable de traiter, en fonction du type MIME reçu et selon le plateforme, l'extension ou le créateur du document.

L'envoi de la requête est également paramétrable. La copie d'écran suivante présente le dialogue de paramétrage d'une requête dans la base de démo :

Pictures 0492x0425



Vous remarquerez que ces paramètres sont identiques à ceux de la partie précédente, à l'exception des différences suivantes :

  • Choix de la méthode utilisée : GET, POST ou HEAD. Lorsque l'on choisi la méthode POST la zone de saisie nommée "Data du POST" s'active pour vous permettre de saisir les données du post.

  • Url : on note que dans ce type de test on ne peut saisir qu'un seul url.

  • Progression : une zone de texte appelée "Progression" affichera à l'utilisateur des informations relatives au déroulement de la requête depuis l'ouverture de la connexion jusqu'à sa fermeture.

  • Erreur : une zone de texte qui affichera à l'utilisateur les erreurs rencontrées a été rajoutée à droite de la zone progression. Bien entendu, s'il n'y pas d'erreurs cette zone reste invisible.


Pour lancer le test et passer à la deuxième page du dialogue qui est la page des résultats, il suffit de cliquer sur le bouton "Envoyer ". Cette page de réponse contiendra les informations citées ci-après comme le montre la copie d'écran suivante :

Pictures 0444x0479
  • Statut de la réponse : à chaque réponse du serveur Web correspond un code ou statut d'erreur ou de succès. Pour plus d'informations sur ce sujet nous vous renvoyons sur la partie III.2 Les réponses HTTP.

  • Taille de données reçues : cette information nous informe sur la quantité de données reçue en octets. Cette taille tient compte de l'entête et du corps de la réponse.

  • Entête http : Les entêtes http sont affichés sous forme de deux tableaux groupés. Le premier affiche les noms des champs présents dans l'entête et le deuxième tableau affiche leurs valeurs respectives.

  • Corps de la réponse : cette zone affiche le contenu de la page reçue. Cette page peut être la page demandée en cas de succès de la requête ou bien la page de réponse du serveur web ou éventuellement du proxy.


Pour avoir un idée plus claire de fonctionnement de la base de demo en voici quelques exemples d'utilisations.

La copie d'écran suivante montre une simple requête construite pour télécharger la page d'accueil du site APPLE. Dans cet exemple on interroge le proxy car le test était effectué dans un réseaux local où le passage par le proxy pour accéder à l'Internet est obligatoire :

Pictures 0452x0442
Simple Requête : Interrogation de la page d'accueil d'APPLE



Lorsqu'on clique sur le bouton "Envoyer", la requête est envoyée et on passe sur la deuxième page du formulaire qui nous affiche la réponse, comme le montre l'écran suivant :

Pictures 0456x0458



Ce deuxième exemple a pour but de tester le fonctionnement et la montée en charge d'un serveur web par exemple celui de 4D SA à l'adresse http://www.4d.fr/ . Ce projet de test est défini dans la copie d'écran suivante, notez que vous pouvez enregistrer vos projets sur disque pour pouvoir les réutiliser :

Pictures 0464x0434
Projet de test du serveur Web de 4D SA



Pour lancer ce projet de test il suffit de cliquer sur le bouton "Démarrer". Les résultats sont alors affichés en temps réels sur la deuxième page comme le montre l'écran suivant :

Pictures 0551x0489
Résultats à temps réel d'un projet de test d'un serveur Web

V. Exemple de requête sécurisée avec SSL

Pour pouvoir utiliser le protocole SSL pour vos requêtes sécurisées il faut vérifier la présence du fichier 4DSLI.DLL, nécessaire au fonctionnement de SSL, dans le dossier 4D Extensions de votre application (4D, 4D Serveur, 4D Client ou Base compilée avec 4D Engine). En revanche, Il n'est pas nécessaire de disposer d'un certificat SSL ou d'activer la case à cocher "Autoriser SSL pour le serveur Web" dans la fenêtre de dialogue des Propriétés de la base.

Par ailleurs, 4D propose deux types d'interfaces de la couche sécurisée (Secured Layer Interface) pour la gestion du SSL : 4DSLI.DLL pour un cryptage 40-bits et 4DSLI128.DLL pour un cryptage 128-bits. 4D peut utiliser indifféremment l'une ou l'autre librairie. Pour utiliser l'interface 128-bits, il faudra :

   1- Renommer ou déplacer le fichier 4DSLI.DLL correspondant au cryptage 40-bits du dossier de la base ;
   2- Placer le fichier 4DSLI128.DLL dans le dossier de la base ;
   3- Renommer le fichier 4DSLI128.DLL en 4DSLI.DLL.

Ci-après un exemple de requête sécurisée utilisant le protocole SSL. Notez le choix du protocole HTTPS.

Pictures 0409x0442



Le résultat de cette requête sécurisée est présenté dans la copie d'écran suivante. Il important de noter que le nom du protocole retourné dans le statut de la réponse est HTTP et non  HTTPS. Ceci n'est pas une erreur car le protocole de communication utilisé est bien le HTTP. Le HTTPS n'est pas un protocole à part entière mais une couche de cryptage et décryptage basée sur le protocole HTTP.

Pictures 0439x0473

VI. Conclusion

Dans cette note technique, nous avons présenté 4D Webtools, un outil de test des web serveurs fait en 4D. Il vous permet de tester et contrôler le fonctionnement des Web serveurs en cours de développement ou bien ceux en production. Le principe de fonctionnement de cet outil consiste à définir un projet de test, le lancer et afficher les résultats qui seront actualisés à temps réel. 4D Webtools vous permet de stocker les projets de test sur disque sous format texte. Vous pouvez faire la même chose pour stocker les résultats de vos tests en vous servant uniquement de deux méthodes génériques : GEN_Vars_vers_Blob et GEN_Blob_vers_Vars.


VII. Bases exemples

Téléchargez les bases exemples :

base exemple Mac

base exemple Windows

__________________________________________________
Copyright © 1985-2009 4D SA - Tous droits réservés
Tous les efforts ont été faits pour que le contenu de cette note technique présente le maximum de fiabilité possible.
Néanmoins, les différents éléments composant cette note technique, et le cas échéant, le code, sont fournis sans garantie d'aucune sorte. L'auteur et 4D S.A. déclinent donc toute responsabilité quant à l'utilisation qui pourrait être faite de ces éléments, tant à l'égard de leurs utilisateurs que des tiers.
Les informations contenues dans ce document peuvent faire l'objet de modifications sans préavis et ne sauraient en aucune manière engager 4D SA. La fourniture du logiciel décrit dans ce document est régie par un octroi de licence dont les termes sont précisés par ailleurs dans la licence électronique figurant sur le support du Logiciel et de la Documentation afférente. Le logiciel et sa documentation ne peuvent être utilisés, copiés ou reproduits sur quelque support que ce soit et de quelque manière que ce soit, que conformément aux termes de cette licence.
Aucune partie de ce document ne peut être reproduite ou recopiée de quelque manière que ce soit, électronique ou mécanique, y compris par photocopie, enregistrement, archivage ou tout autre procédé de stockage, de traitement et de récupération d'informations, pour d'autres buts que l'usage personnel de l'acheteur, et ce exclusivement aux conditions contractuelles, sans la permission explicite de 4D SA.
4D, 4D Calc, 4D Draw, 4D Write, 4D Insider, 4ème Dimension ®, 4D Server, 4D Compiler ainsi que les logos 4e Dimension, sont des marques enregistrées de 4D SA.
Windows,Windows NT,Win 32s et Microsoft sont des marques enregistrées de Microsoft Corporation.
Apple, Macintosh, Power Macintosh, LaserWriter, ImageWriter, QuickTime sont des marques enregistrées ou des noms commerciaux de Apple Computer,Inc.
Mac2Win Software Copyright © 1990-2002 est un produit de Altura Software,Inc.
4D Write contient des éléments de "MacLink Plus file translation", un produit de DataViz, Inc,55 Corporate drive,Trumbull,CT,USA.
XTND Copyright 1992-2002 © 4D SA. Tous droits réservés.
XTND Technology Copyright 1989-2002 © Claris Corporation.. Tous droits réservés ACROBAT © Copyright 1987-2002, Secret Commercial Adobe Systems Inc.Tous droits réservés. ACROBAT est une marque enregistrée d'Adobe Systems Inc.
Tous les autres noms de produits ou appellations sont des marques déposées ou des noms commerciaux appartenant à leurs propriétaires respectifs.
__________________________________________________
 



Valid XHTML 1.1!Valid CSS!

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
Contacter le responsable de la rubrique 4D