In May of this year, Salesforce announced the acquisition of MuleSoft. The 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 and how they can be applied to your Salesforce integrations.
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:
- Reading and understanding the different APIs of the parcel services
- Write Apex HTTP callouts for create, read, write, and update operations (for every parcel service, as they have different APIs). Don’t forget about:
- Data conversion and validation
- Multiple HTTP callouts for one request (like a search request that looks up customer name across all parcel vendors)
- Code coverage
- Writing and testing Triggers or Process Builder flows for running some of the callouts
- Setup Named Credentials for the authentication of every parcel service in your Salesforce org.
- 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 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:
- API specifications
- Mule applications
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. 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.
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 Exchange (it’s like the AppExchange, but for Anypoint):
As you see the 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 users within our organization.
The “ParcelService 1 REST API” tile represents the API specification that we created. Based on that spec, Anypoint 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 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.
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.
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.
This post showed only a small excerpt of what the 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:
And now it’s time for you to get started! First, sign up here for a free trial of the Anypoint Platform. Then head to the MuleSoft Developer QuickStarts to dive deeper into the Anypoint Platform. It’s fun!
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.