ACTIVATE_UC_OBJECT for starting recurring task

[Anon Anon]

Hi All

Can we use ACTIVATE_UC_OBJECT to trigger a recurring activity?

I am trying to configure a lot of similar jobs which follow the pattern of Execute > Recurring, then I enter Timings and Alias, Timezone, Queue and click ok.

Is there a way to do this using ACTIVATE_UC_OBJECT?

I can generate commands from CSV file and run them so that all recurring tasks can be created in one go.

Thanks

Nimish

[Anon Anon]

We tend to not use Automic facilities that are not readily visible to our production support staff for scheduling of tasks.  By convention all tasks are either in a Schedule object or objects that have been activated by a Schedule object.  This also helps us in several areas such as ability to stop a Schedule and ability to just start Schedules after the rare "cold" start of the system.  We do not need to concern ourselves with determining which other objects might need to be manually started.

We rarely use the Recurring execution option and to my knowledge never for production work.  If this feature is used at all it is in the non-production Clients.

Our preferred method is to use Timed Events and have their Interval (! Process) perform the required object activation. The Events themselves are on the Schedule and normally have RunTime Supervision (MRT) that lets them run a bit less than 24 hours (for those that run continuously) and then are started again via the Schedule at the appropriate time the next day.

The Event's Interval logic, depending on requirements, reads either a Variable or a file using the appropriate PREP_PROCESS_VAR/FILE function.  These contain the objects to activate and various information regarding their attributes such as Calendars, times of day or whatever else is needed.

We also use this technique for some File Events.  They activate objects when there are matching files to process and in some cases stop themselves when there are no more files for some period of time or other criteria.  Again, these events adhere to the above scheduling convention.

[Anon Anon]

Is there a reason for a large number of recurring tasks? How often are these tasks running?

Using a Time Event job is an alternative to Execute-Recurring.

[Anon Anon]

>@</p>Mark Hadler" 

Thanks for your reply, that is indeed quite informative and will certainly help me in optimizing our Atomic activities.

@Jenn & Mark_Hadler_430 


We are using Automic to implement JDE jobs.

Our current approach is like

Initially create module specific Queues (which can be stopped to hold the task executions)

Then add jobs who have these queues configured according to their modules.

Then execute > recurring for each job as per requirement. Some jobs are required to be executed in a recurring manner more than once. for e.g. say a job needs to be executed at 07:00 and 20:00 CET daily (this will require 2 recurring "At time" executions).

Please do let me know if there is a better approach or if there are any drawbacks in this approach.

Thanks :smile: 

Nimish

[Anon Anon]

In our environment, we have a relatively large number of jobs/process flows that run hourly, every 30 minutes, and every 15 minutes in our UC4 V8 environment.  Automic V10 is presenting quite a challenge for us to duplicate this behavior. 
I have attempted to set up the EVENT OBJECTS as mentioned above, and put them in a schedule.  This worked to a degree, but we found that when we let the schedule run over a period of days, we would have multiple instances of the jobs running at the same time... I'll clarify:
We set up an EVENT OBJECT called "Hourly Maintenance".  The schedule had this start at midnight, and run on the hour via the EVENT OBJECT.  This worked very well for the first day.  However, when the NEXT day started, it started a new instance of the EVENT OBJECT within the schedule, so now, we had 2 "Hourly Maintenance" jobs running every hour.  Since this ran over the weekend, a third iteration of this also started, so we had 3 instances of "Hourly Maintenance" running by the time we were back in the office on Monday morning.
We have now moved away from that situation, and are trying the "EXECUTE-->RECURRING" possibility, but as Mark Hadler mentions above, we are concerned with having to manually restart all of these recurring jobs in the event of a cold-boot. 
I would also like to know if there is a scripted way to start these recurring jobs, like the ACTIVATE_UC_OBJECT command... if this were possible, we would like to create a "start-up script" that would have all of our recurring jobs in it, and simply use that to kick them off after a cold boot or some other situation.

[Pete Wirfs]

The solution I applied for our hourly jobs is to hard-code them into the schedule 24 times.  Our 30 minute jobs are hard coded into the schedule 48 times.  I also set their "Max number" setting on their Attributes tab to "1" so that two instances of the same job won't run at the same time. (we get occasional log jams when we temporarily close our application queues.)

This method also provides your forecast reports with a more accurate view of what is scheduled to happen in the future.

[Anon Anon]

Pete, that is DEFINITELY the easiest way to do it, and there would be no doubt that it would work correctly. 
The reason we decided to veer away from that route, however, is that's a lot of "drag and drop" work for each job or process flow.  We have about 15 different processes that are currently running every 15 minutes.  96 "drag and drops" per job is something that we felt was prohibitive, especially when you consider how much easier it is to do the same thing in UC4 V8.  With 15 jobs like that, 1,440 entries is simply a poor way to utilize our resources.  Add on the "every 30 minute" job and the hourly jobs, and that's a LOT to keep track of.

That being said, if we continue to encounter these scheduling difficulties, we may have to push back on our developers and simply tell them "no more than once an hour"....

[Pete Wirfs]

We do a lot of pushback here.  Application developers would love to have Automic kick off some of our batch processes every 60 seconds to give their customers the impression that they are getting real-time results from a batch solution.  But we won't allow it.  If they need real time results, then they should re-engineer their applications to not depend upon periodic batch cycles.

We also allow our applications to trigger upon-demand Automic jobs from within their applications via the CALLAPI interface into the product.  We put it inside of a .net component so it is very easy to use.

[Anon Anon]

I think I have missed a point here, can someone please explain what exactly we mean by cold boot? I am getting a feeling that we would be required to redesign our process of scheduling jobs.

[Anon Anon]

Nimish... cold-boot means completely powering down your server, letting it sit for at least a few minutes, and then restarting it.   As opposed to a "warm-boot", where you just do a restart, and the machine never completely powers down.
Jobs that have been submitted by using the "execute--> recurring" method would not come back up automatically after a cold-boot... they might come back up after a warm boot, but I'd need to test it to be sure.
Jobs that are submitted via Schedules would only need to have the schedules resubmitted.  You can see the obvious benefit of only having to remember to start up a few schedules as opposed to starting multitudes of individual jobs with "recurring" parameters.

[Anon Anon]

Nimish, Adrian:

Just to clarify, I was referencing an AE software "cold" start not something at the hardware level and the loading of a new copy of the operating system.  For example. see the Best Practices for moving database discussion. 

[Anon Anon]

Well... even after all of this discussion, it doesn't look like Nimish got the answer to his question... "Is there a way to do this using ACTIVATE_UC_OBJECT?" 
I'd still like to know if that's possible or not...
:-)

[Anon Anon]

Adrian:

Regarding your issue:

We set up an EVENT OBJECT called "Hourly Maintenance".  The schedule had this start at midnight, and run on the hour via the EVENT OBJECT.  This worked very well for the first day.  However, when the NEXT day started, it started a new instance of the EVENT OBJECT within the schedule, so now, we had 2 "Hourly Maintenance" jobs running every hour.  Since this ran over the weekend, a third iteration of this also started, so we had 3 instances of "Hourly Maintenance" running by the time we were back in the office on Monday morning. 

We use the following technique that I mentioned in my initial reply:

Our preferred method is to use Timed Events and have their Interval (! Process) perform the required object activation. The Events themselves are on the Schedule and normally have RunTime Supervision (MRT) that lets them run a bit less than 24 hours (for those that run continuously) and then are started again via the Schedule at the appropriate time the next day.

The MRT can stop the Event around midnight and the Schedule would start it back up just after midnight.  This avoids the scenario that you described regarding the same Event running multiple times.  This also somewhat addresses "event drift" that can happen to the Interval not occurring at the desired time of day for long running Events.  We also usually include theTasks running parallelattribute to ensure that only one Event is active at a time (as mentioned by Pete).

[Anon Anon]

Thanks, Mark... I have implemented your suggestions above, and it works very well! 
I guess that this could be considered an acceptable substitute to creating a "startup script" and trying to execute all of the recurring jobs via ACTIVATE_UC_OBJECT.

Again, thanks.

[Anon Anon]

Hi Everyone,

I had raised a ticket about, whether recurring jobs cease to exist after any kind of reboot.

Good to hear that it will remain as it is even after a cold boot. Here's a reply from support

a recurring task is the same as a task set up in a scheduling object, they also remain in activity window and will be started again after the Automation Engine is restarted.

 

To ensure that everything will remain working as expected please ensure that before you switch off the physical (or virtual) machine, all CP and WP Processes of the Automation Engine are switched off correctly, so you can start them after the outage. in that case the planned and scheduled tasks will run waiting for their next starttime after the restart of the Automation Engine.

 

This is valid in each case

 

Automation Engine "cold" restart and Automation Engine "normal" restart. In that case it does not matter if the Physical (or Virtual) machine is restartet too or not. It always depends on the Automation Engine CP and WP Processes.

 

In case the Machine is switched off without shutting down the CP and WP processes before, or the Database is switched off without switching off the CP and WP processes before you should check the activities if they run properly after a restart.

[Anon Anon]

Mark and Adrian

Thanks for your replies, it was really informative.

The startup script option seems to be good, will surely try it out.

Thanks :smile: