Building AWS External Services
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.
Learn about Apex-Defined Types: the Glue between External Services and Flow
This is the original material on Apex-defined Types. Excellent reading for External Services users.
Authorizing Salesforce access to Slack
Oftentimes the biggest obstacle to integrating Salesforce with an External Service is the first step: configuring secure designated access to that service. Below are step-by-step instructions on using OAuth 2.0 to grant Salesforce the ability to post a message in Slack:
[Slack] App & App Credentials
Tell Slack about the Salesforce app that will need access your Slack workspace, and that it needs permissions to write messages.
1.Log into Slack as the administrator of the workspace you want to integrate with Salesforce.
2. In the Apps page, click on “App Directory” in the upper right hand corner.
3. In the App Directory, click on “Build” in the upper right hand corner, which should take you to api.slack.com.
4. Click on “Start Building”.
5. In the “Create a Slack App” modal:
a. App Name: enter an app name
b. Development Slack Workspace: select the workspace you want to Salesforce to access
c. Click “Create App”
6. Modal will close, and you will see the Settings -> Basic Information page for your newly configured app. In the “Building Apps for Slack” section, under “Add features and functionality”, click “Permissions”.
7. In the Features -> OAuth & Permissions page, scroll down to the “Scopes” section. For Bot Token Scopes, click “Add an OAuth Scope”, and choose “chat:write”.
8. Scroll up to the “OAuth Tokens & Redirect URLs” section, and click “Install App to Workspace”.
9. Click “Allow” to confirm you want this app to access your Slack workspace.
[Slack] Client ID and Secret
Retrieve the shared secret that Salesforce needs to use to access Slack:
10. In the Settings -> Basic Information page for your app in Slack, scroll down to the “App Credentials” section, and copy the values for the “Client ID” and “Client Secret” fields.
[Salesforce] Auth. Provider
Configure Salesforce to request access to Slack using the shared secret:
11. Log into Salesforce as an administrator for your org.
12. In the Setup -> Auth. Providers page, click “New” to configure a new auth. provider.
13. Configure the new Auth. Provider as follows:
a. Provider Type: Open ID Connect
b. Name: (choose a name for the Auth Provider)
c. URL Suffix: (choose a suffix to be used in client configuration URLs)
d. Consumer Key: (paste in the Client ID from step #10 above)
e. Consumer Secret: (paste in the Client Secret from step #10 above)
f. Authorize Endpoint URL: https://slack.com/oauth/v2/authorize
g. Token Endpoint URL: https://slack.com/api/oauth.v2.access
h. Default Scopes: chat:write
i. (Leave all other fields with their default values)
j. Click Save
[Salesforce] Callback URL -> [Slack] Redirect URL
Whitelist the Salesforce Salesforce Callback URL in Slack:
14. From Salesforce’s Setup -> Auth. Provider page, click to view the details of your newly configured Auth. Provider.
15. Scroll down to the “Salesforce Configuration” section, and copy the value from the “Callback URL” field.
16. In Slack, go back to the “Features -> OAuth & Permissions” page for the app from step #7 above.
17. In the “Redirect URLs” section, click “Add New Redirect URL”.
18. Paste in the Callback URL from step #15 above.
19. Click “Save URLs”.
[Salesforce] Named Credentials
Configure the Slack callout endpoint and authentication parameters.
20. Go back to Salesforce.
21. From the Setup -> Named Credentials page, click “New Named Credential”.
22. Configure the new Named Credential as follows:
a. Label: (choose a label for the Named Credential)
b. Name: (choose a name for the Named Credential)
c. URL: https://slack.com
d. Identity Type: Named Principal
e. Authentication Protocol: OAuth 2.0
f. Authentication Provider: (choose Auth. Provider you configured in step #13 above.
g. Scope: chat:write
h. Start Authentication Flow on Save: checked / selected
i. (Leave all other fields with their default values)
j. Click Save. The Authentication Flow will start.
k. Click “Allow”.
Extend the Power of Flow with External Services
Lightning Flow already empowers you to declaratively automate your business processes within Salesforce. But what if your business processes require integrations between Salesforce and other non-Salesforce services? Chances are that customer service agents who use Salesforce to track and resolve support cases would also need to access information from and/or submit changes to another backend system. Or perhaps you want a Flow to create a new record in Salesforce as well as post a message in Slack to notify the team. These are scenarios where you can leverage External Services to extend the ability of Flow to automate processes beyond Salesforce!
External Services provides a declarative way to access external business processes, whether they are proprietary APIs, public APIs, or other Salesforce APIs:
For any REST API that you want available as a callout from Lightning Flow, you just need to register the OpenAPI 2.0 specification for that API, so that it will be available as an action in Flow.
Configuring Flow to Integrate with an External Service
To support this integration, you just need to provide Salesforce with the following information:
- Named Credentials
- Where to configure this: Setup -> Named Credentials
- What these configurations tell Salesforce: Where is the external service being hosted (domain URL), and what credentials do we need to send for authentication?
- External Services:
- Where to configure this: Setup -> External Services
- What these configurations tell Salesforce: Where the OpenAPI 2.0 specification is located (relative to the domain URL of the Named Credential), and/or what the API specification is. The specification describes what API callouts Salesforce can make to the external service.
- Flow Action:
- Where to configure this: Setup -> Flow
- What these configurations tell Salesforce: Which action / callout you want to make to the external API, what input parameters you want to send, and what variable you want to use to store the response.
Example
This example shows how to the register the OpenAPI 2.0 specification for the Swagger PetStore API, as well as configure a callout to the PetStore API in Flow:
Named Credential:
External Service:
Flow – Add “findPetsByStatus” action:
Flow – Configure Input Parameters and Store Response:
Learn More
Here are some more resources for you to learn more about External Services: