source: trunk/docs/services/process-profiles.rst @ 763

.. _process-profiles:
    
Process profiles registry
=========================

WPS Services belonging to the same Services provider often share the
same inputs and outputs. In such a case, every :ref:`ZCFG
<services-zcfg>` file would contain the same metadata information and
this may be a waste of time to write them all.

:ref:`ZOO-Kernel <kernel_index>` is able to handle metadata
inheritance from `rev. 607
<http://www.zoo-project.org/trac/changeset/607>`__, and this solves
the issue of writing many ZCFG with same input and output. A registry
can be loaded by the ZOO-Kernel (before any other ZCFG files) and
contain a set of Process Profiles organized in hierarchic levels
according to the following rules:

  * *Concept*: The higher level in the hierarchy. *Concepts* are basic
    text files containing an abstract description of a WPS Service
    (see `the OGC definition
    <http://docs.opengeospatial.org/is/14-065/14-065.html#33>`_ for
    more details).
  * *Generic*: A *Generic* profile can make reference to
    *Concepts*. It defines inputs and outputs without data format or
    maximum size limitation (see `the OGC definition
    <http://docs.opengeospatial.org/is/14-065/14-065.html#34>`_ for
    more details).
  * *Implementation*: An *Implementation* profile can inherit from a
    generic profile and make reference to concepts (see `the OGC definition
    <http://docs.opengeospatial.org/is/14-065/14-065.html#35>`_ for
    more details). It contains all the metadata information about a
    particular WPS Service (see :ref:`ZCFG reference <services-zcfg>`
    for more information).

Both *Generic* and *Implementation* process profiles are created  from
:ref:`ZCFG <services-zcfg>` files and stored in the registry
sub-directories according to their level (*Concept*, *Generic* or
*Implementation*).

To activate the registry, you have to add a ``registry`` key to the
``[main]`` section of your ``main.cfg`` file, and set its value to the
directory path used to store the profile ZCFG files. Please see
:ref:`install_gfr` for more details about the other services and
parameters required.

.. note::
    Even if the profile registry was first introduced in WPS 2.0.0, it
    can be also used in the same way for WPS 1.0.0 Services.




Generic Process Profile
-----------------------

A Generic Process Profile is a ZCFG file located in the ``generic``
sub-directory, it defines `main metadata information
<zcfg-reference.html#main-metadata-information>`__, inputs and outputs
name, basic metadata and multiplicity. It can make reference to a
concept by defining a ``concept`` key in the `main metadata
information <zcfg-reference.html#main-metadata-information>`__ part.

You can find below the `GO.zcfg` file, a typical Generic Process
Profile for Generic Geographic Operation, taking one InputPolygon
input parameter and returning a result named Result, it make reference
to the ``GOC`` concept:

.. code-block:: none
   :linenos:
   
   [GO]
    Title = Geographic Operation
    Abstract = Geographic Operation on exactly one input, returning one output
    concept = GOC
    level = generic
    statusSupported = true
    storeSupported = true
    <DataInputs>
     [InputPolygon]
      Title = the geographic data
      Abstract = the geographic data to run geographipc operation
      minOccurs = 1
      maxOccurs = 1
    </DataInputs>
    <DataOutputs>
     [Result]
      Title = the resulting data
      Abstract = the resulting data after processing the operation
    </DataOutputs>  


.. Note:: if you need to reference more than one concept, you should
    separate their names with a comma (ie. concept = GO,GB),

Process Implementation Profile
------------------------------

A Process Implementation Profile is similar to a `ZCFG file
<zcfg-reference.html>`__ located in the `implementation`
sub-directory, it defines (or inherit from its parent) all the
properties of a `Generic Process Profile <#generic-process-profile>`__
and specify `Data Format <zcfg-reference.html#type-of-data-nodes>`__
for both inputs and outputs. It can make reference to a concept by
defining a ``concept`` key in the `main metadata information
<zcfg-reference.html#main-metadata-information>`__ part.

You can find below the `VectorOperation.zcfg` file, a typical Process
Implementation Profile for Vector Geographic Operation, it inherit
from the `GP generic profile <#generic-process-profile>`__:

.. code-block:: none
   :linenos:
   
   [VectorOperation]
    Title = Vector Geographic Operation
    Abstract = Apply a Vector Geographic Operation on a features collection and return the resulting features collection
    extend = GO
    level = profile
    <DataInputs>
     [InputPolygon]
      Title = the vector data
      Abstract = the vector data to run geographic operation
      <ComplexData>
       <Default>
        mimeType = text/xml
        encoding = UTF-8
        schema = http://fooa/gml/3.1.0/polygon.xsd
       </Default>
       <Supported>
        mimeType = application/json
        encoding = UTF-8
        extension = js
       </Supported>
    </DataInputs>
    <DataOutputs>
     [Result]
      Title = the resulting data
      Abstract = the resulting geographic data after processing the operation
      <ComplexData>
       <Default>
        mimeType = text/xml
        encoding = UTF-8
        schema = http://fooa/gml/3.1.0/polygon.xsd
       </Default>
       <Supported>
        mimeType = application/json
        encoding = UTF-8
        extension = js
       </Supported>
      </ComplexData>
    </DataOutputs>  


ZCFG inheritance
----------------------------------

For the ZCFG files at the service level, you can inherit the metadata
from a Process Implementation Profile available in the registry. As
before, you simply need to add a ``extend`` key refering the ZCFG you
want to inherit from and a ``level`` key taking the `ìmplementation``
value to your main metadata informations.

So, for example, the original `ConvexHull.zcfg
<http://www.zoo-project.org/trac/browser/trunk/zoo-project/zoo-services/ogr/base-vect-ops/cgi-env/ConvexHull.zcfg?rev=491>`__
may be rewritten as:

.. code-block:: none
   :linenos:
   
   [ConvexHull]
    Title = Compute convex hull.
    Abstract = Return a feature collection that represents the convex hull of each geometry from the input collection.
    serviceProvider = ogr_service.zo
    serviceType = C
    extend = VectorOperation
    level = implementation

Now, suppose that your service is able to return the result in KML
format, then you may write the following:

.. code-block:: none
   :linenos:
   
   [ConvexHull]
    Title = Compute convex hull.
    Abstract = Return a feature collection that represents the convex hull of each geometry from the input collection.
    serviceProvider = ogr_service.zo
    serviceType = C
    extend = VectorOperation
    level = implementation
    <DataOutputs>
     [Result]
        <Supported>
         mimeType = application/vnd.google-earth.kml+xml
         encoding = utf-8
        </Supported>
    </DataOutputs>

.. _install_gfr:

Setup registry browser
----------------------

In the ``zoo-project/zoo-services/utils/registry``  you can find the
source code and the ``Makefile`` required to build the Registry Browser
Services Provider. To build and install this service, use the
following comands:

.. code::

     cd zoo-project/zoo-services/utils/registry
     make
     cp cgi-env/* /usr/lib/cgi-bin


To have valid
``href`` in the metadata children of a ``wps:Process``, you have to
define the ``registryUrl`` to point to the path to browse the
registry. For this you have two different options, the first one is to
install the ``GetFromRegistry`` ZOO-Service and to use a WPS 1.0.0
Execute request as ``registryUrl`` to dynamically generate `Process
Concept <http://docs.opengeospatial.org/is/14-065/14-065.html#33>`__,
`Generic Process Profile
<http://docs.opengeospatial.org/is/14-065/14-065.html#34>`__ and
`Process Implementation Profile
<http://docs.opengeospatial.org/is/14-065/14-065.html#35>`__.
You also have to add a ``registryUrl`` to the ``[main]`` section to
inform the ZOO-Kernel that it should use the Registry Browser to
create the href attribute of Metadata nodes. So by adding the
following line:

.. code::

    registryUrl = http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=GetFromRegistry&RawDataOutput=Result&DataInputs=id=

The second option is to pre-generate each level of the hierarchy by
running shell commands then set ``registryUrl`` to the URL to browse
the generated files. In such a case, you will also have to define the
``registryExt`` and set it to the file extension you used to generate
your registry cache.

To generate the cache in ``/opt/zoo/registry/``, use the following command:

.. code::

    cd /usr/lib/cgi-bin
    mkdir /opt/zoo/regcache/{concept,generic,implementation}
    for i in $(find /opt/zoo/registry/ -name "*.*") ; 
    do  
        j=$(echo $i | sed "s:../registry//::g;s:.zcfg::g;s:.txt::g") ; 
       if [ -z "$(echo $j | grep concept)" ]; 
       then 
           ext="xml" ; 
       else 
           ext="txt"; 
       fi
        ./zoo_loader.cgi "request=Execute&service=wps&version=1.0.0&Identifier=GetFromRegistry&RawDataOutput=Result&DataInputs=id=$j" | grep "<" > /opt/zoo/regcache/$j.$ext; 
    done