Building AWS External Services

/0 Comments/in /by

I haven’t had a chance to really dig into this topic, but was asked about it recently and thought I’d assemble some known information.

Creating a Named Credential for AWS Signature V4

Salesforce has GA support for this as a Named Credential type:

Testing AWS Named Credentials

Use code like this Apex code to verify that your Named Credential works:

HttpRequest req = new HttpRequest();
req.setEndpoint(‘callout:EC2/?Action=DescribeImages&ImageId.1=*INSERT_YOUR_AMI*&Version=2016-11-15’);
req.setMethod(‘GET’);
System.debug(req.getBody());
Http http = new Http();
HTTPResponse res = http.send(req);
System.debug(res.toString());
System.debug(res.getBody());


Named Credential Setup:
URL: https://ec2.us-east-1.amazonaws.com/
AWS Region: us-east-1
AWS Service: ec2 (edited)

It retrieves an image from an EC2 endpoint (you will have to set up your own EC2 endpoint or some similar thing!)

Also check out this blog post from ForcePanda.

Creating an External Service for AWS

Here’s an example of a set of AWS endpoints that have been successfully ingested as External Service Registrations

In the above example, I ingested the specification for the AWS API Gateway service. I found it at Apis.guru, a useful online library.

External Service recently extended the size of the specifications that can be ingested from 100k to 1megabyte. That was critical to enabling the above ingestion example, because it is about 700k in size.

There are other AWS specs that are larger than 1megabyte. For example, the AWS EC2 spec is 2.4 megabytes, and can’t be ingested as-is. However, it’s definitely possible to carve pieces of them out. It can be tricky because different parts of the spec depend on other parts. But usually, for a given service, there’s an 80/20 rule, and a small number of API’s carry most of the load. Salesforce does intend to increase the size of ingestable specifications.

Authorization Headers in AWS Specs

Salesforce External Services recently added support for Authorization Headers in its processing of Open API Specifications. AWS uses Authorization Headers extensively in its apis. Take as an example the DeleteApiKey api from above. In the specification you’ll find a listing of a bunch of authorization-related input parameters:

Like all input parameters, these then show up in the property editor of the resulting invocable action:

Note that in the spec above, these are defined as ‘components’. Further down, the ‘components’ section of the spec informs External Services that these are intended to be used as headers:

The invocable action code generated as part of the external service registration will take the inputs provided to the invocable action and form them into headers for the resulting callouts.