In what circumstances might a microflow specified as "Start" in the Navigation under Menu Bar not be run when a user logs in? Further to earlier questions about preventing login during long-running database updates, I implemented a microflow which does the following things: display a welcome message (this is how I know that the microflow is or isn't run) checks a system monitor to see if the system is "busy" if it is not busy, it takes the user to a datagrid view which is the 'real' home page of the application if it is busy, it displays a message telling the user this, then retrieves his session and calls a Java action which terminates the session, which should result in the user being logged back out again. This Java action contains debug messages to verify that it is being invoked when it should be. If a user logs in when the system isn't busy, the welcome message is displayed, then the user is taken to the home page datagrid view - no problem. This happens also if a second user logs in, and so on. If the system is busy, however, the microflow doesn't seem to run at all. The welcome message is not displayed, debug messages in the Java action are not printed, and the home page datagrid view is not displayed either. Instead, the user is taken to a blank page where he can see and use the navigation menu. His session is visible in the MxAdmin | Active Sessions view. (If there were simply a logic error which permitted the login when it should be blocked, the welcome message should still appear, and so should the home page datagrid). When the system is busy, it is very busy - it is making bulk uploads to the database by means of Java actions which use batching. When the upload starts, the monitor is updated to say that the system is busy, and anyone logged on gets kicked off (using the same Java action mentioned above). At the end, the monitor is cleared so that logins are once more accepted.
asked
Martin Bucknall
1 answers
3
Hi Martin, to analyse where things go wrong you should use some tool to see all client-server requests, at Mendix we use firebug for this. That is a free firefox plugin which I use almost every day. (You can download it here)
If you enable firebug and activate the 'console' it shows all the requests send to the XAS and the response it gave.
To find your problem you should check what is send to the server and what the response is for this request.
The request you should be looking for end's with the term #executeaction if you open this server call you can see in the request tab the name of the microflow and in the response tab the actions the client should take. Can you post the response for the normal server call and the response when the server is busy?
When you have done that I might be able to give you a few more hints to locate the problem