i have developed a sapui5 freestyle app, running in an sap fiori launchpad. This app extends a third party solution with a fiori frontend. All is working good so far. But this third party solution uses its own locking table for its objects and i have no possibilities to change this. So when my apps is starting, it reads the data by using an odata request (the odata services are also "my" code). This odata implementation is then adding an locking entry to the third party solution. When the user "normally" ends its work on that document using save, delete or cancel, my odata implementation of the save, delete, cancel methods also deletes the lock entry in the third party solution. Even the closing of the browser or the app is handled by attaching to special browser-events, so the locks are released in that case by calling an odata method for releasing the locks.
But what if the user starts the app (which triggers the lock) and then does nothing any more. The user is running into a session timeout. And the lock-entry for document he/she was working on is still existing.
What i need is a way to react on such a session timeout with my code which then releases the lock. Maybee an event which is triggered, or maybee there is a smart idea to dealing with such session-timeouts in the backend.
Any ideas are welcome.
kind regards
Matthias
Related
I have a Google Apps Script bound to a Google Sheet, and have published that as a Web App. It is restricted to a certain Google Workspace. That Google Sheet is kind of an improvised database for that web app and changes over time. I would like to send the updated data to all clients once the Google sheet gets changed. Is that possible? I don't need a trigger for the edit, since I know in the script when I add new data, so this is the time to send the new data.
Basically the same question can be formulated as follows: We know that we can execute a server-side function from the client with google.script.run, but is it also possible to execute a client-side function from the server i.e. the apps script?
My current workaround is a client-side setInterval which checks for server-side updates (and fetches them using successHandler) every 30 seconds or so. It works, but is not optimal.
Just to mark this one as answered. Cooper writes in the comments:
"It's not possible to execute a client side function from the server unless it has been first initiated by the client and it's responding with a callback. Polling is your only option I think."
Ok, so I came to this company that recalled its software from an offshore, no-longer-extant entity. We all know the drill.
In looking at the nuts and bolts, I come across the 'lock' keyword. Googling, I find that Entity Framework does not support multi-threading.
My question is: How can I be 100% certain that the application is attempting to run in multiple threads? Is the existence of the 'lock' keyword enough?
Thanks.
If this is a ASP.NET/MVC web app and you have the lock keyword that is probably because the app is in IIS and IIS dispatches different user requests on different threads and therefore web app becomes multi-threaded.
In case of MVC - Controller is created per request and then it is processed on different thread. That leads to the need to lock something if two users at a time are going to access it.
If this is a desktop app and the lock is where data access happens it might be for similar purpose.
The lock keyword alone is not enough, they could be using it incorrectly after all. lock will just prevent more than one thread from entering the protected area at any one time. What is being protected by the lock? Data stored in a static variable is available to all users (threads) using the app and so should have controlled access.
We have a GWT based thick client like web application. The application is considerably large and has some initial load time.
We would like to send the users of our application e-mail messages with href links that would open up a specific asset in our application. Well this of course has the effect that clicking the link opens up the application again, reloads it which we would like to avoid. Ideally we would like the href link to just signal our application/web page somehow so that we could pick up the event in our application and react to it.
Any ideas how we should approach this or is this even possible ?
Thanks!
You need to use a GWT Hyperlink which is a widget that serves as an "internal" hyperlink. That is, it is a link to another state of the running application. When clicked, it will create a new history frame using History.newItem(java.lang.String), but without reloading the page.
If you are not already using it, information is here on GWT's History mechanism
There seems not to be any elegant solution to send an event from a link to an existing browser window. Few solutions I have encountered this far:
a) Implement a cookie polling solution for the application to poll if a cookie exists or changes. The link points to our server which just sets the cookie and this way informs the running app about the event. Some tricky handling should be implemented with some kind of 2-way protocol between the returned temporary page from server to handle the situation where the application is not (yet) running.
b) The same approach as in solution a) but use html5 local storage for communication. This way the poller is not needed as the local storage fires an event when content changes. This would be a possible solution but is not for me as we have to support older browsers without local storage support.
c) A long polling ajax or a web socket for delivering events from the server to the client. A solution but seems overkill and might require a modern browser for atleast web sockets.
After many support cases we are realizing the biggest problem we have with our GWT-based application is that users are leaving it open for weeks at a time. This means when we do a hotfix every week or two the RPC stubs are out of sync and cause silent exceptions to be thrown making the site look "broken". Does anybody know of a way to auto-detect and avoid this issue? A few ideas I have had are...
On catching an RPC mismatch exception refresh the browser.
When loading the host page inject the version number in source control the build came from, have a status checker/timer that check that the number did not change. When it does reload.
Reload on an arbitrary timer (perhaps twice daily).
Any ideas?
I'd like to present a fourth option.
Create an RPC Proxy and UI Object proxy that all UI requests and RPC requests are routed through. This way whenever this proxy detects that something is out of date it can dynamically load the widget or change it's expected RPC models.
This is pretty how Vaadin does things and it works great. Vaadin is a UI toolkit built on GWT in case you're not aware. We have several long running production applications using this over the last couple of years and we have made some tweaks in their UI Def language (UIDL) to add version mismatch.
This diagram is a good representation of what they do and if you don't want to build something like this yourself I'd of course recommend moving to Vaadin.
Implement security that logs users out after an hour of idle time. Assuming your releases are overnight or on weekends, the users are logging in after the release. No need to refresh the app.
this is viable especially if your site eventually needs users to login.
I'm working on an iPhone application that should work in offline and online modes.
In it's online mode it's supposed to feed all the information the user enters to a webservice backed by GWT/GAE.
In it's offline mode it's supposed to store the information locally, and when connection is available sync it up to the web service.
Currently my plan is as follows:
Provide a connection between an app and a webservice using Protobuffers for efficient over-the-wire communication
Work with local DB using Core Data
Poll the network status, and when available sync the database and keep some sort of local-db-to-remote-db key synchronization.
The question is - am I in the right direction? Are the standard patterns for implementing this? Maybe someone can point me to an open-source application that works in a similar fashion?
I am really new to iPhone coding, and would be very glad to hear any suggestions.
Thanks
I think you've blurring the questions together.
If you've got a question about making a GWT web interface, that's one question.
Questions about how to sync an iPhone to a web service are a different question. For that, you don't want to use GWT's RPCs for syncing, as you'd have to fake out the 'browser-side' of the serialization system in your iPhone code, which GWT normally provides for you.
about system design direction:
First if there is no REAL need do not create 2 different apps one GWT and other iPhone
create one but well written GWT app. It will work off line no problem and will manage your data using HTML feature -- offline application cache
If it a must to create 2 separate apps
than at least save yourself effort and do not write server twice as if you go with standard GWT aproach you will almost sertanly fail to talk to server from stand alone app (it is zipped JSON over HTTP with some tricky headers...) or will write things twise so look in to the RestLet library it well supported by the GAE.
About the way to keep sync with offline / online switching:
There are several aproaches to consider and all of them are not perfect. So when you conseder yours think of what youser expects... Do not be Microsoft Word do not try to outsmart the user.
If there at least one scenario in the use cases that demand user intervention to merge changes (And there will be - take it to the bank) - than you will have implement UI for this - than there is a good reason to use it often - user will get used to it. it better than it will see it in a while since he started to use the app because a need fro it is rare because you implemented a super duper merging logic that asks user only in very special cases... Don't do it.
balance the effort. Because the mess that a bug in such code will introduce to user is much more painful than the benefit all together.
so the HOW:
The one way is the Do-UnDo way.
While off line - keep the log of actions user did on data in timed order user did them
as soon as you connected - send to server and execute them. Same from server to client.
Will work fine in most cases as long as you are not writing a Photoshop kind of software with huge amounts of data per operation. Also referred as Action Pattern by the GangOfFour.
Another way is a source control way. - Versions and may be even locks. very application dependent. DBMS internally some times use it for transactions implementations.
And there is always an option to be Read Only when Ofline :-)
Wonder if you have considered using a Sync Framework to manage the synchronization. If that interests you can take a look at the open source project, OpenMobster's Sync service. You can do the following sync operations
two-way
one-way client
one-way device
bootup
Besides that, all modifications are automatically tracked and synced with the Cloud. You can have your app offline when network connection is down. It will track any changes and automatically in the background synchronize it with the cloud when the connection returns. It also provides synchronization like iCloud across multiple devices
Also, modifications in the Cloud are synched using Push notifications, so the data is always current even if it is stored locally.
Here is a link to the open source project: http://openmobster.googlecode.com
Here is a link to iPhone App Sync: http://code.google.com/p/openmobster/wiki/iPhoneSyncApp