BatchPatch Forums Home › Forums › BatchPatch Support Forum › So close to a killer feature, Macros.
- This topic has 1 reply, 2 voices, and was last updated 5 hours, 1 minute ago by doug.
-
AuthorPosts
-
August 26, 2026 at 2:20 pm #14525mkreitzerParticipant
So far I am really loving this product. The old school no nonsense sensibility as it gets out of my way to let me work is most welcome in current year.
As I’ve come to learn it, I’m seeing all of the plumbing for what would be a killer feature for complex setups. I have a base “queue” that I copy and expand when I need bespoke behavior. I call it “Generic Update”. If I need special behavior for something, I pull in that saved queue and modify it. A couple of examples are a “Veeam Update” which has additional checks that our Veeam server is not currently processing any jobs or a “F5 Node Update” which pulls a host out of all load balancer pools before updating then places them back and waits for all health checks to show green before proceeding.
What is going to increasingly become a problem moving forward is when I need to make an adjustment to the generic queue. I have to make the same changes to each derived queue. Add multiple administrators, and you have the perfect recipe for divergence.
The software has the concept of the saved queue that exists outside the scope of the grid. It has the basic logic plumbing for flow based on results. All that is needed is a way to execute a saved queue from within the job queue, and for a saved queue executed in such a way to return a “success” or “fail” result, and voila, you have macros!
The one detail that would make or break this is that the call to the saved queue needs to execute the saved queue as it is now, not as it was when the call was added. This is a bit of a divergence to the way the software currently operates. For example, if I alter a saved command, I have to re-add the call to that saved command in every place such a call exists in every queue. Ngl, I don’t much like this behavior either, as I’d like to update the command once and it take effect in all places it is called, but I understand changing this behavior has the potential to break a lot of existing installs. For any such “Macro” feature like the one I described, it should be different. Changing the macro should be immediate for all callers.
Anyway, food for thought, maybe. 🙂
August 26, 2026 at 2:48 pm #14528dougModeratorThank you much for the suggestion. We will consider this.
-
AuthorPosts
- You must be logged in to reply to this topic.