Triggering a refresh in the client of another user
I've just spent some time trying to find a solution to an interesting problem a colleague of mine had (See this post: https://forum.mendix.com/link/questions/87166). In summary; we want to trigger a refresh of an object in the client of user A1 based of an action in the client of user A2. A microflow-timer or some similar polling mechanism is out of the question, as this interferes with the session-timeout after 10 minutes of inactivity (a requirement from a security standpoint). Normally you'd probably resolve this using websockets (or a similar setup), but alas, Mendix gives us very limited control in this regard. However, I figured I might have a workaround. We tried the following: 1) Create a 'notificationCounter' object that we want to refresh, and associate it to user-session for each logged-in user 2) Create a simple java-action that retrieves all active user-sessions, and for each session retrieves the associated notificationCounter object 3) Update and refresh all notificationCounter objects My hope was that as we retrieved the specific in-memory instance of the notificationCounter for each user-session, the refresh would cause Mendix to send the refresh order to the correct client. I gave it high odds this wouldn't work (though it was worth a try), and indeed it did not. We did get the correct notificationCounter object for the user-sessions (GUID as the same), but not only did the refresh have no effect in the other client, the change we made to the object (changed the count) was also not applied to the instance of object in the other user-session. Example: We have two sessions running on the same local server. A1 and A2. A1 will add a new notification, that should lead to an update of the notificationCount in A2. We retrieve both sessions as described above, update the notificationCount with a 'refresh in client'. We start a test microflow in A2 that retrieves notificationCount over the session association. Though we see that in A1, the 'count' attribute of the notificationCount instance with GUID X has been updated to 5, the same notificationCount instance we see in the debugger for A2 still reads 4. My question is purely out of theoretical interest (practical ideas to the other thread please), as it made me realise how little I understand of how Mendix handles these kind of interactions. Why are we seeing this behavior? On websockets / client-server interaction: Why does the above not initiate a refresh of the given object in the appropriate client? On sessions / memory: Why does the above change in instance X of an object by user A1 not lead to a change in that same instance X for user A2?
Is this an example what is called in Dutch the chicken and egg paradox? What was first the chicken or the egg? In this case you want to update an inactive session and for a session to be updated it must be active, but it must stay inactive and that means you cannot update it because it becomes inactive when updated. Sounds logical to me that when something is inactive you cannot update it. I think the solution must be that the two things should be set apart of each other and this can be done by updating a session when it becomes active.
I dove into this problem as well a while back. The ´problem´ is that Mendix does not have incorporated the standard for it according to W3C, which is using the capability of a browser to send clientside updates via so called service workers enabled on your local client which are triggered based on the browsers Push API. Sounds probably a bit too technical if you haven´t read up on it yet.
I once solved this with the pusher service. A java action pushes object changes to the server. Any client can subscribe to changes of an object with a custom widget. The widgets starts a microflow per user that can force refresh.
A native mendix solution is a microflow timer on the page with a microflwo that retrieves an object from the database every X seconds and forces refresh if changed.