Asynchronous Server Object Extension method?

[RiverTaig1]

Is it possible to create a method in an SOE that is aynchronous and which could perhaps provide back the progress of an operation?  For example, I would like to create an SOE method that accepts a rectangular area in which there are "customers", and I would like to create a report on the server for each customer. It could take several seconds to generate a report for a single customer, and there would likely be many customers; a total time of 5-10 minutes would be expected.  Ideally as the reports were created, the client could be notified on a call-back method in JavaScript (perhaps providing a percent completion and a link to the last completed report).

[PaulCrickard]

Could you use websockets and on each 10% completed, they server uses socket.send("x%") to send the percent completed.

the client has a socket onmessage and displays the message (evt.data) alerting the user to how much is complete.

[nicogis]

your soe can return a guid reference of the job and then use another operation of soe or same operation providing the guid and soe return a percent completion like gp with submit job Esri ...

[RiverTaig1 · Accepted solution]

An interesting pattern that seems to be used, at least partially, by ESRI is the idea of a REST endpoint operation kicking off a job and immediately returning a URL to the client; the client can use the URL to get the results of the job.  I think the ExportTiles operation might be a little like that (though I haven't used it). A link to that documentation is below. 

ArcGIS REST API

Possibly the URL returned could provide either another link to the the completed job (in my case reports on customers) or a percentage indicating how far along the job was. This pattern would seem to require the client browser to be quite chatty though (in Javascript, you would set up some mechanism to check on the progress every 5 seconds or so I suppose). 

I'm not sure if that constitutes a good design choice or not - thoughts or comments appreciated.

[nicogis]

Yes, I use this pattern for long job or send email with link if I don't need wait

[RalfSchmidt]

I know this post is old – nevertheless if you, like me, stumble upon it be warned that all answers in this thread break the load balancing model of ArcGIS server. Why is that? Because all authors suggest to have the SOE return a URL and then do the work after that. This could only be done by creating a new thread or process during the time the request to the SOE is processed on the AGS. But AGS is not aware of such a thread or process that works in background long after the response (i.e. the URL) has been returned. Even worse: In case of a multi machine AGS site, your subsequent polling request might be routed to a different machine than the machine where your "working" process/thread is doing its work on. This machine wouldn't know anything about your "working" process.

The only valid pattern for an SOE with asynchronous behavior I ever came to think of (and successfully implemented) was to additionally create a GP Service that does the asynchronous work and whose endpoints ("submit job", "get job status", "get job result") are called by the SOE behind the scenes from three similar endpoints implemented by the SOE.

So why would I want to have an SOE in this case at all, if all the work is done by the GP Service? Simply because the REST interface of a GP Service is so complicated to use that you don't want to hand it to someone how does not have ArcGIS in his/her DNA. 🙂

[nicogis]

RalfSchmidt, the idea is create a factory method that you can use for all methods soe.

You call the method factory and it returns a guid.

The factory method writes in 'server store' a record (guid, status (uninitialised), hasError, result, detail, ect).

You call your method soe and provide your parameters soe and guid

If your method soe 'see' guid check if it exists and has status uninitialised and while it runs update status (failed, completed, completedwitherrors ect), detail ecc. otherwise skip update record.

Your method soe performs like any method sync but client check status using factory method (for same method factory you can create or provide the guid to check the status,result, haserror, details)

The service of your method soe however is subject to  timeout settings so you must set timeout for execution of method.

If you use GP you lose benifits of caching soe (inizialize variables in costruct ect)