Configuration and ZOO-Kernel use

ZOO-Kernel Configuration

As already said in introduction, an OSGeoLive Virtual Machine has been booted on your computer, allowing you to use ZOO-Kernel in a development environment directly.

Note

we will use ZOO-Kernel or zoo_loader.cgi script without any distinction in this document.

General ZOO-Kernel settings are set in the main.cfg file located in the same directory as the ZOO-Kernel, so in /usr/lib/cgi-bin/. This informations will be accessible from each services at runtime, so when you wil use Execute requests. You can see a typical main.cfg content in the following:

 1[headers]
 2X-Powered-By=ZOO-Project@MapMint
 3
 4[main]
 5encoding=utf-8
 6dataPath=/var/data
 7tmpPath=/var/www/temp
 8cacheDir=/var/www/cache
 9version=1.0.0
10sessPath=/tmp
11msOgcVersion=1.0.0
12serverAddress=http://localhost/cgi-bin/mm/zoo_loader.cgi
13lang=fr-FR,ja-JP
14language=en-US
15mapserverAddress=http://localhost/cgi-bin/mapserv.cgi
16tmpUrl=http://127.0.0.1/temp/
17
18[identification]
19keywords=WPS,GIS,buffer,MapMint,ZOO-Project
20title=ZOO-Project Workshop - FOSS4G 2014
21abstract= Deploying Web Processing Services using ZOO-Project – Examples of Python based WPS using PgRouting
22accessConstraints=none
23fees=None
24
25[provider]
26positionName=Developer
27providerName=GeoLabs SARL
28addressAdministrativeArea=False
29addressDeliveryPoint=1280, avenue des Platanes
30addressCountry=fr
31phoneVoice=+33467430995
32addressPostalCode=34970
33role=Dev
34providerSite=http://www.geolabs.fr
35phoneFacsimile=False
36addressElectronicMailAddress=gerald@geolabs.fr
37addressCity=Lattes
38individualName=Gérald FENOY

The main.cfg file contains metadata informations about the identification and provider but also some important settings. The file is composed of various sections, namely [main], [identification] and [provider] per default.

From the [main] section settings are as follow:
  • lang: the supported languages separated by a coma (the first is the default one),

  • version: the supported WPS version,

  • encoding: the default encoding of WPS Responses,

  • serverAddress: the url to access your ZOO-Kernel instance,

  • dataPath: the path to store data files (when MapServer support was activated, this directory is used to store mapfiles and data).

  • tmpPath: the path to store temporary files (such as ExecuteResponse when storeExecuteResponse was set to true),

  • tmpUrl: a url relative to serverAddress to access the temporary file,

  • cacheDir: the path to store cached request files [1] (optional),

  • mapservAddress: your local MapServer address (optional),

  • msOgcVersion: the version for all supported OGC Web Services output [2] (optional).

The [identification] and [provider] section are specific to OGC metadata and should be set [3].

Obviously, you are free to add new sections to this file if you need more [4]. Nevertheless, you have to know that there is some specific names you should use only for specific purposes: [headers], [mapserver], [env], [lenv] and [senv].

Warning

[senv] and [lenv] are used / produced on runtime internaly by the ZOO-Kernel and should be defined only from the Service code.

The headers section is used to define your own HTTP Response headers. You may take a look at headers returned by web site such as http://www.zoo-project.org by using curl command line tool for instance and notice the specific heder X-Powered-By: Zoo-Project@Trac.

Warning

There is no reason to define basic headers such as Content-Type or encoding as they will be overwritten at runtime by the ZOO-Kernel.

The mapserver section is used to store specific mapserver configuration parameters such as PROJ_LIB and GDAL_DATA or any other you want to be set to make your MapServer working.

Note

the mapserver section is mainly used on WIN32 platform

The env section is used to store specific environment variables you want to be set prior to load your Services Provider and run your Service. A typical example, is when your Service requires to access to a X server running on framebuffer, then you will have to set the DISPLAY environnement variable, in this case you would add DISPLAY=:1 line in your [env] section.

The lenv is used to store runtime informations automatically set by the ZOO-Kernel before running your service and can be accesses / updated from it:

  • sid (r): the service unique identifier,

  • status (rw): the current progress value (value between 0 and 100, percent),

  • cwd (r): the current working directory of the ZOO-Kernel,

  • message (rw): an error message when returning SERVICE_FAILED (optional),

  • cookie (rw): the cookie your service want to return to the client (for authentication purpose or tracking).

The senv is used to store session informations on the server side. You can then access them automatically from service if the server is requested using a valid cookie (as defined in lenv > cookie). The ZOO-Kernel will store on disk the values set in the senv maps, then load it and dynamically add its content to the one available in the main.cfg. The senv section should contain at least:

  • XXX: the session unique identifier where XXX is the name included in the

    returned cookie.

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

That means that the ZOO-Kernel will create a file sess_XXX1000000.cfg in the cacheDir and return the specified cookie to the client. Each time the client will request the ZOO-Kernel using the Cookie, it will automatically load the value stored before running your service. You can then easilly access this informations from your service source code. This functionality won’t be used in the following presentation.

Testing the ZOO installation with GetCapabilities

Once you have a main.cfg file available in the same directory as your ZOO-Kernel, then you can use GetCapablities. Indeed, to answer such kind of requests, the ZOO-Kernel will simply parse the main.cfg file (to gather global informations), then parse individually each zcfg files (if any) contained in the same directory or in sub-directories [6], then return a well formed Capabilities document.

You can request ZOO-Kernel using the following link from your Internet browser:

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

You should get a valid Capabilities XML document, looking like the following :

../_images/GC2.png

Please note that some Process nodes are returned in the ProcessOfferings section, as somes are available already on OSGeoLive DVD. You can also run a GetCapabilities request from the command line, using the following command:

cd /usr/lib/cgi-bin
./zoo_loader.cgi “request=GetCapabilities&service=WPS” | less

The same result as in your browser will be returned, as shown in the following screenshot:

../_images/GC_CL2.png

Invoking ZOO Kernel from the command line can be helpful during development process of new Services for debugging purpose. If you need to simulate POST request from the command line, then you can use the following:

cd /usr/lib/cgi-bin
# Download the sample GetCapabilities request
curl -o /tmp/10_wpsGetCapabilities_request.xml http://schemas.opengis.net/wps/1.0.0/examples/10_wpsGetCapabilities_request.xml
# Define required environment settings
export REQUEST_METHOD=POST
export CONTENT_TYPE=text/xml
# Run the request downloaded
./zoo_loader.cgi < /tmp/10_wpsGetCapabilities_request.xml | less

You should have the same result as presented before.

Footnotes