Developing Integrations in Mulesoft

In our previous post we saw the overview of Mulesoft, why it is used and how it fits into the ESB ecosystem. In this post we will quickly see in brief the tools available for developing the integration application in Mulesoft

Anypoint Studio

Anypoint Studio is the graphical editor that is used to develop the Mule projects. This is built on top of the Eclipse IDE and hence the entire editor would give a very familiar feel if you have been acquainted with Eclipse or Eclipse based editor before. The editor has a drag and drop canvas on which the flows are designed. All the flows designed using the drag and drop canvas are internally stored as XML files. Hence we can also use the XML editor of the Anypoint Studio to design the projects.

The studio can be downloaded from https://www.mulesoft.com/platform/studio. Let’s look into the various components that are available in the studio.

Package Explorer

As shown above, on the left hand side of the canvas in the Anypoint Studio is the Package Explorer. It contains all the content of a mule application that we develop. Whenever we create a new Mule project, a default flow is created.

Canvas

The Canvas is the area where we design the flow. It is a graphical editor where in we can drag and drop the elements from the Mule Palette from the right side. The palette contains the basic building blocks of a flow. It contains various predefined components which can be used. With a closer look at the canvas we can see that there are three tabs at the bottom, namely:

1. Message Flow: Drag and drop interface to build flows.
2. Global Elements: Contains the elements which can be reused. It is generally a good practise to keep all the connection related attributes and configurations of the entire project in a single global elements flow.
3. Configuration XML: In addition to the graphical editor, the studio also provides an XML editor. All the building blocks that are placed on to the canvas are represented by their equivalent XML structure in the configuration.xml file.

As shown in the below two snippets, the XML is the exact equivalent of the flow that is dragged and dropped. So, we can edit either in the canvas or the xml editor.

Canvas

Configuration.xml

Mule Palette

The studio comes with a set of predefined building blocks that can be dragged on to the canvas to build the applications. These building blocks range from a simple File Connector to Enterprise connectors such as SAP, PeopleSoft, etc. The components on the Mule Palette are classified into the following types:

1. Connectors - used to interact with the third party APIs or Systems
2. Scopes - used to define the area or boundary until which the flow and the messages in the flow are visible
3. Components - used to execute the business logic
4. Transformers - used to modify or massage the data
5. Filters - used to conditionally pass the data
6. Flow control - used to route or broadcast the same message to more than one processor component.
7. Error handling - used to handle Exceptions
8. Security - used to provide secure access to information, applications and services

Now that we have understood the various parts of the Anypoint Studio, let’s try to understand a bit about how the data moves around in Mule.

Mule Message

Mule message is the data that passes through the application via one or more flows. The message is composed of the following:

1. Header - contains the metadata about the message.
2. Payload - contains the actual data that would be acted upon. The entire mule message is encapsulated in an object called as the Mule Message object. This object contains the following:

• Mule message
  • Header
    * Inbound properties
    * Outbound properties
  • Payload
• Variables
• Attachments
• Exception payload

The Inbound properties are the immutable ones and are set by the message sources, whereas the Outbound properties are set in the flow and these might act as inbound properties for the next connector.

The variables like in any other programming language are used to store some useful data. The variables are further classified into the following types:

1. Flow variables - specific to a flow
2. Session variables - available to all the flows within the app
3. Record variables - used in case of records of a batch context

Designing a Mule Application

The development of a Mule application starts with a Flow. Flow is the logical component which acts as a starting point of an application. The flow kicks in when it receives an input or an incoming message. Flows can be configured to be either Synchronous or Asynchronous.

As can be seen from the above figure, the Flow contains two parts. A message Source and a Processing unit. The flows can also be configured to have an error handling mechanism. There can be any number of flows defined in an application, and we can separate them on a logical basis, e.g. consider a flow which process the data from a REST source, another one which processes data from a SOAP endpoint, one from database and so on. There are unit names that can be used as flow reference and invoke one flow from another. Flows without a specific message source are termed as Private flows.

There are a couple of ways in which we can invoke or kick in the process:

1. Polling: We can define the Mule to poll an endpoint at regular intervals and then receive the data and process accordingly.

2. HTTP Listener: The mule flow can be made to listen on to a specific port and host. So whenever a request is received on the specific port, the mule flow starts.

The HTTP Component requires a connector configuration that defines the Hostname, the Proxy details, use of TLS etc. as shown below

Commonly used building blocks:

The following section defines some of the commonly used connectors for simple integrations.

1. Salesforce Connector

• Authentication Methods:

  1. Basic Authentication
  2. OAuth 2.0 JWT Bearer
  3. OAuth 2.0 SAML Bearer
  4. OAuth v2.0

• Salesforce actions:

  1. Insert / Upsert/ Update / Delete / Query
  2. Getting Session ids
  3. Streaming API
  4. Calling apex services
  5. Getting batch job details
  6. Converting lead
  7. Creating metadata, Deploying metadata

2. Database
   The database connector can be used to connect to the databases and perform operations such as select, update, insert.

3. Set Payload
   There can be instances when we would want to modify the payload as per the need, or set the payload to a specific value. In such cases we can use the set payload to define the payload to a new value. In general whenever we use any of the transformers, the payload is usually modified. Also, when an outbound connector is used, the response received from the connector becomes the new payload.

4. HTTP Request
   The http request configuration can be used in case of REST API services. This connector is used to invoke the outbound APIs. Whatever is defined as the payload prior to this step becomes the body of the API call in case of POST methods. The parameters such as Query parameters, URI parameters, and Headers can all be configured.

Well, this is definitely not all that Mulesoft has got and there is a whole lot of things that could not be covered in one single post. You can always refer the documentation which covers all topics in detail https://docs.mulesoft.com/. In the next post we will specifically see how Salesforce and Mulesoft interact with each other in an integration project.