Manuel

Client de bases externes : connecteur HTTP

 

Un connecteur d'accès à une base externe de type HTTP nécessite de bonnes connaissances en html, en rédaction de script et de bonnes qualités d'observation.

 

Vous ne pourrez réaliser un connecteur fiable, pérenne et honnête que si le serveur le permet. En effet, télécharger des données d'un site qui ne l'autorise pas peut vous exposer à un litige. Avant de vous lancer dans la réalisation d'un connecteur, consultez donc les mentions légales. De plus, un site qui ne veut pas être interrogé par une application autre qu'un navigateur a tout moyen technique de "brouiller les pistes".

 

Les grands principes

 

La réalisation d'un connecteur http se déroule en deux étapes : poser une question et analyser le résultat. Pour poser une question, l'application va tenter de reproduire les échanges entre un utilisateur et un serveur via un navigateur.

 

Notion de session : au niveau de l'utilisateur

 

Certains sites utilisent une notion de session qui consiste, le plus souvent, à mettre en oeuvre une solution permettant d'identifier à chaque appel l'utilisateur. Cette identification peut être réalisée, soit parce que ce dernier a indiqué ses identifiant et mot de passe, soit parce que le serveur lui a envoyé un "marqueur" qui sera systématiquement renvoyé. Il existe deux types de marqueurs  : les "cookies" et les "session ID". Un "cookie" sera stocké dans le dossier temporaire du navigateur de l'utilisateur et sera renvoyé au serveur lors de chaque envoi d'une URL. Un "session ID" est en général inclus dans l'URL. Etant donné qu'il n'existe pas de standard bien défini à ce niveau, chaque serveur a implémenté la notion de session en fonction des possibilités techniques offertes par sa plate-forme.

Lorsqu'un internaute appelle la page de recherche d'un site, ce dernier a déjà pu lui envoyer un cookie ou bien inclure un session ID dans le formulaire de recherche. Dans la mesure où le connecteur reproduit le formulaire de recherche, il sera peut être nécessaire d'appeler une première page afin qu'un cookie soit envoyé par le serveur et que le connecteur puisse ensuite renvoyer ce cookie afin que la recherche puisse être traitée correctement. Dans le cas d'un session ID, c'est plus complexe et cela nécessite l'écriture d'un script d'analyse du résultat permettant d'injecter le session ID dans les paramètres de recherche.

 

Notion de session : au niveau d'une recherche

 

Poser une question puis naviguer au sein d'un résultat nécessite également parfois de gérer une notion de session.

Lorsqu'un utilisateur effectue une recherche, la première page de résultat est affichée. Afin de permettre à l'utilisateur de demander une deuxième page, les serveurs utilisent trois techniques principales.

 

1 - la requête est sytématiquement renvoyée (et donc le résultat recalculé par le serveur) et un paramêtre indique dans l'URL des pages complémentaires l'item de départ (exemple : "start=10" pour indiquer que l'on veut à partir du 10ème élément), ou la page (exemple "page=3" pour indiquer que l'on souhaite obtenir la troisième page du résultat)

2 - un session ID est affecté lors de chaque requête et l'appel des pages complémentaires s'effectue par transmission du session ID. Ceci évite au serveur de recalculer systématiquement le résultat. Lors de la requête le résultat est conservé par le serveur, ensuite la navigation s'effectue à l'intérieur de ce résultat.

3 - le serveur utilise le cookie que renvoie le navigateur et identifie grâce à celui-ci l'utilisateur et / ou la requête effectuée.

 

Methode GET ou POST

 

Un internaute utilise un formulaire pour poser une question à un serveur. Soit les critères sont en nombre limité et peuvent être adressés de manière visible dans l'URL (ce qui correspond au cas général), la méthode indiquée dans le formulaire est alors en GET ; soit les critères peuvent être complexes, longs et ne doivent pas être visibles (et donc pas de possibilité non plus de créer un signet au niveau du navigateur) et la méthode est en POST.

 

Dans le cas d'une méthode GET, il est suffisant (en général) d'analyser l'URL apparaissant dans le navigateur pour en comprendre et reproduire la structure.

 

Dans le cas d'une méthode POST, il convient d'ouvrir la page html contenant le formulaire de recherche et d'analyser la structure du formulaire.

 

 

Exemple de formulaire POST

 

Le formulaire s'affichant comme représenté ci-dessous

 

est généré à partir du code html suivant (le code reproduit ci-dessous a été, pour des raisons de lisibilité, simplifié et les balises de présentation ont été enlevées)

 

<form action="ListRecord.htm" method="post" enctype="x-www-form-encoded" name="record">

<input type="hidden" name="idinlist" value="0">

<input type="hidden" name="list" value="request">

 

<input type="hidden" name="NumReq" value="191963591914">

<input type='checkbox' name='objecttype_03Article' checked=true >Article

<input type='checkbox' name='objecttype_03Logiciel' checked=true >Logiciel

 

Rechercher dans le contenu

<input name='cluster_1' type='text' size='30' value='' class='textblack10'>

 

<input type="radio" name="inselect" value="0" checked=true >Dans la base

<input type="radio" name="inselect" value="1" >Affiner la recherche

 

<input type="reset" value="Annuler" class="button">

<input type="submit" value="OK" class="button">

 

</form>

 

 

Javascript dans un formulaire

 

Du javascript peut être introduit dans un formulaire pour :

 

- calculer l'affichage de ce dernier

- alimenter des champs (input...) à partir de valeurs saisies dans d'autres champs

- valider un formulaire en faisant, préalablement, des opérations sur les valeurs avant transmission

 

Dans ce cas, il se peut que de solides connaissances en javascript soient nécessaires pour en étudier le comportement.

 

Redirection

 

Lorsqu'un internaute pose une question, il se peut que ce dernier réponde par l'intermédiaire d'une redirection (ie : ne réponde pas immédiatement). Suivant la manière dont sont structurées ces redirections, il se peut que cela bloque le processus.

 

Analyse du résultat

 

Une page html est avant tout conçue pour être lue par un être humain. Aussi la manière dont sont présentées les informations a pour premier objectif de mettre en valeur les informations importantes (exemple : un titre sera en général plus visible qu'un commentaire). Cela se traduit par des balises placées avant les zones de texte. La réalisation de la deuxième partie du connecteur consiste à tenter d'utiliser ses balises afin de découper le résultat.

 

Pagination

 

Dans le cas où la page de résultat inclut un lien vers la "page suivante", nous allons tenter de provoquer l'appel de l'URL correspondant. Sinon, il faudra calculer l'URL des pages suivantes par l'intermédiaire de scripts.

 

Conclusion... avant de démarrer

 

S'il existe des connecteurs simples à réaliser, la lecture de cet avant-propos permet de prendre conscience des difficultés que l'on peut rencontrer. Il convient donc de commencer par des connecteurs simples puis de monter en difficulté tout en gardant à l'esprit qu'il n'y aura pas systématiquement de solution. Par ailleurs, il existe sur le marché des produits de veille très sophistiqués prenant en charge un nombre de cas de figure beaucoup plus important. La vocation de votre logiciel n'est pas de rivaliser avec ces solutions. Il peut être alors judicieux de faire communiquer votre logiciel avec un tel produit.

 

Dialogue de réglage

 

Le réglage d'un connecteur http s'effectue en deux étapes. La première consiste à indiquer les coordonnées du serveur cible et la manière dont la question est posée. La deuxième consiste à indiquer comment analyser la structure du résultat afin d'en isoler les enregistrements et les champs.

 

Coordonnées du serveur et construction d'une requête

 

Réglages du connecteur : composer une requête

 

Entête http (ou header)

 

 1  Composition de l'entête http

 

Lorsqu'un navigateur adresse une requête à un serveur sous la forme d'une URL, il envoie en fait toute une série d'informations que le serveur va pouvoir décrypter afin d'obtenir des renseignements sur l'application qui le sollicite. Certains navigateurs font déjà, à ce niveau, des vérifications et ne renvoient pas de résultat s'ils estiment que le client est "douteux". L'information peut comporter des balises qui seront remplacées par les valeurs calculées lors de la requête :

 

 

Balise   Remplacée par lors de l'exécution 

$$KV_Date   Date et heure courante

$$KV_Content_Type       Chaine vide si méthode GET

   Content-Type: application/x-www-form-urlencoded si méthode POST

$$KV_Method        GET ou POST

$$KV_Host   Nom du serveur

$$KV_URL    URL demandée

$$KV_Cookie         Cookies éventuellement reçu du serveur (cas d'URL de connexion)

 

 

URL de connexion

 

 2  Première URL adressée avant l'URL correspondant à la requête elle-même

 

Pour qu'une URL de connexion soit traitée en méthode POST, il faut mettre un retour à la ligne après l'URL elle-même ainsi qu'entre chaque paramètre. Sinon, c'est une URL traditionnelle qui doit être saisie ici. Cette URL de connexion peut être utilisée soit pour indiquer au serveur qui est l'utilisateur (et récupérer ensuite le cookie qui sera envoyé en entête lors des appels suivants), soit plus simplement pour obtenir un cookie de session.

 

Réglages avancés complémentaires

 

 

Information      Description  

HTTPS  Utiliser une connexion sécurisée (sur le port 443 vs port 80)

SyncCookies   Ajoute les cookies recus lors de l'envoi de la requête

    à ceux reçus lors de l'appel de l'URL de connexion

Retry connect  nombre de tentatives d'obtention d'une URL (entre 1 et 3)

Redirect Follow         nombre de redirections propagées (entre 1 et 3)

 

 

Methode et coordonnées du serveur

 

 3  Serveur et URL de recherche ; nombre maximum d'enregistrements à récupérer.

 

Méthode : lors de l'envoi d'une requête au serveur, le codage est différent suivant que la méthode spécifiée est GET ou POST. Il est donc important de bien vérifier au préalable quelle méthode doit être utilisée (cf. ci-dessus).

 

Host : le nom du serveur (ou Host) doit être exprimé sans la mention du protocole devant (http ou https).

 

URL : la partie située entre le nom du serveur et les paramètres.

 

NB records : lorsque la balise de page suivante est détectée dans la page html reçue, par défaut le connecteur va tenter d'appeler la page suivante tant que cette balise est trouvée. Si le connecteur peut renvoyer un nombre elevé de résultats, il est conseillé de de limiter en indiquant ici un nombre maximum.

 

Spécificité des URL de type "File"

 

Si vous saisissez une URL commençant par "file://..." cela signifie que vous désignez un fichier sur le disque. Dans ce cas, les informations de connexion seront automatiquement cachées.

 

Connecteur URL (File) : permet de bénéficier des outils d'analyse décrits ci-après

 

Découpage de l'URL

 

 4  Assistant de découpage

 

SI vous collez dans la zone URL une URL complète que vous auriez copiée à partir de votre navigateur, en cliquant sur ce bouton, vous isolerez d'abord le serveur puis les paramètres.

 

 

Exemple

En utilisant le moteur de recherche Yahoo

 

en collant l'URL générée (dans le navigateur) dans la zone URL du connecteur

 

puis en cliquant sur le bouton de découpe, le serveur (Host) est isolé et les paramètres extraits

 

il ne reste plus qu'à indiquer que "Khentika" est en fait la valeur recherchée

 

 

Paramètres

 

 5  Les paramètres sont exprimés sous la forme libellé = valeur

 

Il existe trois manières de renseigner un paramètre :

 

Valeur fixe : le libellé et la valeur sont identiques, quelle que soit la requête

exemple : "fr=moz2"

 

Valeur fixée par programmation (cf. ci-dessous : 8 )

 

Valeur dépendant de la recherche : la valeur est remplacée dynamiquement par la valeur de recherche saisie lors de l'utilisation du connecteur.

exemple : "p=$$KV_Query"

 

Pour fixer cette balise, il est fortement recommandé d'utilisé le pop-up apparaissant en cliquant sur le point rouge.

 

Choix du champ de recherche correspondant au paramètre

 

Option : Définir comme champ de recherche par défaut. Un connecteur peut être utilisé de deux manières : par l'intermédiaire d'un écran de recherche multi-critère ou bien à l'aide d'une zone de saisie unique de critère (cas de l'explorateur par exemple). Si les champs de recherche sont clairement identifiés (exemple : Titre / Mot clé / Auteur), vous devez définir un de ces champs comme critère de recherche par défaut.

 

Le titre sera le critère de recherche par défaut

 

Conversion spéciale. Une valeur saisie dans un paramètre est automatiquement convertie en format URL lors de la construction de l'URL complète. Il est possible de désactiver ce mécanisme de la manière suivante :

 

- en préfixant la valeur par $URL=, le préfixe ne sera pas transmis et la valeur de sera pas convertie

- en préfixant la valeur par $UR8=, le préfixe ne sera pas transmis et la valeur sera convertie en UTF-8

- en mettant "$NoParam"  dans l'intitulé (1ère colonne), seule la valeur sera transmise (et pas le libellé)

 

Tester l'URL

 

 6  Tous les éléments sont en place pour effectuer une requête

 

En cliquant sur ce bouton, une requête est adressée au serveur en tenant compte de tous les paramètres qui ont été précisés. Si le serveur répond correctemenet, le résultat est affiché juste sous le bouton.

 

 

Pour les experts

Si la requête s'est bien déroulée, vous obtenez dans une zone grisée, située en dessous et à gauche du bouton, l'entête http qui a été transmise au serveur, exemple :

GET /search?p=Khentika&ei=UTF%2D8&fr=moz2 HTTP/1.0

Host: fr.search.yahoo.com

User-Agent: Mozilla

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Content-Type: application/x-www-form-urlencoded

Content-Length: 0

Si la requête s'est mal déroulée, vous obtenez dans cette zone un message :

# redirected

# No response : fr.search.yahoo.com?fr=404

 

 

Voir le résultat

 

 7  Vérifier que la page est correcte avant de passer à l'étape d'analyse du contenu

 

Le texte qui s'affiche sous le bouton donne déjà une première idée de ce qui a été reçu. En cliquant sur le bouton la page reçue s'affiche dans votre navigateur. Ce qui s'affiche n'est pas exactement ce qui est reçu, en effet, afin d'avoir une meilleure présentation du résultat, le fichier subit une transformation des URL relatives en URL absolues. Pour désactiver cette transformation, maintenez la touche majuscule enfoncée en cliquant sur le bouton.

 

Scripts

 

 8  Avant et après la requête : deux possibilités de programmation

 

Dans certains cas, il peut être nécessaire d'influer sur la construction de l'URL par programmation et d'effectuer une série d'opérations après avoir reçu la page. Ci-après sont décrites les principales variables sur lesquelles il est possible d'influer.

 

 

Variable Description  

THost    Nom du serveur (tel que saisi dans le dialogue)

TURL    URL (telle que saisie dans le dialogue)

TT_TitreTableau des intitulés des paramètres (1ère colonne)

TT_Ligne        Tableau des valeurs des paramètres (2ème colonne)

ELDeb   Sa valeur est à -1 lors du premier appel.

    Sert à gérer la pagination par programmation

 

 

Analyse

 

 9  Quand la page est correcte, on procède à son analyse

 

Deuxième étape : découper la page en enregistrements et reconnaître les informations au sein de ces derniers.