In May of this year, Salesforce announced the acquisition of MuleSoft. MuleSoft Anypoint Platform, which will become part of Salesforce Integration Cloud, unlocks developer productivity on many levels. This post will guide you through some of the basic concepts for understanding Anypoint Platform and how they can be applied to your Salesforce integrations.

Use case

As a simplified use case we’ll imagine that our company sends its goods using various parcel services. Every parcel service has their own API, their own types of data, authentication, and so on. We want to integrate those APIs with our Salesforce org (or any other system) so that we automatically schedule pickups for new to delivered goods, see the status of current deliveries and so on.

To achieve this integration we have to do multiple things, like:

1. Read and understand the different APIs of the parcel services
2. Write Apex HTTP callouts for creating, reading, writing, and updating operations (for every parcel service, as they have different APIs). Don’t forget about:
   1. Data conversion and validation
   2. Multiple HTTP callouts for one request (like a search request that looks up customer name across all parcel vendors)
   3. Code coverage
3. Write and test Triggers or Process Builder flows for running some of the callouts
4. Set up Named Credentials for the authentication of every parcel service in your Salesforce org.
5. Start at step 1 when we add another parcel service.

All this is what is called “point-to-point integration.” You build out a programmatic connection to another system, just for this use case. It’s not re-usable by other systems. If someone in your company needs a similar service in a node.js or Ruby app, they have to go through the same process, which leads to duplicate development and maintenance efforts.

When you start reading about the capabilities of Anypoint Platform you will come across the term “API-led integration.” It’s super important to understand what this term means and how it impacts you to think about current and future integrations.

API-led integration is built upon three key elements within Anypoint Platform:

• API specifications
• Connectors
• Mule applications

API specifications

Every communication is based on an API. That’s the fundamental principle. In our use case we have the existing parcel service vendor APIs that we want to connect to. But we want to make them generally available to our whole organization, in a way that we have a single point of communication internally.

We create the specifications for those APIs within Anypoint Platform. If you have existing RAML or Swagger/OpenAPI specifications, you can directly import them too. This is what it looks like in the visual editor:

Why re-create/import the specification of an external API that we want to communicate with? This enables us to generate a custom connector for this API. And what is a connector? Glad you asked.

Connectors

A connector does what the name says – it connects to another system(s). MuleSoft, and their partners provide a large variety of ready-to-use connectors, templates, and API specifications on the Anypoint Exchange (it’s like the AppExchange, but for Anypoint Platform):

As you see, Exchange already contains a tile “ParcelService 1 REST API” as well as another tile “ParcelService 1 Connector.” Those two tiles are private to our organization. They’re not shared on the public Exchange, but can be discovered by other Anypoint Platform users within our organization.

The “ParcelService 1 REST API” tile represents the API specification that we created. Based on that spec, Anypoint Platform enables us to build a custom connector to that API, which then handles the HTTP callouts and so on. As mentioned before these things are discoverable by other internal Anypoint Platform users. If someone wants to use the same parcel service API for another use case, they can right away use the connector from here.

Relating to our use case this connector will now be used to create a new pickup order in the parcel service vendors system, when records in Salesforce change. And we achieve this with a Mule application.

Mule applications

At a high-level view a Mule application represents a deployable workflow, which can run on MuleSoft’s CloudHub, your own private cloud, on-premises, or a combination of those. By leveraging the built-in – and the custom – connectors, we build a data flow that spans Salesforce API and the parcel service API:

The declarative UI enables us to achieve the integration using clicks, not code. As you see we listen on modified records in Salesforce. No need to write any Apex callouts, triggers or Process Builder flows, or handle third-party system authentication in your org. All the integration is handled within Anypoint Platform.

As we have the data flow, we now have to take care that the parcel service system gets the right data from Salesforce. For that we add data transform operations within that flow using DataWeave:

The left-hand side represents data that is coming from the Salesforce connector, the right-hand side represents the data expected for the parcel service API. This is not restricted to drag-and-drop of data fields. You can also add, or change data along the way of a flow using DataWeave.

Summary

This post showed only a small excerpt of what Anypoint Platform is capable of. There are many other things that you can do, like build new composite APIs that unify data from various systems into a single API. Or run ETL tasks for data loading and offloading across multiple systems. We’ll dig into some of that in an upcoming blog post.

Till then, check out some of the developer posts on the MuleSoft blog:

• Part 1: Design Reusable APIs to Save Time: Learn multiple ways that you can create RESTful API services with Anypoint Platform and Anypoint Studio and how you can expedite getting your application together when creating the spec itself.
• Part 2: How to Design a Process API: Use your API specifications in DataWeave to transform your requests, plus upload your applications to CloudHub and build a higher level of APIs.
• Part 3: Build a Mule Integration with a Slack Slash Command: Build on the APIs you created in parts 1 and 2 and create a modular, reusable end-to-end solution — a new experience API that can perform DevOps processes from Slack via a slash command.

And now it’s time for you to get started! First, sign up here for a free trial of Anypoint Platform. Then head to the MuleSoft Developer QuickStarts to dive deeper into Anypoint Platform. It’s fun!

We will also be hosting a brand new webinar “Introduction to MuleSoft Anypoint Platform” on August 16th 2018, at 10:00 am PST. See more details and register for the webinar here.

About the author

René Winkelmeyer works as Principal Developer Evangelist at Salesforce. He focuses on enterprise integrations, Lightning, and all the other cool stuff that you can do with the Salesforce Platform. Follow him on Twitter @muenzpraeger.