I see that in release 2022.2 of Indicium(-universal) it is now possible to do a setting that prevents system flows from passing through this indicium. (A setting in appsettings.json { "Agent": { "Enable": false } }
It would be really nice if Indicum would detect online if I change this setting in the appsettings.json, because then I could use this to shut down an environment.
I suggest something like an API call to Indicium, which instructs it to read this value from the appsettings.json. And Indicium should then stop accepting new system flows. (already running system flows should be completed in the normal way)
Of course I have to wait after this is done until all running system flows have ended.
The way I currently close an environment and stop the system flows is to change the schedules in IAM and then wait for all running system flows to have an end time. And when I open the environment, I change all the schedules again.
But the downside of this is that I have to change records in IAM.
Hello ericbosman,
Having Indicium look at the appsettings.json while the system flow scheduler is already running is not a feasible solution for this problem. Using an API call to stop and start the system flow scheduler (without looking at the appsettings) is feasible, but in that case it would be better to just add a task to IAM that allows you to pause/resume all active system flow schedules simultaneously. Tasks can also be called through the Indicium API after all. Perhaps we could even make it so that all active schedules can be paused for a certain amount of time. Since this would also be a nice feature to have inside of IAM, it seems like the best of both worlds to me.
What do you think of this solution?
Hello Vincent,
Your suggestion of having a task in IAM, which can also be called through an indicium API call sounds fine for me. And being able to specify how long all the active schedules will be paused sound really nice, because i can than use it as a self correcting mechanism. (If deployment fails and is not able to activate the system flows again, then i can use this as a backup mechnism.)
@Arie - We have 1 standard product and have it running in many environments. To be able to do the deployment efficiently, we have completely automated it and these deployments are done without supervision.
That means, if the deployment process encounters a problem, it must be fully self-healing.
Now a core deployment process consists of the following steps:
- deactivate the system flows (and remember which system flows they are) + check that no more system flows are running
- Shutdown the environment for users
- make backup
- upgrade
- opening up the environment to users
- activating the system flows
I now deactivate the system flow by adjusting the records in IAM.
If a deployment goes wrong somewhere, I have to restore the original situation (reload backup), but then the system flows are still stopped (records in IAM).
In my automatic procedure the system flow is then activated again (the records in IAM are adjusted again)
If for some reason the restore action after an upgrade fails or is canceled, the system flow will not be activated (because the DB was modified).
If it is now possible for the system flows to be deactivated via a task, the records in IAM will not be modified and if the Indicium universal is restarted, the system flows will be reactivated automatically. This prevents me from having to adjust records in the IAM DB and having to remember which records those were.
Yes, this is how it works. However, there is no easy way to do this for all applications or all schedules with a single click or API call. Another thing to note is that a system flow could very well take half an hour to finish, so disabling scheduled system flows by deactivating the application might cause additional downtime for end users, because the entire application will be unavailable while waiting for the system flows to complete. On the other hand, manually disabling dozens of schedules is not only tedious, it also requires you to keep track of which schedules were active to begin with, in order to restore the original state later. I could imagine three states (active, inactive, paused) to be a potentially valuable addition, but this is something we will have to consider first.