Automic Workload Automation

Hello,

Can we create a job which will run every 30 seconds? in UC4 I just only see the format 00:00, it means we only can specify the hour and minute. No place for setting the seconds?

Regards,
Phat Tran

here is a Post from Josef covering this:

https://community.automic.com/discussion/9126/runtime-monitoring-maximum-runtime-mrt-lower-than-1-minute-is-not-reliable-detected

You could try using means of the operating system

possibly it works using scripting, but you will have to test it.

FrankMuffke
 Thank you for your info. I will test it. if I want to run every 5 minutes(not less than 1 minutes). How can we do "every" ? We select "Start of period +"?

There are several ways to archieve this

A) using an EVNT.time object
B) using recurring execution (with or without PERIOD object) of your Job
C) using a JSCH object (not recommend, if you want it be startet that often)
D) using scripting (not recommended for you as well)

I personally would use A
possibly B

Hi Wolfgang,

we usually recommend to use (B) because of the known issues with EVNT: no data for forecast, lack of displayment in the activity window, floating execution time.

best,
Peter

peter_grundler_automic
Thanks for the info, Peter!

Which versions are affected from this?

In the JSCH object we can see the schedule of jobs/workflows. If we use recurring B, how can we know when the job will be executed?

The next execution time of the scheduled job will be displayed in Details Window (Activities Window - doubleclick on the recurringly started job)

      .....
      .....
      Period
          Next check    22.08.2017 12:25:00
          Next run    22.08.2017 12:25:00

FrankMuffke,

Yes we can do that.
When we open JSCH, we can see clearly the jobs are scheduled. But with this, we don't have clear view. First we need to identify the job and second do as your instructions. The disadvantage here is there are a lot of jobs, we cannot click on 1 by 1.

Wolfgang Brueckler said:

Which versions are affected from this?

Hi Wolfgang,

I think that every version is affected as this is an internal behavior. That's one of the reasons why "recurring execution" was introduced.

regards,
Peter

Hi peter_grundler_automic

ah now I understand, thougt you are talking about a special Bug :-)

Recurring Execution has one disadvantage in my view - once ended, it does not show up in the activities windows as well...

Usually I use C) (starting via JSCH object) for my system, but I do not have this small recurrent window (=many executions in short rimframe)

cheers, Wolfgang

This is a case where I'd go back to the developer of the "job" and ask them to manage the recurrence more robustly. 

Every 30 seconds is a huge number of executions, and each execution contributes (just a feather) to weigh down your infrastructure. Automic handles high executions wonderfully, for the most part. But let's say you have 1000 jobs that run hourly. That's 24k executions per day. Now you add 2800 daily executions for one single job. It's 0.1% of your jobs, and it takes over 10% of your executions! 10% of your history tables, 10% of your WP resources, 10% of communication between master and agent, etc... and moreover, you have set a precedent of treating every execution like it's free. 

Especially for a simple job (which it must be, running in less than 30 seconds), it's not difficult to code a loop around a set of commands, no matter what language. Take a parameter for number of loops or number of minutes; run the commands and sleep 30 seconds until the number is met, tracking success or failure; and then exit appropriately (or exit immediately if the error is fatal). For example, let the command run 500 times (about 4 hours if the work takes 1 second) and exit, then restart the job 1 minute later.

You might think at first that you will lose some information this way, but it is usually much better, operationally.

• You can look back over several days of history without scrolling through thousands of records. 
• If the Automic master goes down for 2 hours (but the job host is OK), no problem... your job keeps running fine without having to check in with the master; otherwise it would stop running for the whole 2 hours.
• If the runtime of the actual command doubles, you'll see much more clearly when it goes from 4 hours to 4.5 hours, than from .8 second to 1.6 seconds. 
• If you have a notification set for every failure, but it's normal to have a few failures occasionally, then you can give the job just a bit of internal logic so it only exits after N number of errors. Otherwise you get lots of unactionable notifications (evil) or you have to code this kind of error handling in UC4 script, which is again more overhead, and usually less transparent to non-experts.
  

With over 300k activations per day, I feel pretty strongly about this. :smiley: 

JessicaIsaacson603938 got me thinking.  This could be a situation where the business problem should be resolved by having the application dynamically launch the object upon demand via CALLAPI so it will only run when needed.  

It all goes back to understanding "Why are they requesting this?"  Once you understand the WHY, then you can design a better solution.

One time I was approached by a project team that had a similar need to have a "listener" on a business process.  The final solution was to build and run a real service application on another server.  In this case, UC4 was not the best tool for the job.

petwir exactly!  So often, UC4 is not the right tool for the job, but we try to please the customer and fulfill a requirement anyway, without looking at the bigger picture.

On the other hand, asking everyone to fill out a six-page form including their life story and motivations for creating each job... didn't work out too well for us, either. 

So I know this is from months ago, but reading through this got me thinking of some processes we've accommodated for over the years.  Part of me feels like at times, this contributes to some spikes and noise in our systems.
Some of our users have a handful of workflows that they want always out there, and watching for a file every minute, every day.  This also means that the jobs in the workflow are also sitting out in the Activities window in pending status, and sometimes, it can be months before a file arrives.  If the file is found, the workflow completes and starts again.  I've actually asked them to look in to file events and run them every 10 minutes instead as the workflows are also available ADHOC using CallAPI.  
Just wondering if anyone has come across these types of requests before and if they've had any issues with jobs running every minute (these jobs are also in Preconditions and aren't the actual object in the JOBP).  I'd like to give the users alternatives as it will help them as well with troubleshooting if they have an issue (ie/ less objects in Activities).

We made it very easy for developers to invoke CallAPI with a reusable object.  There isn't as much resistance to that method when it is easy to do.

Absolutely!  Some of those jobs are using CallAPI and it works, but they still want them running every minute as well.  I want to present them the idea of using File Events again for these processes and push the time out to 10-15 minutes.  That way, if someone does run it ADHOC, it'll run no problem.

One more thing, I just have a feeling that having something run every minute, every day, can potentially cause issues in our system.  I know for us, since we're responsible for the services and monitor Activities, I find we'll have queues with several items just sitting out there waiting for preconditions related to the workflows.  Has anyone had processes like this cause issues on their systems?