Configuration et utilisation du ZOO-Kernel¶

Configuration du ZOO-Kernel¶

Pour télécharger et installer l’ensemble des outils nécessaires à la réalisation de cet atelier, veuillez saisir les commandes suivantes dans un terminal.

wget http://geolabs.fr/dl/ws2016-fr/zoo-ws-fr-2016.tar.bz2
sudo tar -xvjpf  zoo-ws-fr-2016.tar.bz2 -C /
sudo chown www-data:www-data -R /var/data

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 :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

[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 2016
keywords = WPS,GIS,buffer
abstract = Initiation à la création de services 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].

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

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.

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 afin de pouvoir les débuguer si nécessaire. Dans le cas où vous voudriez simuler l’invocation d’une requête POST en ligne de commande, vous pouvez utiliser les commandes suivantes :

cd /usr/lib/cgi-bin
# Télécharger le fichier de requête GetCapabilities
curl -o /tmp/10_wpsGetCapabilities_request.xml http://schemas.opengis.net/wps/1.0.0/examples/10_wpsGetCapabilities_request.xml
# Définir les variables d'environnement nécessaires
export REQUEST_METHOD=POST
export CONTENT_TYPE=text/xml
# Exécuter la requête téléchargée
./zoo_loader.cgi < /tmp/10_wpsGetCapabilities_request.xml | less

Vous devriez obtenir le même résultat que précédemment.

Footnotes