0

I'm looking at What's the difference between AsyncApexJob and CronTrigger? Currently I have a Schedule class, and queueable class(which fires future methods). Below is the hierarchy:

  1. Schedule class calls queueable class
  2. Queueable class calls couple some future methods

I want to know the completed datetime stamp for the entire process.

I was looking at AsyncApexJob object and what my understanding is, because queueable and futures are asynchronous these future calls can have a different completed date time-stamp future than queueable completed date time-stamp.

Now here comes the issue if what my above understanding is true how can I truly know the completed date-time stamp of when actually my Queueable and anything within Queueable(future calls) are actually completed.

2

Your Queueable and future jobs will all be represented by different AsyncApexJob records, and enqueuing a future method doesn't yield your calling code a job Id that you can monitor. As a result, when you're trying to monitor the progress of a job that spans multiple types of asynchronous code, you generally have to implement your own "transaction Id" sort of mechanic.

This would be some kind of unique identifier you supply to the first job in the chain, and which is passed to each successive asynchronous piece of code along the way to preserve the identity of the overall process.

One form that this could take is a Custom Object My_Job__c, a record of which is created at the time of enqueuing the first asynchronous job in the sequence. Each successive async job can then obtain as one of its parameters the Id of that record and can perform an update against it to record the progressive status of the larger job before spawning the next async code in the sequence, passing along the record's Id. Once the status is updated to the final value, you can persist the date of completion to that object.

If your async process has a "fan out" structure, as it sounds like it does with multiple future methods being called from Queueables, you do have to consider carefully the possibility of lock contention against an object like that. (What if two or three future jobs execute in parallel and one or more of them takes a while to run?)

For that reason, among others, I would generally prefer to use (serial) Queueable chaining rather than a fan-out structure that changes between types of asynchrony.

What you might do if, as you mention in comments, you have 10 futures being fired from a single Queueable and you cannot change that architecture, would be to have a persistent job object as described above with a checkbox field for each of the 10 sub-jobs. Have each sub-job take the job object Id as one parameter, make its callout (I presume they're callout jobs), and at the very end query the job object FOR UPDATE and check off the checkbox field that corresponds to the sub-job. You'll need to keep the duration of that lock as short as you possibly can, because the possibility of lock contention with this architecture is significant.

You could then have a workflow rule/process/trigger on the job object whose entry condition requires that all 10 boxes are checked and a field update action to populate NOW() into a DateTime field to record the overall completion.

Alternately or in addition, that final piece of automation could fire a Platform Event, which makes it easier for your front-end to listen for job completion without polling the database.

  • +1 The problem i was thinking is lets say my queueable is calling 10 future methods, there executions can run in parallel rather than in series, so im little confused because creating a record in top queueable would be fine but passing Id's to future's for updates can be really tricky! – codeyinthecloud Aug 31 '18 at 14:32
  • platform events still won't really suffice my need, but can help to an extent – codeyinthecloud Aug 31 '18 at 14:34
  • I guess like you said the design has to change to Queueable chaining! Thanks for jumping in. – codeyinthecloud Aug 31 '18 at 14:42
  • 1
    It doesn't have to change, but from an architecture standpoint that would be my preference. I added a little more detail regarding your fan-out structure. – David Reed Aug 31 '18 at 14:45
  • I love the checkbox pattern. I still have to careful about the possibility of concurrency like you said. – codeyinthecloud Aug 31 '18 at 14:50

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.