[Zoo-discuss] ZOO-Project OGC API - Processes User Interface

[Gérald Fenoy]

Dear all,
I am glad to present some enhancements that has been added lately on the ZOO-Project and especially the addition of a basic User Interface  (UI).

I made this UI available on this demo server [1], as said it is a really basic UI where one can browse the processes available from the /processes path [2], get detailed informations from the /process/{processId} path (i.e. using OTB.BandMath processId [3]) but also use this same page to produce the JSON Execute request to be sent to the ZOO-Kernel with OGC API - Processes activated.

Indeed, from this last part of the UI, users have an HTML form that can be used to configure the inputs, the outputs and other parameters to be sent. From this HTML form, complex data can be passed by reference only when literal input can be defined right from the corresponding field. To generated the JSON Execute request, one can click on the « Submit » button. Note that in case you did not define a required input properly, you will be prompted to fill them. 

Also, as we now get the callbacks [4] definition supported by the ZOO-Kernel, the UI is automatically defining a URL for successUri, inProgressUri and failedUri. The consequence is that the ZOO-Kernel will send the current status of the execution of a process to the defined Uris. Also, when one click on the « Submit job » button appearing in the modal, a web socket is used to get the up-to-date information about status of execution of a process. Note that the service implemented to handle this is a very trivial python code [5] using redis and a uuid generated by the ZOO-Kernel to keep track of whom the messages should be targeted to. We implemented the UI this way to illustrate how the callbacks can be used to avoid polling using the OGC API - Processes.

The UI uses the Cheetah Tempalte Engine [6] and will require that the display service [7] is installed on your server. Also, to simplify the URLs to access the OGC API - Processes I have added this .htaccess [8] sample to show how to setup the transparent invocation of the display service in case the URL ends with .html. You may notice that the rewrite rules defined in this file use the original URL to create a Xlink:href that is passed as an input to the display Service which is responsible to produce the HTML output. The display service also rely on the Cheetah template [9] which define the way data should be shown in the HTML layout. One more time, this HTML code is very basic and require improvement here and there.

Note that, by now, only the document value is acceptable for the response parameter in the JSON Execute request.

I hope you will appreciate the UI. I am more than open to any comment, enhancement request and so on.

I wish you a great day and a great week ahead.

Best regards,


[1] https://demo.mapmint.com/ogc-api/index.html
[2] https://demo.mapmint.com/ogc-api/processes.html
[3] https://demo.mapmint.com/ogc-api/processes/OTB.BandMath.html
[4] https://swagger.io/docs/specification/callbacks/
[5] http://www.zoo-project.org/trac/browser/trunk/zoo-project/zoo-services/utils/open-api/server/publish.py
[6] https://cheetahtemplate.org/
[7] http://www.zoo-project.org/trac/browser/trunk/zoo-project/zoo-services/utils/open-api/cgi-env
[8] http://www.zoo-project.org/trac/browser/trunk/zoo-project/zoo-services/utils/open-api/server/.htaccess
[9] http://www.zoo-project.org/trac/browser/trunk/zoo-project/zoo-services/utils/open-api/templates/index.html

Gerald Fenoy
Chair, ZOO-Project PSC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/zoo-discuss/attachments/20201102/aef7e0d2/attachment.html>