Configuration et utilisation du ZOO-Kernel

Table des matières

• Configuration et utilisation du ZOO-Kernel
  • Configuration du ZOO-Kernel
  • Tester votre installation de ZOO avec le GetCapabilities

Configuration du ZOO-Kernel

Comme nous l’avons dit en introduction, l’image iso fournie a été démarrée sur votre ordinateur, vous permettant d’utiliser le ZOO-Kernel directement dans un environnement de développement.

Note

nous utiliserons ZOO-Kernel et le script zoo_loader.cgi sans distinction dans ce document.

Les paramètres généraux du ZOO-Kernel sont définis dans le fichier main.cfg situé dans le même répertoire que le ZOO-Kernel, donc dans /usr/lib/cgi-bin/. Vous pouvez voir le contenu d’un main.cfg basique ci-dessous :

[main]
lang=en-US,fr-FR,ja-JP
version=1.0.0
encoding=utf-8
serverAddress=http://localhost/cgi-bin/zoo_loader.cgi
dataPath=/var/data
tmpPath=/var/www/mapmint/temp
tmpUrl=/mapmint/temp
cacheDir=/var/www/cache/
mapserverAddress=http://localhost/cgi-bin/mapserv
msOgcVersion=1.0.0

[identification]
title=Atelier ZOO-Project - FOSS4G-FR 2014
keywords=WPS,GIS,buffer
abstract=Création d'une application web de recherche de plus courts chemins basée sur la norme WPS
accessConstraints=none
fees=None

[provider]
positionName=Developer
providerName=ZOO-Project
addressAdministrativeArea=Lattes
addressDeliveryPoint=1280 Av. des Platanes
addressCountry=fr
phoneVoice=+33670082539
addressPostalCode=34970
role=Dev
providerSite=http://www.zoo-project.org
phoneFacsimile=False
addressElectronicMailAddress=gerald.fenoy@geolabs.fr
addressCity=Lattes
individualName=Gérald FENOY

Le fichier main.cfg contient les informations de métadonnées à propos de l’identification et du fournisseur mais aussi des paramètres importants. Le fichier est composé de différentes sections, à savoir [main], [identification] et [provider] par défaut.

Dans la section [main] les paramètres sont les suivants :

• lang: les langues supportées, séparées par une virgule (la première est celle par défaut),

• version: la version du WPS supportée (uniquement 1.0.0 pour l’instant),

• encoding: l’encodage par défaut des réponses WPS,

• serverAddress: l’url pour accéder à votre instance du ZOO-Kernel (automatiquement mis à jour à l’exécution),

• dataPath: le chemin pour stocker les fichiers de données (utile

  uniquement lorsque le support MapServer est activé, ce répertoire est utilisé pour stocker les mapfiles et les données),

• tmpPath: le chemin pour stocker les fichiers temporaires (par exemple pour une requête ExecuteResponse ayant le paramètre storeExecuteResponse défini à true),

• tmpUrl: une url relative au serverAddress pour accéder au fichier temporaire

• cacheDir: le chemin pour stocker les fichiers de requête mis en cache [1] (optionnel),

• mapservAddress: l’adresse de votre MapServer locale (optionnel, utile quand le support MapServer est activé),

• msOgcVersion: la version pour toutes les sorties des services Web OGC supportées [2] (optionnel).

Les sections [identification] et [provider] sont spécifiques à la métadonnée OGC et devraient être définies [3].

Bien entendu, vous êtes libres d’ajouter de nouvelles sections à ce fichier si vous avez besoin. Néanmoins, vous devez savoir qu’il y a quelques noms spécifiques, que vous ne devez utiliser que pour des besoins bien spécifiques: [headers], [mapserver], [env], [lenv] et [senv].

Warning

[senv] et [lenv] sont des sections utilisées et générées à l’exécution par le ZOO-Kernel et ne devraient être modifiées qu’au niveau du code des services.

La section headers est utilisée pour définir des entêtes HTTP personnallisées (par exemple X-Powered-By: Zoo-Project@Trac).

Warning

Il n’y a aucune raison de définir des en-têtes de base tels que Content-Type ou encoding étant donné qu’elles seront écrasées à l’exécution par le ZOO-Kernel.

La section mapserver est utilisée pour stocker des paramètres de configuration mapserver spécifiques comme PROJ_LIB et GDAL_DATA ou n’importe quel autre que vous vouliez définir pour faire fonctionner votre MapServer.

Note

La section mapserver est uniquement utilisée sur des plateformes WIN32

La section env est utilisée pour stocker les variables d’environnement spécifiques que vous souhaitez mettre en avant pour charger votre fournisseur de services et pour exécuter votre service. Un exemple typique, c’est quand votre service nécessite d’accéder à un serveur X fonctionnant sur ​​framebuffer, alors vous aurez à définir la variable d’environnement DISPLAY, dans ce cas, vous devez ajouter la ligne DISPLAY=:1 dans votre section [env].

La section lenv est utilisée pour stocker les informations d’exécution rassemblées par le ZOO-Kernel avant de lancer votre service, l’ensemble des clés définies sont les suivantes :

• sid: l’identifiant unique du service,
• status: a valeur de progression actuelle (valeur entre 0 et 100, pourcents),
• cwd: le répertoire de travail courant du ZOO-Kernel,
• message: un message d’erreur quand SERVICE_FAILED est retourné (optionnel),
• cookie: le cookie que votre service veut retourner au client (à des fins de suivi ou d’authentification).

La section senv est utilisée pour stocker les informations de session côté serveur. Vous pouvez ainsi y accéder automatiquement depuis le service si le serveur est interrogé en utilisant un cookie valide (comme défini dans lenv > cookie). Le ZOO-Kernel stockera sur le disque les valeurs définies dans la liste clé-valeur de senv, puis les chargera et ajoutera dynamiquement leur contenu à celui disponible dans le main.cfg. La section senv devrait contenir au moins:

• XXX: l’identifiant de session unique où XXX est le nom inclus dans le cookie renvoyé.

Par exemple, si vous avec ce qui suit dans votre code source de Service [4] :

conf["lenv"]["cookie"]="XXX=XXX1000000; path=/"
conf["senv"]={"XXX": "XXX1000000","login": "demoUser"}

Cela signifie que le ZOO-Kernel créera un fichier sess_XXX1000000.cfg dans le cacheDir et retournera le cookie spécifié au client. Chaque fois que le client interrogera le ZOO-Kernel en utilisant ce même cookie, il chargera automatiquement la valeur stockée avant d’exécuter votre service. Vous pouvez ensuite accéder facilement à ces informations à partir de votre code source de service. Cette fonctionnalité ne sera pas utilisée dans cet atelier.

Tester votre installation de ZOO avec le GetCapabilities

Vous pouvez interroger le ZOO-Kernel en utilisant le lien suivant depuis votre navigateur Internet:

http://localhost/cgi-bin/zoo_loader.cgi?Request=GetCapabilities&Service=WPS

Vous devriez obtenir un document XML Capabilities valide, ressemblant à ce qui suit :

Notez que certains noeuds de processus sont retournés dans la section ProcessOfferings, étant donné que certains services sont déjà disponibles dans l’image iso utilisée. Vous pouvez également exécuter une requête GetCapabilities en ligne de commande, en utilisant la commande suivante:

cd /usr/lib/cgi-bin
./zoo_loader.cgi "request=GetCapabilities&service=WPS"

Le même résultat que dans votre navigateur sera retourné, comme montré dans la capture d’écran suivante:

Invoquer le ZOO-Kernel depuis la ligne de commande peut être utile pendant le processus de développement de nouveaux services.

Footnotes

[1]

lorsque vous utilisez les requêtes GET passées via xlink:href, le ZOO Kernel-exécutera la demande une seule fois, la première, et il stockera sur le disque le résultat. La prochaine fois que vous aurez besoin de la même ressources, le fichier de cache sera utilisé pour exécuter votre service le rendant plus rapide. Si cacheDir n’a pas été précisé dans le fichier main.cfg alors la valeur de tmpPath sera utilisée.

[2]

depuis la version 1.3-dev, quand MapServer est activée, votre service peut automatiquement retourner une requête WMS, WFS ou WCS pour exposer vos données. Vous pouvez définir ici le numéro de version spécifique que vous souhaitez utiliser pour interroger la configuration de votre MapServer local. Il dépend surtout de la capacité du client à gérer la version spécifique des services Web OGC.

[3]	depuis la version 1.3dev, quand MapServer est activé, les mêmes métadonnées seront utilisées pour définir les métadonnées pour les services Web OGC.

[4]	Si vous n’êtes pas familier avec le ZOO-projet, vous pouvez passer cette partie et y revenir après la section suivante.