Migration from Mulesoft to Kumologica— Part 1

In our previous article “A journey from MuleSoft to Serverless Integration” 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 and youtube videos to get an insight. Kumologica 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

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

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

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

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

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

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

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

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

In Kumologica, Datamapper plays the role of data mapping. It follows JSONata based scripting. For more details on JSONata.

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

Kumologica message structure

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.

Kumologica is totally free to download and use. Go ahead and give it a try, we would love to hear your feedback. In the meantime, if there is any specific use case that you would like to see in a future article please let us know in the comments section.