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.
Top comments (0)