Hi,
We are planning to upgrade the Alteryx Server to 11.7.
The plan is to upgrade the server and then let users test their workflows.
In case the users are good with the results, we get the go ahead to execute the production workflows.
The issue is, once I upgrade the server, the server will automatically start executing the scheduled production workflows.
Is there a way to just disable the scheduler until we get the go ahead from the users?
OR
The only way is to delete all the scheduled workflows and manually reschedule them once we get a go ahead?
Thanks,
Poorab
@ppoorab1 There isn't any settings or functionality to disable just scheduler entirely on the server as the underlying functionality is used for all workflows run by the server. However, you can take a couple approaches to preventing or limiting scheduled jobs depending on your specific needs, configuration, and what version you are running currently. If you are on 11.0 or higher and using exclusively Gallery for scheduling a Curator can go in and disable the ability to schedule workflows. Then edit each scheduled workflow setting them to disabled. Once they are tested the Curator can then re-enable each schedule as needed and the ability for users to schedule workflows. I think this is the best option if it is available to you.
If you aren't on 11.0+ or if you are still scheduling workflows directly from Designer you can achieve a similar result by editing each schedule from within Designer and setting the frequency to Once. This will update the schedule so that the workflows will no longer run on a recurring basis. However, anyone with access to schedule in this manner would be able to edit the schedule to set it back to a recurring state or create new schedules.
A final option would be to disable the worker(s) entirely. This can be done via the Alteryx System Settings by selecting Custom under Setup Type and unchecking the Enable Worker option. Disabling the workers will prevent the server from running any workflow at all. This would include scheduled workflows, user run workflows, workflows run via Gallery API request, and workflow validations when saving workflows to Gallery. Any workflows sent to the queue while the worker(s) are disabled will sit in queue until the worker(s) are re-enabled. This can lead to a very large backlog of pending tasks, and could make adequately testing the workflows difficult.
Thanks @KevinP for all the options.
I am afraid unfortunately none of them would work for me.
We are on 10.5 currently with no Gallery implementation all the workflows are scheduled via controller token.
And with the upgrade to 11.7, we are planning to implement Gallery a week later.
Here is my crude plan, please let me know if that would do the trick.
1. Take a backup of the current schedule using "alteryxservice emongodump"
2. Wipe out the entire schedule
3. Do the version upgrade to 11.7
4. Let the users test their workflows on the server (by using the controller token)
5. Get a go ahead from users.
6. Restore the schedule using "alteryxservice emongorestore"
The other question I have in mind is, will I end up with a large backlog of pending tasks?
Thanks,
Poorab
@ppoorab1 Backing up the database first is an excellent idea, and would give you the opportunity to roll back to your current version. For information on backup best practices and procedures please refer to the Alteryx Server Backup & Recovery knowledge articles. Since none of the options presented are viable for you I would proceed is as follows:
Keep in mind though that this is only viable if you are using MongoDB as your persistence layer. Since you are currently using server without Gallery it is possible that you are using SQLite instead. If this is the case you will have to start with a blank database in order to deploy Gallery as MongoDB is required for Gallery, and there isn't a migration tool to convert from SQLite to MongoDB. This does have the advantage of letting you test on a blank database without have to do repeated backup/restore processes. Just stop the service and backup the entire persistence folder (default: C:\ProgramData\Alteryx\Service\Persistence). Then reconfigure the service to use MongoDB, upgrade to 11.7, and test. If everything goes well your users would just need to re-upload their production workflows and re-schedule them once testing is complete.
Thanks a ton @KevinP for such detailed steps.
I will test the steps on our Test Server and let you know how it goes.