Create a DAG-enabled Batch Job

  • Updated

Create a DAG-enabled Batch Job

Overview

While configuring the DAG Schedule, you need to have batch jobs that are compatible with the DAG framework to be able to add the jobs to the DAG chain.

Jobs available through CL products are configured to run in the DynamicJobs framework. Any existing custom non-DAG jobs cannot be used directly in DAG configurations, as it only implements Salesforce classes. If you have an existing non-DAG class that needs to be added to the DAG chain, you must first convert it to a DAG-enabled job class that extends the abstract clcommon dynamicjob class.

This document explains both the following procedures:

Create a new DAG-enabled Batch Job

Prerequisites

  • CL Common 2.3000 or higher is installed. This contains the DynamicJobs framework.

Steps

Perform the following steps to configure a job for DAG:

  1. Log in to your Salesforce account.

  2. Go to (Setup) > Setup.

  3. On the left navigation bar, go to Custom Code > Apex Classes.

    You can also search directly for Apex Classes in the Quick Find search box.

  4. Do one of the following:

    • Click New.

    • Click Developer Console, then go to File > New > Apex Class and provide the job name in the New Apex Class field, and then click OK.

  5. Replace the code in the new class with the following code, replacing MyJob with the required batch job name:

    Sample DAG job
    global class MyJob extends clcommon.DynamicJob { // you do not need to implement Database.Batchable or Database.Stateful as the DynamicJob superclass already does this

    global MyJob() {
    super();
    }

    global MyJob(String name, String query) {
    super(name, query);
    }

    global override void doInitialize() {}

    global override String getRuntimeQuery() {
    return null; // OR return a valid query if you did not specify a query while making an execution entry through the API
    }

    global override void doStart(Database.BatchableContext bc) {
    }

    global override void doExecute(Database.BatchableContext bc, List<sObject> scope) {
    }

    global override void doFinish(Database.BatchableContext bc) {
    }

    }

  6. While creating a new DAG-enabled job, ensure the following:

    • The new class must extend the clcommon dynamicjob class as the dynamicjob class is the base class to invoke the DAG framework.

    • The new class must have a global access modifier, and not a public one.

    • All the methods must have the a global access modifier.

    • The class needs to have an empty constructor.

    • All the methods must have the override keyword.

    • doStart, doExecute and doFinish methods correspond to start, execute and finish methods of Database.Batchable interface. Provide the related batch processing logic for the methods here.

    • Following are the description of the methods of this class:

      Method NameDescription
      doInitialize This method is called before the batch job starts. It is called post instantiating a job class. It consists of the logic that the system needs to implement before the job is executed. Furthermore, it can be empty, but it needs to be overridden.
      getRuntimeQueryThis method returns the query to be executed by the job at runtime. This method must be implemented only when the query needs to be generated at runtime.
      getRuntimeQueryForPipelineExecutionThis method is not required to be implemented in this context currently. This method returns information about pipeline executions in the specified state.
      doStartThis method is used to implement any additional logic that is not mentioned in the getRuntimeQuery method.
      doExecuteThis method is used to implement any business logic that is set for the job.
      doFinishThis method returns the finish logic that is set for the job.
      getParametersEvery custom job can have only an empty constructor, so it cannot have parameters passed to its constructor. So if you need to add additional parameters, then you need add the parameter in the Input Parameters field of the DAG configuration and you can consume those parameters by this getParameters method.

  7. Add the batch processing logic in the methods.

  8. Save your changes.

Convert an existing custom non-DAG batch job to a DAG-enabled batch job

If you have an existing custom batch job that you need to add to the DAG chain, then you need to convert that non-DAG job to a DAG-enabled job and then add it.

For example, you have an existing non-DAG job named BillingJob that implements Database.Batchable<sObject>, Schedulable. To convert it into a DAG-enabled job, you need to create another class with a name such as BillingDynamicJob that implements clcommon.DynamicJob. And only this BillingDynamicJob class name can be specified in the DAG schedule.

Prerequisites

  • CL Common 2.3000 or higher is installed. This contains the DynamicJobs framework.

Steps

To convert, create a new DAG-enabled job as explained in the previous section and copy the logic from your existing non-DAG job to this new DAG-enabled job by ensuring that the following actions have been taken:

  • The new class must extend the clcommon.dynamicjob class as the dynamicjob class is the base class to invoke the DAG framework.

  • The new class has a global access modifier, and not a public one. Else, the system throws an exception.

  • The class must have an empty constructor.

  • All the methods must have the override keyword and must be implemented.

  • All the methods must have a global access modifier.

  • The methods must be implemented as follows:

    Method NameImplementation Details
    doInitialize This method is called before the batch job starts. It is called post instantiating a job class. It consists of the logic that the system needs to implement before the job is executed. It can be empty, but it needs to be overridden.
    getRuntimeQuery

    Where ever you have implemented the job query in your existing non-DAG class, you need to add that job query in this method. This method returns the query to be executed by the job at runtime.

    For example, you have implemented the job query in the start method of your non-DAG class, then you need to implement that query in this method of the new class.

    getRuntimeQueryForPipelineExecutionThis method is not required to be implemented in this context currently. This method returns information about pipeline executions in the specified state.
    doStart

    This method is used to implement any additional logic that is not mentioned in the getRuntimeQuery method.

    For example, let us say, that the start method of your existing non DAG class returns a query, and in addition to returning a query, you have some preprocessing logic too before returning the query. Now, since the query of the start method of your existing class is already implemented in the getRuntimeQuery method of your new class, then this preprocessing logic must be added in this method of the new class.

    doExecuteThis method is used to implement any business logic that is set for the job. All the business logic implemented in the execute method of the non-DAG class, must be copied over to this method of the new class.
    doFinish This method returns the finish logic that is set for the job. Copy the logic of the finish method of the non-DAG class to the doFinish method of the new class. If the finish method of the non-DAG class is empty, then the doFinish method of the new class must also be kept empty.
    doExecute(schedulableContext) Any logic in the execute(schedulableContext) method of the non-DAG class must be copied to the doExecute(schedulableContext) method of the new class.
    getParameters Every custom job can have only an empty constructor, so it cannot have parameters passed to its constructor. So if you need to add additional parameters, then you need add the parameter in the Input Parameters field of the DAG configuration and you can consume those parameters by the getParameters method.

Example

For example, say you have an existing non-DAG job class as follows:

Non-DAG job
public class TestJobNotDAG implements Database.Batchable<sObject>, Schedulable {

private Boolean returnRuntimeQuery;

public TestJob() {
super (‘TestJob’);
returnRuntimeQuery = true;
}

public TestJob(Boolean return RuntimeQuery) {
this();
this.returnRuntimeQuery = retunrRuntimeQuery;
}

public TestJob(String Query) {
Super( ‘TestJob’ , query);
}

public String getRuntimeQuery() {
If (addLimit) {
String query = ‘SELECT Id, Name, Active_c FROM Account LIMIT 2’ ;
System.debug(LoggingLevel.Error, ‘query’ + query);
return query;
}
If(returnRuntimeQuery) {
return ‘SELECT Id, Name, Active_c FROM Account’
}
else {
return null;
}
}

public void Start(Database.BatchableContext context) {}

public void doExecute(Database.BatchableContext context, List<sObject> scope) {
//code for business logic
}

public void doFinish(Database.BatchableContext bc) {

}

To convert it, create another DAG-enabled job by copying all the contents from the non-DAG job as follows:

DAG job
global class TestJob extends clcommon.DynamicJob {
private Boolean returnRuntimeQuery;
public static Boolean addLimit = false;

global TestJob() {
super (‘TestJob’);
returnRuntimeQuery = true;
}

global override void doInitialize() {}

global override String getRuntimeQuery() {
If (addLimit) {
String query = ‘SELECT Id, Name, Active_c FROM Account LIMIT 2’ ;
System.debug(LoggingLevel.Error, ‘query’ + query);
return query;
}
If(returnRuntimeQuery) {
return ‘SELECT Id, Name, Active_c FROM Account’
}
else {
return null;
}
}

global override String getRuntimeQueryForPipelineExecution (Set<Id> records) { }

global override void doStart(Database.BatchableContext context) {}

global override void doExecute(Database.BatchableContext context, List<sObject> scope) {
//code for business logic
}

global override void doFinish(Database.BatchableContext bc) {

}

Then provide this name, TestJob, in the DAG Schedule configuration to be able to add it to the DAG chain.

Note:

For more information on how to configure a DAG Schedule, see the DAG Configuration section.

In This Article