Invoke a MuleSoft RPA Process from Flow using External Services

/0 Comments/in , /by

MuleSoft Robotic Process Automation (RPA) gives you the power to automate business processes that usually require human input and interact with systems that don’t have an API, extending the reach of Salesforce’s process automation capabilities by integrating these RPA processes into flows in Salesforce as of Winter ’23!

Use MuleSoft RPA Manager to publish REST APIs for your RPA processes to Anypoint Exchange, which you can then register as External Services in Salesforce and invoke from low-code tools like Flow Builder.

This post describes the configuration steps necessary to invoke a MuleSoft RPA Process in Flow Builder. It assumes familiarity with MuleSoft RPA, Named Credentials and External Credentials, Permission Sets, External Services, and Flow Builder.

Step 0: MuleSoft RPA Pre-requisites

  • Configure the connection between MuleSoft Anypoint platform and your org to import MuleSoft RPA APIs.
    • In MuleSoft RPA Manager, publish the RPA process as a REST API to Anypoint Exchange.
    • In MuleSoft RPA Manager, copy the API key from the User Management | User API Keys page.

MuleSoft RPA Manager: User Management page

Steps 1-3: Connect Salesforce to MuleSoft Anypoint Platform

These steps create the initial connection between MuleSoft Anypoint platform and your org:

  • Step 1: Create a Connected App in MuleSoft Anypoint Platform – A connected app in MuleSoft Anypoint platform allows Salesforce to call MuleSoft APIs.
  • Step 2: Create an Authentication Provider – Use the ID and the secret from your MuleSoft Anypoint Platform connected app to create an authentication provider.
  • Step 2b: Update Your MuleSoft Anypoint Platform Connected App – Use the Salesforce authentication provider callback URL to update your MuleSoft Anypoint Platform connected app.
  • Step 3: Create a Legacy Named Credential (Retrieve APIs) – Create a legacy named credential to access/authenticate into your MuleSoft Anypoint Platform connected app from Salesforce and retrieve the APIs published to MuleSoft Anypoint Exchange. The legacy named credential stores the URL for MuleSoft Anypoint Platform. External Services uses the legacy named credential when listing the MuleSoft APIs available for import.

Note: the ability to create a ‘Legacy’ named credential is still supported, although it will be discontinued in a future release, at which point, this portion of the instructions will be updated to reflect the new capability.

Salesforce: Named Credentials Home Page

Step 4: Create a Named Credential (Runtime) and External Credential

Note: MuleSoft RPA authenticates clients invoking RPA processes through API keys. The Salesforce Winter ’23 release includes new functionality in Named Credentials and External Credentials that supports this type of authentication.

  • Create an external credential, permission set mapping and custom header
    • Overview
      • Create a second named credential that stores the endpoint for MuleSoft RPA Manager. External Services uses the second named credential when invoking “runtime” the MuleSoft RPA process in a flow.
    • External credential:
      • Before creating a second named credential, first create an external credential.
        • Create an external credential to capture the API key and other authentication details.
        • Then create a named credential to store the actual endpoint.
        • This allows for multiple endpoints to be addressed with the same authentication configuration.
      • After entering the details for the external credential, click Save. You’re taken to the Named Credentials screen. Now you need to create a permission set mapping for this new external credential. This mapping ensures that only the correct users get access to these credentials.
    • Permission set mappings:
      • Click External Credential and select the external credential you created.
      • Scroll to Permission Sets Mappings so you can link the external credential to a user’s permission set.
      • Click New to create a permission set mapping for this external credential using the details below for an external credential that uses ‘Custom’ as the authentication protocol.
    • Custom headers:
      • Lastly, create a custom header for this external credential using the the details below as guidance for how to create a custom header.

Example
Salesforce: External Credentials Detail Page

  • Create a named credential
    • Now that you have an external credential, create a named credential and then link it to the external credential you just created in the previous step. As mentioned before, this second named credential stores the endpoint for MuleSoft RPA Manager. External Services uses the second named credential when invoking “runtime” the MuleSoft RPA process in a flow. Use the details below for how to create a named credential.

Example

Salesforce: New Named Credential Window

  • Verify that the external credential and the named credential you just created are linked
    • From the Named Credentials page, click External Credentials.
    • Click the name of the external credential from this list and confirm that the named credential you just created appears in the Related Named Credentials area shown in the example below.
    • As a reminder:
      • The Named Credential stores the MuleSoft RPA Endpoint
      • The External Credential stores the MuleSoft RPA API Key + Authentication details

Example
Salesforce: External Credentials Detail Page

Step 5: Register the MuleSoft RPA API as an External Service

As you are configuring the external service, recall that you created two named credentials.

  • Legacy named credential (Retrieve APIs) – this named credential stores the MuleSoft Anypoint platform URL and is used to retrieve the APIs published to MuleSoft Anypoint Exchange. Use this named credential in the “Select a MuleSoft Anypoint Platform Account” screen.

Example

  • Named credential (Runtime) – this named credential stores the MuleSoft RPA Manager URL and is used when invoking “runtime” the MuleSoft RPA process in a flow. Use this named credential in the “Configure your MuleSoft Anypoint Platform Service” screen.

Example

Example

Step 6: Invoke a MuleSoft RPA Process in a Flow

  • Now you are ready to start and check the status of the MuleSoft RPA process from a flow.
  • If you follow the steps outlined in the help docs Invoke a MuleSoft RPA Process in a Flow, listed below are a few additional tips to help guide you through the flow configuration.

Create Resource for RPA Process Input Variables

Tip: In step 2, when creating a New Resource to store the input variables for the RPA process, you can obtain the External Service Name and Apex Class Name from the External Services Detail Page to help configure the New Resource

Salesforce: External Services Detail Page

Assign Values to RPA Process Input Variables

Tip: In step 3, you can obtain the information about each variable/input parameter that needs to be defined in the above Apex class from the External Services Detail Page as well as the OpenAPI specification (a few examples shown below).

RPA Process OpenAPI Specification

OperationId: startProcess > ProcessExecutionWithExecutionId

ProcessExecutionWithExecutionId > ProcessExecution

ProcessExecution > inputArguments

Summer ’22: External Services Updates

/0 Comments/in , /by

Check out some of the changes and enhancements to External Services in the Summer ’22 release!

Call External Services Registrations Natively from Apex

Now you can access External Services registered actions directly from Apex to tap into reusable functionality when writing Apex code. Previously, actions created through External Services were exposed exclusively for invocation through Flow or Einstein Bots.

Check out the Summer ’22 Release Readiness Live demo (starts at minute ~3:20) and Developers’ Blog for a simple walkthrough of how to use this functionality.

Make sure to check out the official Salesforce Help Docs: Invoke External Service Callouts Using Apex for more details!

Salesforce Developer Console

Update an Existing Schema Connected to Flow

If a registration is in use by a flow, now you can update it with a new, compatible API specification version. Previously, you couldn’t update a registered schema that was in use by a flow. If the new schema version isn’t compatible, the edit workflow notifies you which operations and schema objects are in use by which flows and by which Apex classes. With this information, you know which existing references are incompatible so that you can remove them before saving your updated registration.

For details about supported and non-supported changes, see the official Salesforce Help Docs: Appendix 1: Schema Update Considerations.

External Services: Edit Screen

Register More APIs

Now you can register an external service without manually editing the schema before registration to conform to the 80-character limit for derived operation and object developer names. This enables you to register more APIs with less friction!

Additional Details

For additional details, make sure to review the Summer 22′ Release Notes and keep the feedback coming in the External Services Trailblazer Community!

Learn MOAR in Spring ’22 with OpenAPI 3.0 Support for External Services

/0 Comments/in /by

Check out all the enhancements you can look forward to with the Spring ’22 release!

External Services is a feature of the Salesforce Platform that empowers customers to connect Salesforce to external business actions and build process integrations without writing custom code.

UnofficialSF has a new Service Cloud Channels Section

/0 Comments/in , , , , , /by

UnofficialSF.com has added a new section devoted to Service Cloud channel functionality, which is increasingly driven by flow-based services.

Check it out here. If you know of a good post or page on the topic, don’t hesitate to let us know via the form on the home page.

WINTER ’22: EXTERNAL SERVICES ENHANCEMENTS

/0 Comments/in /by

Check out some of the changes and enhancements to External Services in the Winter ’22 release – supporting even larger API spec sizes (4MB!) and improving the registration workflow with rescoped limits!

Import MuleSoft Anypoint Platform APIs via External Services

Import your MuleSoft Anypoint Platform APIs in a few clicks. Previously, you needed to manually export your Open API 2.0 specifications from MuleSoft and import them into an external service. Now, all you need to do is select your MuleSoft Name Credentials and let Salesforce do the heavy lifting of importing your endpoints and converting them into actions.

Revised and Expanded Operation, Action, and Object Limits

You can register even more complex, publicly available API specifications. Most registration limits have been rescoped from a per API spec limitation to a per org limitation, and have been expanded.

Map Non-Standard Media Types in Your Registration

A Salesforce administrator, developer, or ISV can edit the compatible media type mappings in an external service registration for OpenAPI specifications with unknown or non-standard request or response media types.

For Winter ’22, we’ve provided a workaround. With the Metadata API, you can manipulate a registration and override the definition of the custom header.

External Services in Einstein Bot Builder

Add an external service’s action to your bot from the Bot Builder. Previously, you could only add an external service’s action to your bot via a flow.

Major Enhancements to the Trailhead Experience

Make sure to check out the newly revised External Services Trailhead module – we’ve made some major enhancements based on your feedback.

Additional Details

For additional details, make sure to review the Winter 22′ Release Notes!

Learn MOAR with Summer ’21: External Services Enhancements

/0 Comments/in /by

Check out the announcement regarding all the improvements shipping in the Summer ’21 release!

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.