Execute long running REST request asynchronously (Fire and forget HTTP-request)

Currently all our REST requests wait for a response from the server.

 

But we also have some long running tasks which can take like 20 minutes. These tasks are triggered by the browser (currently a REST request).

 

But we don't need an answer for this in the browser. The OE backend should just immediately return 200 OK, and execute the long running taks in parallel.

 

In short : 'We need a fire and forget http request'.

 

 

The problem currently is that after 2 minutes the tomcat session times out, and our client software is triggered by this timeout and shows an error.

 

Is this possible in OE? Any pointers on how to do this?


  • Tim Kuehn (TDK Consulting Services Inc)

    I don't think this is possible the way you describe it.

     

    What I've done is have an API which accepts information to start a process. It then spins off a background session to do the work, and returns a token to the API caller that the caller can use to later poll the server for progress updates and finding out when/how the background process completed.

     

    I've done batch processing spawning APIs like this with great success.

  • Peter Judge (Consultingwerk)

    You can do more-or-less what @Tim Kuehn (TDK Consulting Services Inc)​ is suggesting , with PASOE.

    • Send the REST requests to PASOE.
    • The webhandler gets what it needs from the request, and runs a .P ASYNC in the same instance. The request should have enough information to be able to construct the URL (ie PASOE scheme, host, port, webapp).
    • The webhandler returns a 202/Accepted status. It can also return a Location HTTP header with a URL pointing to the resource.
    • The client can occasionally check the Location URL. If the background job has completed, it will return a 200 or maybe 201 HTTP status and maybe some data. If not, the 202 is re-returned.

     

    The determination of what constitutes "done" depends on the job. It may be a report on disk, or a flag set in a db table or something else.

  • Matt Baker (Progress Software)

    You can also move to a message oriented architecture for these sorts of things. I'd suggest Kafka. Use Kafka to send a message from the client to a cluster, and then forward that request to your application server or kick off a separate process.