Geoprocessing Service: Output used for input to another task

[GinoMellino]

Hello,

I am building a web app using arcgisonline and the web app builder. I have 2 custom python script tools, the first creates a layer from a list of OIDs from GenerateNearTable, the second performs some geoprocessing operations on this layer. This works fine in desktop but when I publish them to a web app (using arcgis online and the web app builder) I cannot access the layer from the first task in the second task. The layer is there, it displays fine, it is just not in the choice list for the second task. The second geoprocessing task has the rest of the layers as options as well as the original layer I used to create the gp result in desktop to publish from.

Is it possible to use the output of one gp task as an input to another? If so would someone be kind enough to give me some insight as too how? Is this a ridiculous idea to begin with (pls be gentle, it is my first web app )?

Thanks to all in advance.

Cheers,

Gino

[KevinHibma · Accepted solution]

It's not a ridiculous idea, but you do have to construct the service/web app in a certain way.

I'd step back and ask why you're using them as 2 separate tasks in the server environment? Is there some sort of technical limitation that blocks you from either producing a single script, or even adding these 2 script tools into modelbuilder and having the output of 1 be the input to the 2nd? This is going to be the absolute simplest and most straight forward way to get what you want.

If you need to keep them as 2 distinct services, it'll be you who is responsible for getting the output from one to the other. Your web application will act as the glue between the two. Since your output is a layer the first service will either need to send the featureclass back to the webapp and the webapp will have to send the features back to the 2nd service or the 1st service will have to send the location the features are on disk (server side) and the webapp would pass this reference to the 2nd service.

Both these options arent great. Why?

Option 1 = the transfer of features when you dont really need to. (but you do need to because you have 2 services)

Option 2 = you're sending paths and information about the server back to the client. Even if its just the webapp getting this information and the user doesn't see it, I'd still consider this a minor security flaw as you're web-exposing information about the server itself.

So, again, what you want to do is possible, but I'd strongly suggest pushing both tools into a model and publishing that.

[GinoMellino]

Hi Kevin,

Thanks for the great info. The reason I wanted 2 services was for 2 reasons. The first is mainly for neatness, combined the two tools have 17 parameters and I thought this may be a problem for people using this app on smaller screens/laptops. Secondly, I plan to use the first tool to create 'queries' of the data, so the user could extract more than one query per session. Then I planned to have a drop down list in the second tool where the user could choose which one of this query layers to perform the geoprocessing on. This would allow the user to operate only on the area of interest and not the whole dataset which will probably cause the request to time out on the server.

However in saying this your advice above does make sense to me. I think I will try and put these scripts into a model and run them as one overall tool. Will have a go and let you know the results.

Once again, thanks for your help!

Cheers,

Gino

[GinoMellino]

Thanks for the advice above Kevin, I have implemented it into a single script and it now works great!

Cheers,

Gino