mjhjmtu

Getting the error below while introducing a new app. The new app is attempting to update all accounts and this is happening. Most likely because it is maxing out the callout limit. I can deactivate it temporarily, but I would prefer to make the the code more stable in order to avoid prevent this from happening again. Any help?

UNIQUE ERRORS UPDATING THE ACCOUNT RECORDS:

AccountChangeToCerbWebhook: execution of AfterUpdate caused by:
System.AsyncException: Future method cannot be called from a future or
batch method: CerbWebhookRequest.Post(String, String) () Please
Specify the Campaign for this Trade Show. Required fields are missing:
[Parent_Company__c]

We have a trigger:

 trigger AccountChangeToCerbWebhook on Account (After insert) 
 String webhook_url = 'https://HIDDEN CONTENT';

 for(Account a : Trigger.new) 
 Map<String, Object> fields = a.getPopulatedFieldsAsMap();

 string body = '_=';

 for(String fieldKey : fields.keySet()) fieldValue instanceof Time
 ) 
 paramValue = String.valueOf(fieldValue);
 

 body += '&' + fieldKey + '=' + EncodingUtil.urlEncode(paramValue, 'UTF-8');
 
 //if(!Test.isRunningTest())
 CerbWebhookRequest.Post(webhook_url, body);
 //

 

Here is the class:

 public with sharing class CerbWebhookRequest 
 @future (callout=true)
 static public void Post(String url, String body) 
 HttpRequest req = new HttpRequest();
 HttpResponse res = new HttpResponse();
 Http http = new Http();

 req.setEndpoint(url);
 req.setMethod('POST');
 req.setBody(body);

 try 
 if(!Test.isRunningTest())
 res = http.send(req);
 

 catch(System.CalloutException e) 
 System.debug('Callout error: '+ e);
 System.debug(res.toString());
 
 

If you are using a batch to update all records, then you cannot call a @future method from within that batch. You should add a method which will do the processing synchronously instead. That way, when you are already asynchronous (such as in a batch), you can just run the synchronous code. That would look roughly like the below:

public class MyClass

 static Boolean shouldProcessAsync()
 
 return !system.isFuture() && !system.isBatch() && !system.isQueueable() &&
 Limits.getLimitFutureCalls() > Limits.getFutureCalls();
 

 public static void doStuff(List<MyObject__c> records)
 
 if (records.isEmpty()) return;

 if (shouldProcessAsync())
 
 doStuffAsync(new Map<Id, SObject>(records).keySet());
 
 else
 
 // logic
 
 
 @future(callout=true)
 static void doStuffAsync(Set<Id> recordIds)
 
 doStuff([
 SELECT Name
 FROM MyObject__c
 WHERE Id IN :recordIds
 ]);
 

Looks like you have two separate errors here, neither of which is related to the callout limit (although you're right to worry about that; more below).

AccountChangeToCerbWebhook: execution of AfterUpdate caused by:
System.AsyncException: Future method cannot be called from a future or
batch method: CerbWebhookRequest.Post(String, String)

Your callout logic needs to be context-aware. If you're in a batch class - it sounds like your package is running a batch class which executes updates on Account - you should make the callout synchronously. Adrian's answer describes a good architecture to adopt for this handling.

Please Specify the Campaign for this Trade Show. Required fields are
missing: [Parent_Company__c]

This is a different error that typically indicates your existing data does not meet invariants required by your validation rules. Since the Accounts are being updated, the validation rules will all be evaluated and will block the update if they add an error. You can fix this in several ways.

1. Fix the data.


2. Deactivate the validation rule.


3. Add an exclusion to the validation rule so that it does not run on a specific User or Profile, ideally by referencing a Custom Permission that you place on the data load or integration user via a Permission Set.

Most likely because it is maxing out the callout limit

It's not, but you're right to worry about that because you're making one callout per Account, and the callout limit is 50 per transaction. So if the batch class is running at a batch size of 200, you have a problem there. If you have control over the batch size, you can turn it down at the cost of increased processing time.

The integration architecture you're using is inherently limited, though. It's never a good idea to fire one future call per transaction record.