Salesforce Integrations using Mulesoft

In our previous posts on inteygrate we have seen few integrations by writing Apex classes, creating Web Services, using Salesforce in-built features, utilising wrappers (written in Python, PHP etc.) and downloading apps from AppExchange. In this and next few articles we will discuss about Mulesoft - an emerging ESB and an integration platform.

Why Mulesoft?

Many a times, exceptional companies extensively use Salesforce on a large scale with two or more Clouds and most of the times they are required to integrate their applications with not just one external system but many external systems.

Below are some real world examples of external systems:

1. Invoicing Systems
2. Data Management Systems
3. Legacy Systems
4. ERP systems like SAP
5. Social networks - Facebook, Twitter, Instagram etc.

All the above mentioned integrations can be done right from the Salesforce instance, but with this we simply crank out the custom code over and over; making the whole process of developing and maintaining integrations slower and inefficient. This is where dedicated middleware tools like Mulesoft play a crucial role.

What is Mulesoft?

Mulesoft is a Java based ESB and an integration platform designed for rapid and easy development. The primary advantage of Mulesoft is that it can be used to integrate anything from a plain old java object to a component from other frameworks. The fact that it is HIPPA compliant enables us to use it for healthcare domain related integrations where patient data confidentiality is critical.

Mulesoft as an ESB

ESB stands for the Enterprise Service Bus, and is a specific type of architecture designed to let applications talk to a common bus instead of the point to point interaction. This approach lets the system to be highly scalable, and brings in the concept of plug-n-play. The core concept of the ESB architecture is that each system when it interacts with the bus, need not be aware of all the others systems that are talking to the bus. By doing this, we end up designing applications in which the addition of new systems into the network does not bring about a lot of changes. As an additional consideration, use of an ESB is beneficial when we have at least 3 systems to integrate.

Mulesoft Versions:

Mulesoft has an Enterprise and a Community version offering. Even though both the versions are built on the same code base and offer the same underlying design there are considerable differences between the both. One of the major differences is that the Enterprise versions provide a Mule Management Console that can be used for the Deployment, Alert Management and an out of box Repository in addition to the Server Clustering.

From a development point of view, another key difference is that the Enterprise version has the support of more connectors that can be used for integrations. A key connector named Datamapper ( Deprecated ) or the DataWeave ( using the Transform Message connector ) is only available in the Enterprise version.

From a product perspective there are many other differences such as the provisioning of technical support, etc. A high level set of features that are available only in Enterprise version is as follows:

1. Deployment management console
2. The Batch Processing module
3. Premium connectors such as SAP, and HL7
4. Support for Caching
5. Use of Anypoint templates

For a comprehensive comparison please refer [this](https://www.mulesoft.com/platform/soa/mule-esb-enterprise" target="_blank) documentation.

Now that we have understood what an ESB is, and how Mule fits into the entire ecosystem, in our next post we will try a simple example to understand how can we develop the integrations on the Mule ESB.