The ZOO-Service configuration file (.zcfg) describes a
WPS service. It provides metadata information on a particular WPS
Service and it is parsed by ZOO-Kernel when DescribeProcess and
Execute request are sent.

The ZOO-Service configuration file is divided into three distinct sections :

The fist part of the ZOO-Service configuration file is the main section,
which contains general metadata information on the related WPS
Service.

Note that the “name of your service” between brackets on the first line has to be the exact same name
as the function you defined in your services provider code. In most cases, this name is also the name
of the ZCFG file without the “.zcfg” extension.

An example of the main section is given bellow as reference.

1
2
3
4
5
6
7
8
9
10
11

[Name of WPS Service]
Title = Title of the WPS Service
Abstract = Description of the WPS Service
processVersion = Version number of the WPS Service
storeSupported = true/false
statusSupported = true/false
serviceType = Pprogramming language used to implement the service (C|Fortran|Python|Java|PHP|Ruby|Javascript)
serviceProvider = Name of the Services provider (shared library|Python Module|Java Class|PHP Script|JavaScript Script)
<MetaData>
title = Metadata title of the WPS Service
</MetaData>

Warning

‘Name of WPS Service’ must be the exact same name as the function defined in the WPS Service source code.

<DataInputs>
[Name of the first input]
Title = Title of the first input
Abstract = Abstract describing the first input
minOccurs = Minimum occurence of the first input
maxOccurs = Maximum occurence of the first input
<Type Of Data Node />
[Name of the second input]
Title = Title of the second input
Abstract = Abstract describing the second input
minOccurs = Minimum occurence of the second input
maxOccurs = Maximum occurence of the second input
<Type Of Data Node />
</DataInputs>

Note

A <MetaData> node can also be added, as in the main metadata information.

zero or more <Supported> nodes depending on the existence or the number of supported Units Of Measure (UOM), and

a dataType property. The dataType property defines the type of literal data, such as a string, an interger and so on
(consult the complete list of supported data types).

<Default> and <Supported> nodes can contain the uom property to define which UOM has to be used for
this input value.

For input <LiteralData> nodes, you can add the value property to the <Default> node to define a default
value for this input. This means that, when your Service will be run, even if the input wasn’t defined, this default
value will be set as the current value for this input.

A typical <LiteralData> node, defining a float data type using meters or degrees for its UOM, looks like the
following:

one or more <Supported> nodes depending on the number of supported formats. A format is made up of this
set of properties : mimeType, encoding and optionaly schema.

For output ComplexData nodes, you can add the extension property to define what extension to use to name
the file when storing the result is required. Obviously, you’ll have to add the extension property to each
supported format (for the <Default> and <Supported> nodes).

You can also add the asReference property to the <Default> node to define if the output should be
stored on server side per default.

Note

the client can always modify this behavior by setting asReference attribute to true or false
for this output in the request ResponseDocument parameter.

You can see below a sample ComplexData node for default application/json and text/xml (encoded in UTF-8
or base64) mimeTypes support: