1

Been talked about before and the requests were delivered in Winter 14 (CronJob Name)

But I cannot seem to find the relationship between the ApexAsyncJob and the Actual CronTrigger

  1. If I abort the AsyncApexJob (Via the ID obtained in a query), its status is updated to aborted from the Apex Jobs listing BUT the crontrigger part still shows up in the Scheduled Jobs section and happily runs at the next cycle.

Use Case:

Trying to manage the scheduling and aborting of a job from a configuration screen

  1. I can store the jobID and that is all well and good, BUT if a user scheduled the class via the Salesforce Schedule Apex UI then the entire process goes haywire.
  2. If they schedule via the standard UI, they could name it anything so there is no way for me to tell which cron job goes with the actual ApexAsyncJob that I see
  3. I can stop them from scheduling via regular UI by throwing an error in the constructor of the scheduled class but that throws a nasty error saying "Invalid class" or something

The goal is that Once I have the class ID, I should be able to tell if it is scheduled (Done) AND be able to delete the cronjob. This way I can manage the job from the configuration page regardless of where it was scheduled. If only the ClassName was available in the CronTrigger.......

Anyone have any other ideas?

1

I wonder if there are a few strategies you can employ here:

  1. recommend never to store the JobID, but start it with a known Name and query on that - this way you can maintain that your own code will always be able to locate and stop the job,

  2. maybe you can avail a static boolean whose value you check when constructing the class - then throw an exception unless your code sets the static, locking out the Standard UI,

  3. depending on if it's an ISV package vs unmanaged code, you might demote the class visibility from global to prevent the user trying to schedule it.

|improve this answer|||||
  • 1
    #3 was the way to go. I also ended up storing the job ID and if they try to cancel the job through the config page it provides a message and deletes the jobID. Also if the JobID of the CronTrigger used to execute the batch does not match the one stored the job is aborted effectivly preventing it from running. All together I believe this will fix it. BUT - One would think this missing connection would be available between the CronTrigger and the AsyncApexJob – Eric Sep 26 '14 at 2:28
  • Is there anything on the CronJobDetail object that will help? @Eric – bigassforce Sep 26 '14 at 3:08
  • Unfortunately not, it only has the type of the job and the Name of the CronTrigger Job (What the user called it) - No relation to the AsyncApexJob object at all. – Eric Sep 26 '14 at 4:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.