Clarity

Hi!  Wondering if anyone out there has found an crontab entry that is used to run a job every n days (irrespective of where the days fall on the calendar).....

The use case is we would like to run a job every 28 days.  

Consulting Dr. Google, I've gottten various answers.  Was wondering if anyone is utilizing something that works for them in their CA PPM implementation.  We're running 14.3 if that makes a difference.

Any and all input appreciated.

Thank you.

Don't believe that you can set a single CRON expression to get "every 28 days" - simple to get one that says "every 28th day of the month" (which is close, but not the same).

Think you'll end up with multiple job submissions - i.e. manually work out what dates "every 28 days" falls on and schedule a couple of years worth of job instances? Set yourself a reminder to do this again next year?  

(I have done that sort of thing before with Unix CRONs not PPM ones)

Thanks David.  Unfortunately that is what we have now.  Not exactly the end of life as we know it but just kind of a pain in the shorts from a technical debt perspective.

Yeah, not very satisfying from a technical point-of-view is it!

I've had regular "admin maintenance tasks" set up as work-processes for PPM admin teams though which satisfied my "needing to code this" yearning - in that, the admin team have regular weekly, monthly and yearly work-processes that they need to perform (for example the monthly one would involve closing/opening/creating time recording periods). By adding the "recode the unix crontab" as one of the yearly tasks I was satisfied that I had "coded" a solution (albeit the "code" was a manual process that had to be followed). </geek>

Hey Scott. Tell me a little about your job.

Scheduled Process? Stored Procedure? Java?

We have things scheduled with CRON that function outside of CRON's capability. Conceptually, for your business problem to solve I'd build something that runs every night, checks a counter (attribute or a custom table/field ) for a value (= 28?). If yes, execute then reset counter to zero. If no, increment counter and terminate.

This gives you a job that runs every night but 'does something' every 28 days.

Hey Rob!!!!!!!

Interesting...the job fires off a stored proc to approve submitted timesheets for all open time periods for a given OBS.

As it is already calling a stored proc, it would be simple enough to incorporate your logic into the stored proc.

I'll give it a whirl.....Thanks!

Building off Robert’s idea:

Run every day and check to see if it falls on the 28-day cycle base on a given start date.

<?xml version="1.0" encoding="utf-8"?>
<gel:script
    xmlns:core="jelly:core"
    xmlns:gel="jelly:com.niku.union.gel.GELTagLibrary"
>

     <core:getStatic var="closeOperation" className="java.time.temporal.ChronoUnit" field="DAYS"/>
     <core:invokeStatic var="todayDate" className="java.time.LocalDate" method="now" />     
    <core:invokeStatic var="startDate" className="java.time.LocalDate" method="of">
         <core:arg type="int" value="2014"/>
          <core:arg type="int" value="1"/>
          <core:arg type="int" value="1"/>
    </core:invokeStatic>

     <core:set var="numberOfDays" value="${closeOperation.between(startDate, todayDate)}" />
     <core:set var="is28Day" value="${numberOfDays % 28 == 0}" />
     
     <gel:log>Number of Days = ${numberOfDays}</gel:log>
     <gel:log>is28Day = ${is28Day}</gel:log>

</gel:script>

Requires Java 8.

V/r,

Gene

Well if you are going to "cheat" and have some control in your job ("is it 28 days since I last ran") then that is easy!

Awesome Gene. I didn't have confidence enough in my math to say "is divisible by 28" would always work so I chickened out with the counter idea. You forced me to re-think this. 

Scott, using Modulo as Gene has simplifies things and removes the need for any objects to hold values & code to increment values. In your stored procedure, hard code your start date, diff from Today each time it runs and use Modulo to test the result. If the result is 0, execute.

I'm still a little chicken & open to scenarios where this would not work. Please comment if you see a hole in this.

Perhaps I would still implement that sort of logic as "have I run in the last 28 days" rather than "is it day #28, then run" just to cope with exceptional circumstances (e.g. the system was down on Day28, so I will not run again until Day56) - I guess thats an arguament for Rob's 'counter' logic rather that one based purely on some algorithm based on date.

YMMV of course.

Good point Dave, assuming the happy path has burned me in the past. 

I typically create a small xml file to persist values between runs. 

V/r,

Gene

Something else I thought of (perhaps another argument for the counter logic that Rob suggests......)

Let's say there's a change in business rule (I'll use the Timesheet Approval Use case)...

If you set up the counter variable in a custom object, it would be easier to control...Let's say instead of every 28 days, the business wants it to run bi-weekly (i.e. every 14 days).  

Haven't entirely thought through the design yet, but if you house the interval as attribute in the custom object, and there's a change, you simply change that value.

All good stuff!!!!!!   I have a little time to play with this, as the driver behind this would be simply a reduction of technical debt (i.e. yours truly having to schedule 13 instances of the same job for each run in a given fiscal year)!!!!!!!!!

  Just kidding. I think it's a great idea!