Migration from Mulesoft to Kumologica— Part 1
Tags: aws, serverless, microservices
Published: 2020-11-27 11:18:35

In our previous article “[A journey from MuleSoft to Serverless Integration](https://medium.com/@kumologica/a-journey-from-mulesoft-to-serverless-integration-c906e2670745)” we discussed the need, benefits, use case and an example of moving a Mulesoft flow on to serverless based implementation using Kumologica. Based on the feedback we have received from our users we are introducing an article series demonstrating the migration of popular flow patterns and components from Mulesoft to Kumologica.

This is the first part of our four part series we are publishing which takes you through the steps for migrating your application from Mulesoft to a serverless integration using Kumologica. Mulesoft follows the EAI (Enterprise application Integration) patterns based on which the Mulesoft processors and connectors are aligned. We will discuss some of these patterns as we move through the series.

For those who are new to Kumologica I would recommend to go through our [articles](https://medium.com/@kumologica/) and [youtube](https://www.youtube.com/channel/UCsTDAlhijUFpsfThJu3hF9g) videos to get an insight. [Kumologica](https://kumologica.com/) is one of the early players in this space which brings the benefits of the low-code integration capability of traditional integration like Mulesoft to the new world of Serverless. It provides a drag and drop visual designer and low code approach to ensure the greatest speed and flexibility to support a wide range of integrations compatible with most of the platforms and cloud providers.

## Flow elements

As a developer, before taking the initial steps in migrating the from Mulesoft it is important to understand the basic elements of Kumologica that can replace the Mulesoft processors. A Mulesoft flow consists of connectors and processors. In Kumologica this is called as nodes. Nodes in Kumologica can be connectors as well as processors.

**Flows and subflows**

In Mulesoft the flow consists of a source that can trigger the processing section which holds set of processors. eg. HTTP listener in source section of flow triggering the logger in processing section. The subflow unlike flow consists of only processing section.

![Mulesoft flow and a subflow](https://cdn-images-1.medium.com/max/2000/1*nvWA0VgCFCGeUvJUxlUI5g.png)*Mulesoft flow and a subflow*

In Kumologica the flow block is represented with an **Eventlistener** and **Eventlistener End** node. The Evenlistener node is the triggering section and all the processing nodes placed between the Eventlistener node and Eventlistener End node. The subflow equivalent in Kumologica is **Processor In** and **Processor Out** node.

![Kumologica flow and subflow](https://cdn-images-1.medium.com/max/2392/1*wgKph3tDbLjnd888ZhR4lQ.png)*Kumologica flow and subflow*

**Message routing**

In Mulesoft, the popular message routing processors are choice, collection splitter, collection aggregator and scatter-gather.

*Route based on condition*

Choice router is the processor in Mulesoft for routing the flow based on a condition.

![Mulesoft flow with choice block](https://cdn-images-1.medium.com/max/2000/1*RLDajDWlNbINDpTh5nj3aQ.png)*Mulesoft flow with choice block*

In Kumologica we use **switch** node which routes the flow based on a given condition.

![Kumologica flow with switch node](https://cdn-images-1.medium.com/max/2100/1*Jmf6uE-Ke5BEb3o_t9cmzg.png)*Kumologica flow with switch node*

*Split message to fragments*

In Mulesoft a collection object (array) is split into individual records or fragments and send to next processor using collection splitter. The end of collection iteration is managed by collection aggregator.

![Individual records send to database after split](https://cdn-images-1.medium.com/max/2000/1*dPKi-BZFWMCi8UYP5GTNDw.png)*Individual records send to database after split*

In Kumologica an array of record is split into individual records or fragments and send to next node using **split** node and **join** node. Here the split is equivalent to collection splitter and join is equivalent to collection aggregator.

![Individual records send to database after split](https://cdn-images-1.medium.com/max/2256/1*hlVFMpRh-9v-3uD6IgOkoA.png)*Individual records send to database after split*

*Sending message to multiple targets*

In Mulesoft a of copy message is send to multiple targets and the response from each target is collected using scatter-gather processor.

![Mule flow with scatter-gather processor](https://cdn-images-1.medium.com/max/2000/1*wDIdOOHByY8qvBioCj9xAA.png)*Mule flow with scatter-gather processor*

In Kumologica a copy of message is send to multiple targets the response from each target is collected using **scatter** and **gather** node.

![Scatter gather node in Kumologica flow](https://cdn-images-1.medium.com/max/2532/1*WqwXFtk4maK958fjSRnyHQ.png)*Scatter gather node in Kumologica flow*

**Message Transformation**

In Mulesoft, the popular message transformation processors are dataweave, JSON-Object, XML-Object etc. Dataweave is the heavily used data mapping processor in Mulesoft which following dataweave scripting expression language.

![Dataweave editor](https://cdn-images-1.medium.com/max/2000/1*lYRLO_gx1gZkK1Fjzr0kag.png)*Dataweave editor*

In Kumologica, Datamapper plays the role of data mapping. It follows JSONata based scripting. For more details on [JSONata](https://jsonata.org/).

![Datamapper editor](https://cdn-images-1.medium.com/max/3352/1*4NO34AZNPvpv0qdRuV5lSg.png)*Datamapper editor*

**Custom logic implementation**

In Mulesoft the custom logic is implemented primarily using Java component. In Kumologica this is achieved using the **function** node. The function node allows you the write the code in javascript.

**Message structure**

Mulesoft message structture

![](https://cdn-images-1.medium.com/max/3196/1*PeG6ikiYzL0__s7Jx2Qxzg.png)

Kumologica message structure

![](https://cdn-images-1.medium.com/max/2000/1*EPFTH-cIfDarG_r1y6zpXw.png)

Mule message structure and Kumologica message structure are almost similar structure with very minimal difference in hierarchy.

**Accessing message structure**

In Mulesoft message structure is accessed using MEL expression or using dataweave script. In Kumologica message structure is accessed using JSONata expression.

*Accessing payload* *in* *Mulesoft*

    In mule 3.9 and lower
    #[message.payload]
    In mule 4.0 and above
    #[payload]

*Accessing payload in Kumologica*

    msg.payload

*Accessing variables in Mulesoft*

    #[flowVars.<<variable name>>]

*Accessing variables in Kumologica*

    vars.<<variable name>>
## Conclusion

This article would have given you the basic understanding on the flow construct that we will be using and referring in our next article in the series where we will migrate a real time Mule flow to Kumologica and deep dive further into each flow elements.