Exports SITRA

Attention, page complètement obsolète, qui devrait être dépubliée : liens brisés, etc.

Ceci est une « contribution pédagogique », qui montre par l’exemple comment développer une nouvelle fonctionnalité pour SPIP.

Le système de diffusion des informations ayant été modifié depuis 2012, cette contribution n’est plus maintenue ni opérationnelle.

Cette publication s’adresse à celles et ceux de la région Rhône-Alpes (peut-être d’autres régions bénéficiant d’un système équivalent) qui voudraient alimenter leur site avec les données touristiques. SITRA (Système d’Information Touristique Rhône-Alpes) est principalement une base d’informations touristiques alimentée par les Offices de Tourisme du territoire. À partir de cette base ceux-ci peuvent extraire l’information pour leur communication papier mais également web.

Dans ce dernier domaine, deux méthodes sont proposées
par un système de webservices interrogeable en SOAP
par un système d’export de fichiers au format xml.

Ce plugin traite la seconde méthode.

L’export a lieu quotidiennement (ou moins fréquemment). Les fichiers sont au format xml dérivé du format TourInfrance enrichies de références propres à SITRA. C’est un export différentiel constitué de plusieurs fichiers :
-  Le fichier contenant la liste des objets par sélection (effectuée via un client SITRA spécifique)
-  Le fichier des objets supprimés depuis le dernier export
-  Le fichier de description des objets ajoutés ou modifiés (un par langue choisie)
-  Enfin le fichier des images principales (zip).
Les trois premiers peuvent être compressés en une seule archive zip.

Pour tous les détails techniques se reporter à http://195.101.57.102/Documentation...

Ce plugin traite les cas suivants :
Exports en un seul fichier, compressé ou non, plusieurs langues et export des images principales.
À l’issue de l’export une requête est faite par le système SITRA vers une url du site qui déclenche alors, la décompression éventuelle des archives zip, l’analyse des fichiers et la mise à jour des tables (suppression, ajout, mise à jour), l’exportation des images principales.

Ce plugin ne fourni aucune boucle, modèle ou squelette. Il met à jour l’information dans les tables spip_sitra_* (voir plus loin), fourni l’interface vers ces tables de façon à pouvoir utiliser le langage de boucles propre à spip (avec jointures également), gère les images locales importées ou distantes, fourni certains fonctions simples d’affichage des données recueillies, crée un objet spip SITRA_OBJET permettant un squelette propre pour les objets sitra (sitra_objet.html) que l’on pourra appeler par #URL_SITRA_OBJET et donc bénéficier des différents styles d’urls.

À vous de construire les squelettes, modèles et formulaires adaptés à votre cas. (Un exemple de test est cependant inclus dans le répertoire du même nom). L’utilisation de modèles peut être intéressante, elle permet d’afficher les informations sur la base d’un site « ordinaire » basé sur SPIP, site multilingue ou pas. On pourra aussi développer des noisettes spécifiques utilisables avec le plugin complémentaire Selecteur de noisettes pour SITRA.

Configuration

1. Installer le plugin et cfg (nécessaire).

2. Créer deux dossiers l’un à la racine de spip destiné à recevoir les fichiers d’export (/sitra par exemple) et l’autre destiné à recevoir les images à l’intérieur du dossier /IMG (sinon les filtres image_* ne fonctionneront pas) et lui donner tous les droits (comme ceux du dossier /IMG)

Paramétrage client SITRA

3. Créer une page dont le nom importe peu dans /squelettes (sitra_toto.html). L’url de cette page http://monsite.ext/spip.php?page=sitra_toto sera renseignée dans le client SITRA, afin qu’une requête soit générée sur celle-ci en fin d’export pour déclencher le traitement des fichiers xml exportés (voir copie écran ci-jointe). Coller le code suivant dans le contenu de ce squelette #CACHE{0}<INCLURE{fond=inclure/sitra_maj}>

Formulaire de configuration

4. Accéder à la page de configuration cfg du plugin et remplir les différents champs.
En mode production un email de rapport peut être envoyé à l’issue de chaque traitement d’export.
En mode debugage, une requête sur la page de déclenchement du traitement affichera l’ensemble des données recueillies.

Interface

Une interface de contrôle est disponible dans le menu Édition de la partie privée. Celle-ci affiche les contenus des différentes tables sitra_* et les détails sur un objet. Voir les différentes captures ci-dessous.

Page des sélections importées
Page des catégories des objets importés
Liste des objets d’une catégorie
Détail d’un objet
Recherche


Les boucles et balises disponibles

Le plugin crée un certain nombre de tables (7 au total). Le contenu de certains champs est un tableau sérialisé afin de pouvoir contenir plusieurs email ou fax ou téléphone par exemple. (Un jeu de fonctions sont disponibles pour le traitement, voir plus loin).

Table sitra_objets table principale

id_sitra_objet (un entier auto-incrément du type id_article)
id_sitra (un varchar du type sitraHLO311878)
titre
adresse  (sérialisé)
commune
code_postal
insee
telephone (sérialisé)
fax (sérialisé)
tel_fax (sérialisé)
email (sérialisé)
web (sérialisé)
date_debut
date_fin
latitude
longitude
altitude
classement_orga (organisme de classement)
classement_code (code de classement)
classement (en clair ex: 3 épis)
reservation_url (sérialisé, url du ou des pages de réservation)

Table sitra_objets_details (contient les données afférentes à un objet sitra, susceptibles d’êtres traduites en plusieurs langues)
Clé primaire = couple id_sitra, lang

id_sitra
lang
titre_lang (titre éventuellement traduit)
lieu
description
description_courte
observation_dates
tarifs_en_clair
tarifs_complementaires
presta_accessibilite  (sérialisé)
presta_activites  (sérialisé)
presta_confort (sérialisé)
presta_encadrement (sérialisé)
presta_equipements (sérialisé)
presta_services (sérialisé)
presta_sitra (sérialisé)
langues (sérialisé)
capacites (sérialisé)
carte_plan (notes explicatives du plan d'accès)
ouverture_en_clair (notes sur les dates d'ouverture)
bons_plans (comme son nom l'indique)
accueil (note sur les capacités généralement)

Pour récupérer les données sur un objet on peut donc construire la boucle

<BOUCLE_a (SITRA_OBJETS sitra_objets_details){id_sitra = ….}{lang}>
	#TITRE #DESCRIPTION ...
</BOUCLE_a>

ou

<BOUCLE_a (SITRA_OBJETS sitra_objets_details){id_sitra_objet}{lang}>
	#TITRE #DESCRIPTION ...
</BOUCLE_a>

Le paramètre lang est fourni dans l’environnement par spip pour tous les squelettes, noisettes et modèles par défaut sans avoir à le passer explicitement. Il doit être présent comme critère pour la bonne sélection des champs de la table sitra_objets_details, celle-ci ayant comme clé primaire le couple (id_sitra, lang)

Table sitra_selections permet de sélectionner les objets appartenant à une ou plusieurs sélections à partir de l’identifiant de celle-ci ou de son nom.

id_sitra
id_selection (entier généré par SITRA)
selection (nom de la sélection, normalisé au moment de l'import par suppression des caractères type espace, apostrophe et autres du même type)

Les jointures sur cette table sont automatiques, on pourra donc écrire de façon à obtenir tous les objets d’une sélection donnée

<BOUCLE_a (SITRA_OBJETS sitra_objets_details){selection=…}{lang}>
	#TITRE #DESCRIPTION ...
</BOUCLE_a>

ou

<BOUCLE_a (SITRA_OBJETS sitra_objets_details){id_selection=xxx}{lang}>
	#TITRE #DESCRIPTION ...
</BOUCLE_a>

Table sitra_categories pour sélectionner les objets appartenant à une ou plusieurs sélections à partir de l’identifiant de celle-ci ou de son nom.

id_sitra 
id_categorie (un code défini par SITRA - ex 02.01.05 pour l'hotellerie)
categorie (le nom de la catégorie normalisé)

Exemples de boucles

<BOUCLE_a (SITRA_OBJETS sitra_objets_details){categorie=hotellerie}{lang}>
	#TITRE #DESCRIPTION ...
</BOUCLE_a>

ou

<BOUCLE_a (SITRA_OBJETS sitra_objets_details){id_categorie=02.01.05}{lang}>
	#TITRE #DESCRIPTION ...
</BOUCLE_a>

Table sitra_criteres contient les critères internes définis par l’office (par exemple pour définir les adhérents à l’Office). Ces critères sont propres à chaque office. Seule leur Id est enregistrée (Id générée au moment de la création du critère)

id_sitra
id_critere

D’où les boucles du même style que celles-ci-dessus.

Les images et autres multimédia

Les multimédia du type image (principale, secondaire ou logo), plan, texte et son sont gérés par le plugin. Les images principales peuvent être importés dans un zip (traitement au moment de l’export) et déplacées dans le dossier /IMG/images_sitra/ défini dans le paramétrage. Certaines images principales et tous les autres types sont distants.

Comme les objets, les données sont réparties en deux tables.

Table sitra_docs

id_sitra
num_doc numéro du doc (pour chaque objet)
url_doc
type_doc (principale, secondaire, logo, plan, texte, son)
lien (0 "au majuscule" ou N pour les documents distants)
extension (extension du fichier - jpg,...)

Table sitra_docs_details

id_sitra varchar
num_doc
lang
titre
descriptif
copyright

Exemple de boucle

<BOUCLE_a(SITRA_DOCS){id_sitra}{type_doc IN principale,secondaire}>
	<BOUCLE_b(SITRA_DOCS_DETAILS){id_sitra}{num_doc}{lang}>
		[(#URL_DOC|url_doc_sitra{#LIEN}|image_reduire{150})]
	</BOUCLE_b>
</BOUCLE_a>

Le filtre |url_doc_sitra gère automatiquement le type d’image, locale ou distante en lui passant le paramètre lien. On peut appliquer derrière tous les traitements image_* disponibles dans spip.

Pour les documents autres que image (principale, secondaire ou logo), un modèle doc_sitra est fourni par le plugin conforme au modèle « doc » en dl, dt, dd des documents de spip.

Pour utiliser ce modèle on pourra utiliser la boucle :

[<!-- (#REM) afficher les documents de type plan -->]
<BOUCLE_doc_plan (SITRA_DOCS){id_sitra}{type_doc=plan}>
	[(#MODELE{doc_sitra, align=left, id_sitra, num_doc, lang})]
</BOUCLE_doc_plan>

Tous les paramètres sont obligatoires, align=left ou right ou center.

Note : Spip n’autorise pas de critère doublons sur les tables non pourvues d’un champ index primaire unique. Sur les boucles SITRA_DOCS, on utilisera donc plutôt des critères IN ou !IN.

l’objet SITRA_OBJET

On bénéficie d’un objet SITRA_OBJET qui correspond à u squelette spécifique sitra_objet.html. La logique est la même que pour les autres objets de spip (articles, rubriques,…). On construira le squelette sitra_objet.html avec une boucle englobante du type :

<BOUCLE_a (SITRA_OBJETS sitra_objets_details){id_sitra = ….}{lang}>
	structure de la page html
	....
</BOUCLE_a>

et cette page pourra être appelée dans une boucle par :

<BOUCLE_a (SITRA_OBJETS){categorie=hotellerie}{lang}>
	[<li><a href="[(#URL_SITRA_OBJET|parametre_url{lang,#ENV{lang}})]">(#TITRE)</a></li>]
</BOUCLE_a>

Dans le cas d’un site monolingue on pourra ne pas passer le paramètre de langue, dans les autres cas il faut passer ce paramètre pour la récupération des données localisées (titre_lang, descriptif,…).

Filtres disponibles

|url_doc_sitra{#LIEN} appliqué à #URL_DOC (voir plus haut) le paramètre #LIEN est obligatoire.

|normalise_nom par exemple [(#CLASSEMENT|normalise_nom)] transforme « 3 épis » en « 3-epis ». Supprime les caractères accentuées, remplace tout caractère non alphanumérique par un tiret -. Ce filtre peut être utilisé pour remplacer une expression par une image.

|sitra_expand_liste appliqué aux données sérialisées par exemple :
[(#PRESTA_CONFORT|sitra_expand_liste)], affiche la liste d’éléments séparés par un tiret. (Piscine - Terrasse - ...)
Le délimiteur peut être passé en paramètre [<ul><li>(#PRESTA_CONFORT|sitra_expand_liste{</li><li>})</li></ul>] permettra d’afficher cette donnée sous forme d’une liste à puce.
S’applique à toutes les données sérialisées.

Dans le même style :
|sitra_expand_telephone en normalisant les numéros de téléphone ou de fax
|sitra_expand_email pour les emails en générant une balise a avec la classe spip_mail. En outre les adresses peuvent être « codées » par [(#EMAIL|sitra_expand_email{'',1})]
|sitra_expand_web en générant des liens avec la class spip_out et un rel=« external »

Pour les dates
#DATE_DEBUT|sitra_date_debut_fin{#DATE_FIN , format, horaire}
exemple : [(#DATE_DEBUT|sitra_date_debut_fin{#DATE_FIN})]
Par défaut les dates sont affichées avec les horaires et au format jour_court si on veut le format complet, sans les horaires indiquer : [(#DATE_DEBUT{sitra_date_debut_fin{#DATE_FIN, complet, non})]

Ainsi que
[(#DATE_DEBUT|sitra_date_ical{#DATE_FIN})] pour les dates au format ical. La fonction retourne le couple DTSTART et DTEND.

et
[(#DATE_DEBUT|sitra_date_UTC{#DATE_FIN})] pour les Google agenda du type 20110912/20111003 ou 20111103T083000Z/20111103T083000Z (jour entier ou pas).

Notes diverses

Ce plugin est mis à disposition sous licence GNU GPL par le Sivu des Inforoutes de l’Ardèche

Ce plugin est encore en version test. Il est disponible sur la zone par SVN. Tant qu’il n’est pas en version 1 stable, les champs et structures des tables sont susceptibles de bouger sans mécanisme de mise à jour automatique entre versions.

Exemple de mise en œuvre ici.

Discussion

6 discussions

  • 5

    Plug très intéressant :) Quid de sa version 3 ? Merci

    • Comme sitra évolue en version 2 en abandonnant la structuration xml des exports pour passer à json, mais que cela ne sera défini et stabilisé qu’en mars prochain (2013), tant qu’à adapter et passer en version 3, autant que ce soit avec cette nouvelle version de sitra.

    • Bonjour ;-)

      des nouvelles du passage éventuel en v3 avec l’import en json ?

    • Bonjour

      Dans l’ordre ce serait déjà de passer à la v2 de sitra avec la v2 de spip (faut tenir compte du parc installé). L’idée est de ne pas trop faire bouger la base et de reprendre simplement le parseur. Il y a des choix à faire et des compromis à trouver (notamment json ou xml qui est maintenu aussi et le sera mais dérivé de json).
      Pour cela l’échéance est claire sitra v1 s’arrête fin janvier 2014 en principe.

      Ensuite v2 de sitra avec v3 de spip.

    • Très juste.

    • bonjour,
      quelqu’un a t-il essayer de faire évoluer le plugin pour la nouvelle version de sitra ?

    Répondre à ce message

  • 1

    hello ;-)
    je reprends le développement
    je n’arrive pas à me débarrasser d’une erreur, avec le filtre email : (#EMAIL

    2 erreurs ;
    Warning : Invalid argument supplied for foreach() in .../httpdocs/plugins/sitra_exports/sitra_fonctions.php on line 135 (et idem on line 143)

    tu n’as pas ce souci ?

    • Non je n’ai pas de problèmes. Quelle version du plugin ? que donne l’affichage de #EMAIL** ?

      Ce serait mieux de pouvoir correspondre en privée sur ce point pour ne pas polluer le forum avec cette question de mise au point.

    Répondre à ce message

  • 1

    Bonjour,

    Est-il possible d’afficher uniquement des événements bien ciblés du type « spectacles concerts... » ou est ce que l’on trouverait tout et rien en travers ? Merci de votre réponse.
    Peut-on utiliser le système avec le plugin agenda de sorte que l’on puisse effectuer un tri sur les dates ?

    • Cela dépend des sélections faites pour les éléments à importer (on peut aussi travailler sur les catégories), mais cela reste possible effectivement. je ne comprends pas bien ce que viens faire le plugin agenda ici..

      Pour effectuer des tri sur les dates pas besoin du plugin agenda, spip manipule très bien ce genre de données et le critère age_debut (avec la façon dont les dates sont définies faut pas trop compter sur age_fin pour le moment, ce serait à normaliser au moment de l’import pour pouvoir utiliser ce dernier critère). Pour afficher correctement les dates tu as le filtre sitra_date_debut_fin, mais rien n’empêche de se construire son propre filtre pour cela si il ne convient pas.

    Répondre à ce message

  • 1

    Est-il prévu de pourvoir ajouter à la main (sur l’admin de spip) un objet ? il y a parfois des ajouts (événement par exemple) à faire à Sitra... ou même des modifications, et le fait d’avoir plusieurs tables rend la saisie phpmyadmin trop difficile.

    • Pourquoi pas un peu plus tard, mais avant le but est pour moi de faire la v1 en ayant stabilisé la structure des tables (par exemple je me pose la question de renommer les tables « sitra_images » en « sitra_docs » car on peut avoir d’autres types de fichiers, de récupérer l’extension également,...).

      Après cela me semble difficile de gérer l’ajout de n’importe quel type d’objet, mais les événements pourquoi pas, le soucis étant alors du côté gérer le multilinguisme ou pas ? Après tout cela peut faire l’objet d’un autre plugin (pour pas trop compliquer celui-ci et séparer les rôles, ce que permettent justement les plugins, et pour rester dans la philosophie de ceux-ci). Si la structure des tables est ok, y aura pas de soucis.

    Répondre à ce message

  • Je ne sais pas pourquoi, mais mon ficher sélection est vide chaque jour, mais je vais regarder ça.

    Pour la question des multiples exports : c’est aussi (en dehors du fait que mon site peux très bien ne pas répondre un jour à l’appel du client sitra...) que je ne peux les envoyer directement sur mon serveur, car le client sitra n’accepte pas de paramètre de port pour la connexion ftp, or mon hébergement l’impose... d’où un peu de bidouille et de recopie de fichier, mais rien de rgave.

    je vais suivre ce plugin ;-)

    Répondre à ce message

  • 1

    bon ben... c’est génial ;-)

    voila qui simplifie grandement ma vie et sûrement à court terme celles d’autres personnes ;-)

    Je suis en cours de test du plugin, ça va pas mal du tout... juste 2 remarques peu importantes :

    -  si on a plusieurs fichiers d’export sitra le même jour, la MAJ n’en prend qu’un (le 1er par ordre alphabétique). Or parfois des bugs ou erreurs web se produisent... il serait pas mal de faire une boucle pour vérifier s’il en y a plusieurs ?

    -  j’ai supprimé les contrôles à chaque étape (qui vérifient qu’il n’y a pas erreur), car toujours pour la même raison, on a parfois des fichiers vides (c’est mon cas pour les « sélections » et ça interrompait le travail. Exemple, il peut n’y avoir rien à supprimer mais quelque chose à importer ;-)

    Je poursuis mes tests, mais bravo déjà !

    • Merci
      Attention les tables sont susceptibles d’évolutions... c’est encore en test. Il vaut mieux suivre le svn.

      Je suis un peu étonné. Il n’y a qu’un export par jour (nuit) et il est traité immédiatement à la fin de celui-ci si tu renseignes l’url à requêter dans le client SITRA.

      Les erreurs ne prennent pas en compte les fichiers « vides » mais l’absence de fichier. Même si il n’y a rien à supprimer le fichier del_xxx est transmis mais vide, ça passe très bien pour moi.
      Et il te faut au moins une sélection non ? Pas besoin de la modifier tous les jours. A la limite avec le plugin tu peux n’avoir qu’une sélection générale et ensuite gérer tout sur le site par les catégories des objets récupérés. (ou un mode mixte).

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom