<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Gerald,<div><br></div><div>To summarize my previous email:<div><br></div><div>Is there any way to get access to additional information from within the process/service context. ? As of now, the processor receives three parameters (inputs,outputs, conf) and i am interested to know if there is a possibility to get access to run time information (like user-id, job id created by ZOO-Kernel, etc) within the processor context. Note that this information is not part of WPS Execute request (inputs,outputs).</div><div><br></div><div>If this is possible, then I don't need a middle layer between ZOO-client and ZOO-kernel.</div><div><br></div><div>Thanks<br><br><div><hr id="stopSpelling">From: rakeshuk@outlook.com<br>To: gerald.fenoy@geolabs.fr<br>Date: Fri, 10 Jun 2016 12:14:01 +0100<br>Subject: Re: [Zoo-discuss] ZOO-client and ZOO-API : concepts and usage<br>CC: zoo-discuss@lists.osgeo.org<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">Thanks Gerald for your quick response. <div><br></div><div>Let me explain my use case in detail: <span style="font-size:12pt;">A user will log in to our web portal and then can execute a WPS processing service. All the processors/algorithms/Zoo service are executed in Aysnc mode and all the processors create some directories (input dir and output directories) on file system as part of the processing. </span></div><div><br></div><div>The user has a unique ID and we manage a database with a table that captures user activity. Basically this table looks like below (column headers are separated by \\ )</div><div><br></div><div>user id \\ job id \\ job status \\ input dir \\ output dir</div><div><br></div><div>Note that WPS Execute request does not have input field for "user id". If I let the front end ZOO-Client talk directly to ZOO-kernel, I cannot access the user id. But by having a middle layer between front end and ZOO-kernel, I can forward used id (and other information) from the front end to back end which can then submit the WPS execute request to ZOO-kernel and also can update the database. </div><div><span style="font-size:12pt;"><br></span></div><div><span style="font-size:12pt;">I know the above reasoning may not be true because when I try to run "</span>manage-users.GetUsers" service as described by <a href="http://zoo-project.org/cgi-bin/zoo_loader1.cgi?request=execute&service=WPS&version=2.0.0&identifier=manage-users.GetUsers" target="_blank" style="font-size:12pt;">http://zoo-project.org/cgi-bin/zoo_loader1.cgi?request=execute&service=WPS&version=2.0.0&identifier=manage-users.GetUsers </a>, I got the exception saying "Unable to run the Service. The message returned back by the Service was the following: User not authenticated". I believe that ZOO-kernel relies on certain field in the HTTP(S) header (e.g. cookie) and accepts or rejects the execution request.</div><div><br></div><div>One thing I couldn't figure out is how to relate the directories created by the processor/service with the Job ID so that the database can be updated.</div><div><br></div><div>Thanks</div><div><span style="font-size:12pt;"> </span></div><div><div><br></div><div><br><br><div>> Subject: Re: [Zoo-discuss] ZOO-client and ZOO-API : concepts and usage<br>> From: gerald.fenoy@geolabs.fr<br>> Date: Fri, 10 Jun 2016 11:21:41 +0200<br>> CC: zoo-discuss@lists.osgeo.org<br>> To: rakeshuk@outlook.com<br>> <br>> Dear Rakesh,<br>> nice to hear from you.<br>> <br>> You will find my answers inline bellow.<br>> <br>> <br>> > Le 10 juin 2016 à 10:28, rakesh prithiviraj <rakeshuk@outlook.com> a écrit :<br>> > <br>> > Hi,<br>> > <br>> > I really appreciate if someone could help me in understanding the concepts behind ZOO-client and ZOO-API and the relation between them. Thanks for your time.<br>> > <br>> > Objective: Create a web front end that allows user to select a WPS processor and execute it. <br>> > <br>> > I had a look at ZOO-client (zoo.js, wps-payload.js, utils.js) and ZOO-api (ZOO-api.js, ZOO-proj4js.js) description and my understanding is that ZOO-client can create WPS requests (GetCapabilities, DescribeProcess, ExecuteRequest, DismissRequest) and can send it directly to ZOO-Kernel. ZOO-client uses mustache templates for this. We do not need ZOO-API at all for this sequence. Is it correct? Also ZOO-client can also dynamically build the form based on DescribeProcess response. <br>> > <br>> <br>> This is correct, no need for ZOO-API in the sequence you have described. It is also right to say that the ZOO-Client can create form based on DescribeProcess, it is the case of the otb-example.html demo you are referring later (note that it is also the same for other new demos such as the saga one).<br>> <br>> > Am i right to say that ZOO-api is server side equivalent of ZOO-client. This means ZOO-api can also generate WPS requests and can send it to ZOO-kernel. This means we can write simple web front that sends all the information (processor identifier, inputs, outputs etc.) that is required to create WPS requests to ZOO-API which then constructs the WPS requests and sends it to ZOO-Kernel. <br>> <br>> You are right saying that the ZOO-API is used server-side and that it can construct WPS requests and handle the communication with the ZOO-Kernel.<br>> <br>> > <br>> > In my use case, I do not want the web front end to talk directly to ZOO-kernel but it should send information (as JSON or XML) to some backend which then logs this user activity in database, performs few checks with the user account and then creates and submits the WPS requests to ZOO-Kernel. This same backend receives the WPS response from ZOO-Kernel and knows how to handle it. The backend again updates the database (user account, history etc.) and then sends the information to web front end. So the backend is the client for ZOO-Kernel and not the web front end. I am hoping that ZOO-API is the one that I need to use as backend.<br>> <br>> It is correct to say that you can use ZOO-API in you backend. Nevertheless, I don’t understand why you don’t want your web front end to communicate directly with the ZOO-Kernel. Indeed, in such a situation I feel the easiest way to go would be the following: create the backend client as a JavaScript service taking only one input (the JSON or XML content you were referring to), make your service invoking the required steps (user privileges checking for instance) prior to send WPS request, send it to the WPS server then handle it, at the end you can obviously invoke any other service / specific script to be run from the web server. <br>> <br>> The JavaScript ZOO-API can send WPS request but also more basic HTTP requests if required.<br>> <br>> > <br>> > If my understanding of ZOO-api is not correct, then I need to develop a backend in Java/PHP that should act as middle layer between web front end and ZOO-Kernel.<br>> > <br>> > Also I had a look at this example http://zoo-project.org/examples/otb-example.html. It looks very promising. Is the source code of this exampe available as open source?<br>> <br>> Well, I am not sure about this question. The ZOO-Client is fully open source, we simply have added an html page (its content can be found as the page itself) and two small JavaScript files so we did not think it would require anything to be published as everything is available online. We may be wrong here, if it may be of any help for anyone to have this submitted to the SVN tree please let us know and we can proceed by adding all the demo front end demos on the source repository.<br>> <br>> I hope my answer was clear enough and it helps.<br>> <br>> Best regards,<br>> <br>> <br>> <br>> Gérald Fenoy<br>> http://wiki.osgeo.org/wiki/User:Djay<br>> <br></div></div></div> </div>
<br>_______________________________________________
Zoo-discuss mailing list
Zoo-discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/zoo-discuss</div></div></div> </div></body>
</html>