Migration From Mulesoft to Kumologica — Part 2
This is the second part of our four-part series that will take a deep dive through a real-time use case of migrating a developed service on Mulesoft.
Join the DZone community and get the full member experience.Join For Free
This is the second part of our four-part series that will take a deep dive through a real-time use case of migrating a developed service on Mulesoft. The Mulesoft service described in this article will cover some of the patterns mentioned in our earlier article. We will learn how to migrate this service into Kumologica without negotiating the pattern.
For those who are new to Kumologica, I would recommend going 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 Serverless's new world. It provides a drag and drops visual designer and low code approach to ensure the greatest speed and flexibility to support a wide range of integrations compatible with most platforms and cloud providers.
An order processing service for an e-commerce platform is developed in Mulesoft Anypoint studio and deployed on CloudHub. The service consists of an API that accepts the order processing request (experience API) from the e-commerce UI and puts it into the Amazon SQS queue. Another service (process) that listens to the Amazon SQS queue to get the request message and send to two different services in parallel for processing, i.e., packaging service(out of scope) and logistic service(out of scope). In case of a failure, the order processing request will be pushed into the re-processing queue in Amazon SQS. This design is typically based on API led approach of Mulesoft.
Opinions expressed by DZone contributors are their own.