This healthcare company had undergone an organisational restructuring and wanted to adopt a more agile approach to business development. They were running legacy applications on an older version of MuleSoft, so it was difficult for the organisation’s IT to keep up with the demands of the business. Coforge helped migrate their legacy Mule applications from Mule 2 (version 2.2.6) to Mule 3 (version 3.8.1) enabling them to unlock the new platform offerings and deliver business change faster.
The technical challenges
Mule 2 services were XML with no GUI (graphical user interface) visualisation of the service components. The services used a custom Mule Message object to extend the default object, and had several custom Java classes with Java-based transformers for messaging and executing core business logic. All transformer classes were based on the custom Mule Message object. A variety of services such as Restful APIs, consumer message and response, consumer message success and failure, and asynchronous archive and purge batch data transfers were all in a single application.
Challenges in migrating these services:
- Understanding the core business logic and retaining custom Mule Message objects for business to technical service integration.
- Elimination of the deprecated Mule components whilst ensuring minimal impact on services.
- Creating benchmarks for functional tests that can be executed against Mule 2 and Mule 3 services.
- Keeping the migration changes to a minimum to ensure no impact on the service to consumers.
The solution
Coforge proposed a phase-by-phase migration of services.
Phase 1: Batch functionality was first separated from the Mule 2 legacy application and migrated to Mule 3 with minimal change.
Phase 2: Creation of a benchmark for functional tests by extending the existing Junit tests using proper assertions and the additional of new tests covering all Mule 2 services. These tests were developed in such a way that they can be executed against the old Mule 2 or new Mule 3 services.
Phase 3: All Mule 2 services were migrated to Mule 3 and benchmark tests used to identify any issues and implement a fix.
The organisation was already running some applications on the latest version of the Anypoint Platform (version 3.8.1) with different naming conventions and guidelines for Mule 3 applications, which meant some tradeoffs needed to be agreed with the technical team to facilitate the migration. The migration was carried out with the view that deprecated components should be removed but core business logic within java classes kept. The Mule 2’s heavy dependence upon custom java transformers meant only a few could be replaced with MuleSoft’s out-of-the-box transformers.
Change highlights:
- Service models in Mule 2 were converted to flows in Mule 3
- Generic inbound and outbound components were replaced with specific components to improve the flow readability
- Connector-level exception strategy replaced with flow-level exception strategy
- All JDBC endpoints replaced with database endpoints
- Poll scope used for database polling instead of quartz-based
- Replaced retry-simple-policy with reconnect in all connectors
- Removed pass-through routers not needed in Mule 3
- Replaced synchronous property with exchange-pattern = “request-response”
- Used request-reply for asynchronous processing
- Replaced deprecated Mule API calls with appropriate API calls in Mule 3
The Result
The Mule 2 to Mule 3 migration has helped the company achieve the following:
- a fully supported MuleSoft implementation
- a reduction in the maintenance overhead of managing two different versions of the MuleSoft platform
- access to new MuleSoft Anypoint Platform offerings and an agile approach to delivering change
If you want to find out more about migrating from a previous Mule version then then give us a call on +44 (0)203 475 7980 or email us at Salesforce@coforge.com
