function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
nathan.edwardsnathan.edwards 

Queueable invalid interface name

I've been trying to get the new Queueable Interface to work using API version 32.  Developer console keeps giving me "Invalid Interface name provided".  Anyone experimented with this and get it to work?
Best Answer chosen by nathan.edwards
S. KumarS. Kumar
Please try class name "queueable " instead of "Queueable". 

All Answers

Gaurav NirwalGaurav Nirwal
You can try the wrong process Please check the interface name again 
S. KumarS. Kumar
Please try class name "queueable " instead of "Queueable". 
This was selected as the best answer
Ken KoellnerKen Koellner
The release notes specifically contain -- 
public class AsyncExecutionExample implements Queueable {
Which will not compile.

But I have found that -- 
public class AsyncExecutionExample implements queueable {
compiles.



 
nathan.edwardsnathan.edwards
Awesome, Thanks!
Ken KoellnerKen Koellner
Anyone know way to allow callouts in execute?  I get the error to add @future(callout=true) annotation but that solution won't work verbatim in the queueable class.
 
Carolina Ruiz MedinaCarolina Ruiz Medina
Hi Nathan, Ken,

You are right, It is true that in my dev org I have to save the class with the anotation : 
public class MyQueueable implements queueable{
 
   public void execute(QueueableContext context) {
 
    System.debug('hola');
   }
}

did you try to run it?  
ID jobID = System.enqueueJob(new MyQueueable());

It gives me an error: Internal Salesforce Error:  Method is not implemented.

Therefore seems like it is a little bit "bug-y / flaky " at the moment :-) . 

However , said that, I went to my sandbox where I used already Queueable interface, Queaueble works ok there.

To the question if it is possible to do callouts from a Queable the answer is yes, at least I'm able to. Here it is a sample code: 
public class MyQueueable implements Queueable,Database.AllowsCallouts  {
    public void execute(QueueableContext context) {
        
      
        // Send GET request
        System.debug('xxxhola');
         HttpRequest req = new HttpRequest();
         req.setMethod('GET');
         req.setHeader('Content-Type', 'application/json');
          req.setEndPoint('https://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&key=API_KEY');
         req.setHeader('Authorization', 'Bearer ' + UserInfo.getSessionId());
         HttpResponse response = new Http().send(req);
         System.debug('xx'+response+'xx');
 
    }
}

I'm also able to chain a job after the callout : 
public class MyQueueable implements Queueable,Database.AllowsCallouts  {
    public void execute(QueueableContext context) {
        
      
        // Send GET request
        System.debug('xxxhola');
         HttpRequest req = new HttpRequest();
         req.setMethod('GET');
         req.setHeader('Content-Type', 'application/json');
          req.setEndPoint('https://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&key=API_KEY');
         req.setHeader('Authorization', 'Bearer ' + UserInfo.getSessionId());
         HttpResponse response = new Http().send(req);
         System.debug('xx'+response+'xx');

        ID jobID = System.enqueueJob(new MyQueueable2());
 
    }
}

However what I can't do (yet :) )  is to try to do a DML before I do a callout within the same "execute" like this:
  
public class MyQueueable implements Queueable,Database.AllowsCallouts  {
    public void execute(QueueableContext context) {
        
         Account a = new Account(Name='Acme',Phone='(415) 555-1212');
        insert a;

        // Send GET request
        System.debug('xxxhola');
         HttpRequest req = new HttpRequest();
         req.setMethod('GET');
         req.setHeader('Content-Type', 'application/json');
          req.setEndPoint('https://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&key=API_KEY');
         req.setHeader('Authorization', 'Bearer ' + UserInfo.getSessionId());
         HttpResponse response = new Http().send(req);
         System.debug('xx'+response+'xx');
 
    }
}

It tells me : You have uncommitted work pending. Please commit or rollback before calling out

Hope it helps.

Thanks,
Carolina. 
Ken KoellnerKen Koellner
I didn't see a mention in the documentation of declaring "Database.AllowsCallouts  ".  But once I found that out, I did get my callout to work.

You are correct about DMLs and callouts, once your thread of execution has done any DML, callouts are strictly verboten.  SF designed it that way has they will be holding a connection open to the underlying database (Oracle I believe) as soon as the first DML is issued and they don't want to hold that connection while up to 120 seconds of callouts are going on.  That has always been the case, even in non-batch Apex.  In fact, the reason I'm using batch apex is because I need to do some DMLs, then do a callouts, then do some more DMLs.  So the first set of DMLs is in regular Apex and then I submit a queueable that does the callout and then the remaining DMLs.
Carolina Ruiz MedinaCarolina Ruiz Medina
Hi Ken,
Yeap, You are right, that is the case, ( for this reason I said "yet" as a joke :) ) , and as you pointed out we can always do a chaining in order to do the DMLs.

Great!  Thanks!! 
Carolina.