10
Roughly speaking, this is what Queueables are for. Once Transaction Finalizers are GA, I think they'll be a pretty good solution for this.
There are many concerns, though:
The Queues If you're starting batches from a trigger, you can overwhelm the flex queue pretty quickly. If you're starting Queueables, you can degrade the performance of other async ...
2
The problem isn't really the remote API - it's the design of your CalloutOne and CalloutTwo classes. With the logging DML in the position that it is, you can never call these classes more than once in a transaction.
Consider a different pattern. For example, you could pass in a Map<Id, List<Some_Logging_Record__c>> instance and let both callout ...
2
You can use JSON2Apex to generate the relevant code for parsing. The ideal solution for parsing is to use classes, which can then be deserialized to directly. I converted the code from there to a simpler implicit parser (because of an apparent bug in JSON2Apex), which gives us:
//
// Generated by JSON2Apex http://json2apex.herokuapp.com/
//
public class ...
1
Authorization in a header would be in the Authorization header. It appears that you meant to use query string parameters instead:
String authToken = 'myToken==';
PageReference ref = new PageReference('https://someWebsite.com/api/v1/SeeResource');
ref.getParameters.putAll(new Map<String, String> {
'access_token' => authToken,
'format' => 'json'...
1
One option is to use Merge Fields for Apex Callouts That Use Named Credentials. This won't explicitly give you access to the data from the named credential in Apex, but it will allow you to alter how it is used in any callout.
For example, you could define custom request headers:
// non-standard authentication
req.setHeader('X-Username', '{!$Credential....
Only top voted, non community-wiki answers of a minimum length are eligible
