Callouts in Batch Apex,State in Batch Apex

Using Callouts in Batch Apex

To use a callout in batch Apex, you must specify Database.AllowsCallouts in the class definition. For example:

global class SearchAndReplace implements Database.Batchable<sObject>, 

   Database.AllowsCallouts{
              //Business logic you want by implementing Batchable interface methods

}

Callouts include HTTP requests as well as methods defined with the webService keyword.

Using State in Batch Apex

Each execution of a batch Apex job is considered a discrete transaction. For example, a batch Apex job that contains 1,000 records and is executed without the optional scope parameter is considered five transactions of 200 records each.

If you specify Database.Stateful in the class definition, you can maintain state across these transactions. When using Database.Stateful, only instance member variables retain their values between transactions. Static member variables don’t and are reset between transactions. Maintaining state is useful for counting or summarizing records as they're processed. For example, suppose your job processed opportunity records. You could define a method in execute to aggregate totals of the opportunity amounts as they were processed.

If you don't specify Database.Stateful, all static and instance member variables are set back to their original values.

The following example summarizes a custom field total__c as the records are processed:

global class SummarizeAccountTotal implements 

    Database.Batchable<sObject>, Database.Stateful{

   global final String Query;

   global integer Summary;

  

   global SummarizeAccountTotal(String q){Query=q;

     Summary = 0;

   }

   global Database.QueryLocator start(Database.BatchableContext BC){

      return Database.getQueryLocator(query);

   }

   

   global void execute(

                Database.BatchableContext BC, 

                List<sObject> scope){

      for(sObject s : scope){

         Summary = Integer.valueOf(s.get('total__c'))+Summary;

      }

   }

global void finish(Database.BatchableContext BC){

   }

}

Transaction Control(Database.setSavepoint())

Transaction Control( Database.setSavepoint())

All requests are delimited by the trigger, class method, Web Service, Visualforce page or anonymous block that executes the Apex code. If the entire request completes successfully, all changes are committed to the database. For example, suppose a Visualforce page called an Apex controller, which in turn called an additional Apex class. Only when all the Apex code has finished running and the Visualforce page has finished running, are the changes committed to the database. If the request does not complete successfully, all database changes are rolled back.

Sometimes during the processing of records, your business rules require that partial work (already executed DML statements) be “rolled back” so that the processing can continue in another direction. Apex gives you the ability to generate a savepoint, that is, a point in the request that specifies the state of the database at that time. Any DML statement that occurs after the savepoint can be discarded, and the database can be restored to the same condition it was in at the time you generated the savepoint.

The following limitations apply to generating savepoint variables and rolling back the database:

·         If you set more than one savepoint, then roll back to a savepoint that is not the last savepoint you generated, the later savepoint variables become invalid. For example, if you generated savepoint SP1 first, savepoint SP2 after that, and then you rolled back to SP1, the variable SP2 would no longer be valid. You will receive a runtime error if you try to use it.

·         References to savepoints cannot cross trigger invocations, because each trigger invocation is a new execution context. If you declare a savepoint as a static variable then try to use it across trigger contexts you will receive a runtime error.

§  Each savepoint you set counts against the governor limit for DML statements.

§  Static variables are not reverted during a rollback. If you try to run the trigger again, the static variables retain the values from the first run.

§  Each rollback counts against the governor limit for DML statements. You will receive a runtime error if you try to rollback the database additional times.

§  The ID on an sObject inserted after setting a savepoint is not cleared after a rollback. Create new a sObject to insert after a rollback. Attempting to insert the sObject using the variable created before the rollback fails because the sObject variable has an ID. Updating or upserting the sObject using the same variable also fails because the sObject is not in the database and, thus, cannot be updated.

The following is an example using the setSavepoint and rollback Database methods.

Account a = new Account(Name = 'xxx'); insert a;

System.assertEquals(null, [SELECT AccountNumber FROM Account WHERE Id = :a.Id].

                           AccountNumber);

// Create a savepoint while AccountNumber is null

Savepoint sp = Database.setSavepoint();

// Change the account number

a.AccountNumber = '123';

update a;

System.assertEquals('123', [SELECT AccountNumber FROM Account WHERE Id = :a.Id].                           AccountNumber);

// Rollback to the previous null value

Database.rollback(sp);

System.assertEquals(null, [SELECT AccountNumber FROM Account WHERE Id = :a.Id].                            AccountNumber);