Holding scheduled workflow/job objects

[IanFindon611036]

We are in the final phase of migrating workflows/jobs from our current batch scheduler "TWS" in to AE.

There are some current workflows where we are regularly requested by the Business to put them on hold/delay them for a period of time(hrs)

In TWS this is easy - in today's PLAN(schedule) we can select a "HOLD" option from a drop down menu against - to activate them again we can "RELEASE" from the drop down and they will start to process - if the scheduled time has elapsed they will execute immediately.

Although I have set up some test scenarios in our AE test client I haven't been able to identify a way of simulating this - which is to my(our) mind is such a basic scheduling requirement\function.

Can anyone help me out here - Thanks in advance.

[IanFindon611036]

I have put this question to Automic support - they advised stopping the queue the workflow/jobs are executing in - this isn't a practical solution for us as other workflows/jobs could be potentially processing in the queue at the same time which cannot be stopped from executing due to Business requirements.
Has anyone got a better idea/solution they could offer?

[Anon Anon]

We are on V8.  From a Monitor of a Schedule we select the task and right-click and select Task properties and then uncheck the  Start time/Active box.   When we wish to start it we either use a Modify task with a Go immediately or change the property back to Active.

[Pete Wirfs]

We are on V9.  Marks solution would work.  Another idea that we like if the workflow hasn't activated yet is to edit the workflow, go into the task properties for the START(1) task, and turn on the "Set breakpoint" option.  The workflow will still activate when scheduled, but will not begin executing until an operator manually releases the breakpoint. There are human-error dangers with both of these solutions though.  Staff might easily select the wrong option and something undesirable can happen. (We have had this happen to us in production.) So one idea to reduce the human-error risk would be to engineer a GO/HOLD switch into the system.  I would set up a static VARA object to hold this switch.  You could set up two new executable script objects called  "WORKFLOWX.HOLD" and "WORKFLOWX.GO" that alter the contents of the switch.  Then add a precondition rule onto task #2 of your workflow to query this switch.  If the switch is set to "HOLD" then reevaluate the switch every minute, otherwise let the workflow run. Another option is to add a CALL object to the front of the workflow that always requires a human response before the workflow will start running.

[IanFindon611036]

Mark_Hadler_430 petwir 

Guys thanks for your ideas ...

Mark - thanks - knew we could do what you suggest - if the deactivated task then misses its start time it won't execute when we reactivate - although we can then use the Go immediately option to execute it.

Pete, thanks - I'll investigate all the options you suggest. Although like you I don't want too much human intervention due to the risk of errors.

[IanFindon611036]

Well Automic support advised there is no way to do this.
Have thought of a simple work round to get round this until we can put the time in to investigate some of the solutions offered …

Put the scheduled start time on the workflows/jobs(Earliest tab in task properties) - but have them start earlier in the scheduler - they are then "Active" objects waiting to start and then from the Activities window they can be manipulated by using the drop down menus – Modify task – Stop – this will hold the workflows until the Ops get the Ok to release.

many thanks for all your help.

[Jim Griffith]

Typically if we're asked to hold a process that has not started, we edit the workflow and set a breakpoint on the start object. Unfortunately in this situation there's no real automated solution and human intervention is always involved. The only real issue we've had with the breakpoint solution is forgetting to remove the breakpoint before it runs the next time. For that, we send an email to our team every day before our main processing begins that's a list of all of the breakpoints set in workflows. That way we can review them and remove any that were missed. We also have processes that have permanent breakpoints on the start and they have to be released to start. These are ones that we commonly will get a request at 10:59 to hold this process that starts at 11. We have a check on this process that sends emails and an alert if this process hasn't started by 11:15. I breakpoint is the best bet, IMO, or if they say "hold this until xx:xx, you can right click on it in the active schedule and change the start time. 

[Legacy User]

Is there any solution  to hold the workflows/jobs rather than modifying/editing the workflows?

[Pete Wirfs]

Your workflows/jobs could be assigned unique QUEUEs to run in.  Then you could start/stop that queue.

[Legacy User]

You might also look want to look at our scripting called 

MODIFY_TASK

https://docs.automic.com/documentation/webhelp/english/AWA/12.0/DOCU/12.0/AWA%20Guides/help.htm#AE_AWA_Source/Script/ucacpg.htm

[VidyaPraveenBatchu605049]

In my previous organization, I did like this which was very helpful.
We had a common include in all work flows (all objects started from workflow only)
Created a variable object (we call it as maintenance variable) to update flow name in key and duration to skip the execution in value (Ex.,yyyymmddhhmm;yyyymmddhhmm)
I modified common include to check the current time of execution for work flow and compare it with the value updated in variable object. If current execution is between the defined window time then execution will skip.
So workflow actually starts at the scheduled time and then this solution will skip the execution. You can later run the flow as ad hoc execution.
Check if you can develop similar solution with Automic Scripting.

[KesavanElangovan]

Can the jobs be part of a separate queue and utilize Maximum slots set to 0? 
Maybe create 1 queue per application? Application with > 50 jobs or such factor. 

Thanks, 
Kesavan

[Anon Anon]

Kesavan Elangovan said:

Can the jobs be part of a separate queue and utilize Maximum slots set to 0?

Yes its possible to set the children queue in every workflow:

[Anon Anon]

Another Idea to think about:

We use Run Switches - thats an include in all objects that performs a get_var in prescript to a defined VARA object which holds the Jobname and the value 1 (run) or 0 (don't run)
if the run switch value is 0 we do a STOP NOMSG (Status: ended_inactive)

that could be a simple solution for you.

[IanFindon611036]

Thanks all for your responses ... we have decided to stay away from the more complicated scripting and vara objects for modifications and simply use breakpoints or amend start times etc ...

Kesavan Elangovan said:

Can the jobs be part of a separate queue and utilize Maximum slots set to 0? 
Maybe create 1 queue per application? Application with > 50 jobs or such factor. 

Thanks, 
Kesavan

Yes, it is possible to do - either as Wolfgang said above and your configure a child queue on the workflow - so no requirement to configure a queue on the attributes of individual jobs - Or as we do ...

Workflows configured as above to run in client queue

As our job naming convention always contains the AE agent (server) name that the jobs will run against - we created separate queues for each Agent and configure attributes of each individual job to run in their own queue ...

 

eg: all JOBS.BREEZE.xxxxxxx.****** configured to run in own queue