If you have questions or if you want to share your opinion about Aware IM post your message on this forum
#51383 by johntalbott
Mon Aug 19, 2019 4:03 pm
Here is video demo of another approach to broadcasting real-time data changes to all users.
https://screencast-o-matic.com/watch/cqjqowt1Ph

NOTE: Turn off sound in video. It's all static. There wasn't supposed to be sound anyway. :)

This is using AIM's out of the box CRM sample with:
- some custom client-side JavaScript to send/receive notification messages
- Node.js running side by side with AIM and used to receive & broadcast the notifications

- In the left browser, I'm logged in as admin.
- In the right browser, I'm logged in as John.
- When a data change is made by a user, a notification is broadcast to the other users in the background.
- In response, the queries for the other users that are affected by the change refresh.
#51386 by Jaymer
Mon Aug 19, 2019 7:27 pm
But seriously,
this is nice.

1) so we know a grid can redraw based on a process running, etc.
But I bet this is something in the render/init script that must be "listening" for something... but what?

2) And, since there are some who don't like "losing their place" when a screen redraws (like if you scroll down a big list, edit/save a rec, Aware redraws and puts you back at the top of a form), I wonder if this has that same drawback? Because when the "losing their place" issue is resolved, then it will be even more nice here to not have you dragged away from where you are on a screen.

3) If you have active filters, does it retain them when it redraws?

4) OK, here's how this can be really useful. IMHO. John might have missed this discussion at the R.I. conference... I have thought there is a need to alert someone based on an INBOUND EVENT/NOTIFICATION.
If you have callbacks/messages being processed by Aware, then there is a need to alert an current LIRU that something has happened that needs his attention (ie. a text message was replied to; an email came in; An email was opened by recipient, etc.). Based on the "old" CRM, it uses a badge to let you know that a msg. is waiting - but it does that by running a process every "x" seconds - which means [potentially] lots of users baning away on the database every 10,20,30 seconds unnecessarily. Sure would be nice for John's "listener" code to be installed in several "key" Queries/Forms, and the Rules that process these inbound events would have an easy way to let LIRU know something has happened.

just my $.03
jaymer...
#51388 by hpl123
Mon Aug 19, 2019 8:06 pm
Nice stuff John :D

Support, how about implementing something like this in future versions to enable all of us to do this "natively" without other/external things? Would be very nice to have.
#51390 by johntalbott
Mon Aug 19, 2019 9:47 pm
Jaymer wrote:But seriously,
this is nice.

1) so we know a grid can redraw based on a process running, etc.
But I bet this is something in the render/init script that must be "listening" for something... but what?

2) And, since there are some who don't like "losing their place" when a screen redraws (like if you scroll down a big list, edit/save a rec, Aware redraws and puts you back at the top of a form), I wonder if this has that same drawback? Because when the "losing their place" issue is resolved, then it will be even more nice here to not have you dragged away from where you are on a screen.

3) If you have active filters, does it retain them when it redraws?

4) OK, here's how this can be really useful. IMHO. John might have missed this discussion at the R.I. conference... I have thought there is a need to alert someone based on an INBOUND EVENT/NOTIFICATION.
If you have callbacks/messages being processed by Aware, then there is a need to alert an current LIRU that something has happened that needs his attention (ie. a text message was replied to; an email came in; An email was opened by recipient, etc.). Based on the "old" CRM, it uses a badge to let you know that a msg. is waiting - but it does that by running a process every "x" seconds - which means [potentially] lots of users baning away on the database every 10,20,30 seconds unnecessarily. Sure would be nice for John's "listener" code to be installed in several "key" Queries/Forms, and the Rules that process these inbound events would have an easy way to let LIRU know something has happened.

just my $.03
jaymer...


1. The server side aspect is Node.js listening for and broadcasting web socket messages to / from each client to let the client know that a particular BO was changed.

2 & 3. The data is just refreshing so the grid doesn't have to be redrawn which I *believe* causes the "lose your place" issue. Any active filters are not affected.

If the auto-refresh causes issues, a "less automatic" version could just notify users that there is new data available. Then the user has manually refresh the query data when it make sense.

The approach in this earlier demo video broadcasts data without a refresh. It's using a grid configured in code rather than an AIM out of the box query. https://screencast-o-matic.com/watch/cqVufB3wZc

Now that I have had a couple of goes at it, I see that a more advanced hybrid approach could be taken to use the AIM generated grids and still not get a refresh. It would be some work but would provide for the most seamless user experience.

4. Yes .. all of this is to avoid a timer based polling of the server for new data.

Who is online

Users browsing this forum: Google [Bot], MSN [Bot] and 15 guests