#datawea

Point to Point Integration (P2P)

Point to point integration is integrating systems or applications with each other directly. This is a legacy integration pattern which has many disadvantages and obstacles as listed below:

Single Points Of Failure

No Course Of Action For Emergencies

Exponential Increase in Complexity

Loss of Agility

Enterprise Service Bus Pattern (ESB)

ESB pattern is a more flexible approach for application integration. This integration is achieved by encapsulating and exposing each application functionality as a set of discrete reusable capabilities. Hence applications do not integrate directly with each other instead, they integrate through an ESB infrastructure, as illustrated below:

Anypoint Studio

MuleSoft’s Eclipse-based development environment for designing and testing Mule ESB applications is known as Anypoint Studio. With Anypoint Studio one can develop their message flows between application to application with a graphical drag-and-drop editor (or edit the XML file if preferred). The designer can select all of the different components offered by Mulesoft in their message flows and configure them easily.

Out-of-the-box Components

Anypoint studio has hundreds of built-in components which are needed for integration development:

Message Sources/Endpoints — HTTP, FTP, TCP, UDP, File, Database

Message Processors — Components (REST, SOAP, Java, Python, javascript…), Filters, Routers (aggregators, splitters, round-robin…), Scopes (Flows, sub-flows, for-each, a-synchronous…), Transformers (convert XML, JSON, File, Byte Array, Object, String…)

Connectors — Anypoint studio comes with numerous connectors to third-party applications such as Amazon, Facebook, Google products, Sharepoint, MongoDB, Salesforce...

Dataweave Language

DataWeave is an expression language for accessing and then transform the data that travels through a Mule app.

In a mule message flow, the data being transferred from a component to the next component is called a Message. Hence mostly DW (Dataweave) is used to access and transform data in this Message. For example, after a source component in your flow gets a Message from one system, you can use DW to modify and output selected fields in that Message to a new data format, then use the next component in your flow to pass on that data to another system.

Mulesoft Message Structure

As stated earlier data transferred between components in a mule flow is called Messages. So one component will change/filter the input Message that it receives and export them to the next component so that it’s input Message will be that changed data.

Example 1: Listen to a Post Request from an HTTP Listener, Change the payload structure and save in a MySQL DB.

HTTP Listener Component

Here you should configure the HTTP Listener on what port is this Listener will be listening on and on what path should the caller call to invoke this Mule flow. For example, Listener Configuration would look like below:

So according to the above configuration of HTTP Listener, it would be listening via port 8081 and on path /insert-path .

And above code snippet shows the generated XML code for the configured HTTP Listener. So for every component that we configure in Mulesoft can be edited, created in XML too.

Logger Components

Loggers are used for logging the output message (mostly the payload) from the previous component. This is very helpful when you want to know and debug the output from a component.

Transform Message Component

This is one of the important components in Mulesoft. For all of the message transformations, this component is used mainly. And for doing the transformations, the Dataweave language is used.

DB Insert Component

This component is used to make a connection to the DB and insert the relevant data passed through the mule flow.

Example 2: Listen to a Post Request from an HTTP Listener, Invoke a Java method by passing the received payload, do the necessary changes to the payload from the java method, send the output from java method to another API Endpoint.