6
No, that's nor quite right. Imagine callout as animal and Http as cat, it's a subclass, not the actual class.
What I mean is you have 2 types of callouts in Apex:
Http http = new Http();
http.send(/*...*/);
and
WebServiceCallout.invoke(/*...*/);
Here is the documentation link.
4
The main difference between the two techniques is that with future methods, you can't make any future calls, but with Queueable, you're allowed one more Queueable call. Regardless, you can't call more than one Queueable per asynchronous call.
If you choose to call an InvocableMethod, you must remember to check if you're in asynchronous code or not:
if(!...
3
To say "Salesforce does not have limits for callouts" is completely incorrect. From the very document you linked to:
A single Apex transaction can make a maximum of 100 callouts to an HTTP request or an API call.
This per-transaction governor can be checked at any time in Apex by calling Limits.getCallouts().
The maximum cumulative timeout ...
3
I don't believe that syntax is supported. Instead, you could use Basic authentication:
Http http = new Http();
HttpRequest request = new HttpRequest();
String endpoint = 'https://mycURL';
request.setEndpoint(endpoint);
request.setMethod('GET');
request.setHeader(
'Authorization',
'Basic '+EncodingUtil.base64Encode(Blob.valueOf('username:password'))
);
...
2
Because you've got a different address here:
https://um1.salesforce.com/services/apexrest/Cases/
to here:
https://um1.lightning.force.com/services/apexrest/Cases/*
It's giving a 302 to the first request, you have an automated rerequest, but you haven't added the redirect url to your allowed settings.
Add - 'https://um1.salesforce.com/' url to allowed ...
2
With your goal being error handling in batch jobs, let me introduce you to the Winter '19 BatchApexErrorEvent!
It slices, it dices... It provides a mechanism to raise platform events from a batch job. More importantly, it is specifically designed for your error handling scenario.
The majority of details you need are covered in Building a Batch Retry ...
2
Firstly, it seems that the JSON example you provided is not a valid JSON (missing ',' between elements), I know it is just an example, but if you are using an array then it should have been enclosed with [ and ].
Now coming to the requirement, assuming that it is an array, JSON's deserializeUntyped returns Object which means it depends on what kind of JSON ...
2
Sending large files in multipart HTTP requests is not ideal because the file has to be encoded in a Base64 string and that format creates a huge overhead.
Is multi-part a strong requirement of your third party system?
If not, consider sending the file in a binary post, that should help you avoid those string length limitations.
1
The Choice resource is limited in its application and can't do what you want. However, the Quick Choice component can be installed and will happily accept a couple of string collections (one for the values and one for the labels) returned by your Apex invocable action
1
You can Make all the callout that need to happen first and then at the end make the DML operations that would stop the
you have uncommitted work pending. please commit or rollback before calling out
1
Initially HMAC was generate by apex using "crypto.generateMac" which very small and 32 bit in size, found a article we need to convert HMAC blob to base64 using "EncodingUtil.base64Encode" which will give you 64 character size which is again small compare to what i need to is around 88 character in size in order get work.
Again i reach end of solution, ...
1
There are certain limits to take into consideration when using queueables (like with pretty much everything in a multitenant environment as the Salesforce platform).
For queueables, you can schedule up to 50 queueable jobs in a single transaction, however once inside a Queueable context you can only schedule / chain a single (1) queueable job, in your case ...
Only top voted, non community-wiki answers of a minimum length are eligible
