I am starting new year with new problems and hope, that someone here can help me.
The problem I am facing is that I have this “Fat Client” application, windows application built in appbuilder and I need to let all users know that there is going to be a service maintenance. Like Jenkins is starting to either update the code or update schema, I need to let users know 10 minutes beforehand, that the system is going to be shut down and no new users can connect/log in. I have seen something like this is putty window, in TTY application, but never in fat client. Does Progress have some tools to send that kind of warning and restrict user access to the application or DB?
Can it even be done by some existing tool or should I try to come up with a custom solution. The challenge seems something that others should have also, I hope someone points me to correct direction.
Thank you in advance,
Lauri.
If your system isn't used 24 hours a day you should always upgrade out of hours so that if something went wrong you had time to sort things out before users needed the system again. This is especially true for a schema change.
10 minutes is hardly enough time anyway and not very considerate to the system users.
Unfortunately it is a 24/7 factory system and there are no actual off hours. Business side has agreed that system can go down for max 30 minutes during the day, factory workers can have either a meeting or longer coffee break.
Manually stared Jenkins job is able to shut everything down, apply schema change/code change and start everything up in less than 5 minutes at the moment. Now I need to come up with a way to notify users of the maintenance downtime, ideally Jenkins should be able to start that process, then apply the change as it is currenly working and then stop the process, so that everyone can log back in.
Since it’s fat-client then guess the client runs on windows so easier would be to just send messages the ms$ way… net send if jenkings runs on windows, smbclient if *nix.
1 application has ~100 users in 3 different continental instances of Citrix. EU AP AM, so the application runs in Citrix client and users use it through Citrix on windows machine
Second application is located in factorys ~50 instances and ~10 users each, also in Citrix.
The idea is to let Jenkins update 1 instance at a time, maybe this notification and preventing users to log in can be done on Citrix level, but then it involves people outside Progress developers and I would first try to resolve it on Progress level
OE 11.6 is the version.
Yes it runs in Citrix client on windows.
Judging from answers until now, I guess there is no Progress tool for that. Nothing in asbman or dbman for that?
|
Since your application is a fat client app anyway, why not start a persistent program with a pstimer inside that checks every minute if an update is pending. If you want, you could even let this persistent program quit the application.
[mention:6e3b17cb0ff148039a2aabb4c7834ce4:e9ed411860ed4f2ba0265705b8793d05]
Would it be possible to see a short&sweet tempalte to do this notify icon from progress app?
TIA
I did this notification thing (see winnotify.i and the last comment in http://www.oehive.org/node/404#comment-2943 which can help you to implement notifications in Windows).
I'm using it for this exact same use case, except I'm using webclient. I ping the appserver every 30 seconds (using a PSTimer), and when the connexion is down (Appserver has been stopped e.g. for maintenance), it notifies the user (the same way Outlook does), then try again every 30 seconds until I can restore it (notifying again when it could).
I also have something like a sequence, which - if it increases - asks the user to restart the application (so that the client gets updated when needed).
And meanwhile the connexion is down, I kind of prevent the user to do anything in the application (like disabling menus).
PS: for the record, if your application is doing asynchronous requests, the PSTimer code must check for pending asynchronous requests before pinging the appserver, not to trigger an error.