Timed Trigger - server side

[ChrisPaine]

Hello,

I recently found that the timed trigger UI element is client side driven - i.e. it does not seem to fire if the user loses network connectivity. Please correct me if I'm wrong.

Does anyone have a reasonable solution for achieving the same result server-side? Perhaps an asynchronous task to trigger an event when it returns? Any ideas on how this might be achieved?

The use case is a timeout that fires if the end-user does not save their work before a certain time.

Unfortunately those with poor network connections are also losing their work, and the timeout event is not firing in these cases.

Seems to me that this should be reasonably simple to implement, but thought I'd tap on the cumulated knowledge here to see if anyone else had already done it.

Cheers,

Chris

[Former Member · Accepted solution]

FPM has something called asynchronous events, see for details. I however don't know if the events get delivered in case the network connection is dropped.

[ChrisPaine · Accepted solution]

Thanks Samuli,

could be perfect for my use case, I'll check to see if it works when the user has dropped connection.

Cheers,

Chris

[Former Member]

Hi Chris..Nadh etc

I know this post is a few months old..

Have you guys tried looking at the code behind POWL.

The queries at the top have "Running" text beside them while some of the queries have completed running. So not all queries load at once.

I remember looking at the POWL code a while back, they call Function modules in new tasks etc and strangely they were able to update the UI(running text disappears) after the initial load without reloading the current query.. (its not strange to do this in other technologies but I have never seen this used in custom WD applications)

You may be able to use this concept to achieve the timed trigger from server..

We could even create an email application that auto updates when there is a new email( not time triggered from client   ),

Regards,

Krishna

[Former Member]

Hi Chris,

Were you able to crack this?

WebDynpro applications are stateful applications and thus only way instance of the application is recognized by server is by using its session. As soon as the session is lost, application is totally isolated and cannot communicate with server any more unless it is refreshed to open a new session. Concept of saving form data in browser session does not apply for WebDynpro applications. Hence no persistent storage of data until it is saved back in SAP.

And thus if users lose their session due to poor network, there shouldn't be a way to save data no matter even if it is synchronous or asynchronous way.

Let me know if I missed something...

Best regards,

Nadh Yandamuri