5

There will be a data export happening from our org for large number of objects and records using a cloud based ETL tool.

We have a business scenario where we need to make sure that there is no data update made in the org for a window of 48 hours during which cloud based ETL tool will be exporting data out of salesforce.

We are making sure no user updates data through profile level login hours.

We have lots of Batch, Schedule, Queue apex as well as usage of @future in classes. We need to make sure these asynchronous jobs do not make data changes.

What are some ways to achieve the same with minimum effort ?

One way we are considering is deleting all the scheduled jobs before the 48 hour window and then recreating the scheduled jobs after the window.

Scheduled jobs are owned by an Integration User, is it a good idea to disable the Integration User ?

Will we also need to abort currently running jobs ? Will it be a good idea to do this :

for ( AsyncApexJob aJob : [ Select id ,Status, ApexClass.Name from AsyncApexJob where Status!='Aborted' and Status!='Completed' ] ) {

      System.AbortJob(aJob.Id);

}
  • 1
    I don't think you have any other option other than deleting and rescheduling those jobs. – Jayant Das Apr 24 '19 at 13:26
3

I would do this with a hierarchy custom setting. Create a new setting object with a checkbox. Then, for each object you want to lock down, add a simple validation rule:

NOT($Setup.Lockdown__c.AllowUpdates__c)

Where Lockdown is the name of the custom setting, AllowUpdates is the name of the checkbox. Enable this checkbox at the org level until it's time to lock everything down.

Then, when the time comes, uncheck the box in the org defaults, and let your ETL run. This validation rule will block all attempts to update records, including any batches, scheduled updates, time-based workflow, etc. When you're done with the ETL, just check the box again, and you're good to go. This is the most efficient method I can think of, though other solutions would also be possible.

|improve this answer|||||
  • N.B. a side effect of this may be that the async jobs will flood whatever error reporting mechanism exists with the caught DML exceptions - clearly manageable as OP is a one-time event – cropredy Apr 24 '19 at 18:01
  • small correction : NOT($Setup.Lockdown__c.AllowUpdates__c) – Walker May 13 '19 at 12:04
  • @Walker Thanks! – sfdcfox May 13 '19 at 12:32
2

One way we are considering is deleting all the scheduled jobs before the 48 hour window and then recreating the scheduled jobs after the window.

If you are looking for a one-time activity, I will recommend you go with this approach of deleting the jobs and then rescheduling those after your ETL extract. This way you don't necessarily have to deal with any other tweaks but be able to assure that your data is not being updated by any source within the system. And because you have already ensured that no other Users can update any data, this will be your most direct way of achieving this.

Scheduled jobs are owned by an Integration User, is it a good idea to disable the Integration User ? Will we also need to abort currently running jobs ?

Even if you disable the User, there could be still a scheduled job and when it will execute, you end up with errors spending more time troubleshooting those. So yes, you will still need to abort currently scheduled/running jobs.


In all other cases, you will need to ensure to introduce some logic in your code/configuration and testing those out which potentially could take more time than going the direct way.

|improve this answer|||||

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.