Mule is an integration platform and lightweight Enterprise Service Bus (ESB) developed by MuleSoft. It’s a Java-based framework used for connecting applications, transforming data, and connecting IoT devices. MuleSoft is offered in On-Premise, iPaaS (Integration Platform as a Service) called CloudHub and Hybrid deployment models. MuleSoft’s Anypoint Platform provides a unified, single solution for iPaas and full lifecycle MuleSoft API Management.
ActiveMatrix BusinessWorks is the integration product suite developed by TIBCO. This software allows us to create services and integrate applications using a visual, model-driven development environment.
Both frameworks, ActiveMatrix BusinessWorks and Mule Runtime applications solve various enterprise integration problems. Here are some of the common integration capabilities both frameworks have:
- Integration to back-end systems.
- Connectivity to external applications using different protocols.
- Connectivity to legacy systems using adapters/connectors.
- Transformation of the message from one structure to another.
- Orchestration to multiple business services/APIs.
- Routing capabilities, to route the message based on the message content.
- A GUI-based development environment that allows zero-coding-based development.
ActiveMatrix BusinessWorks 5.x applications are developed using the development environment called Designer, which allows the developers to visualize the palettes and arrange the palette to build the business process application. Mule’s development environment has a similar approach which is built on Eclipse called Anypoint Studio. Anypoint Studio allows the developer to visualize the components to build Mule flows.
However, there are differences in how each of the frameworks works, their capabilities, ease of development, DevOps support, etc. The intent of this blog is not to compare the pros and cons of each framework, but to provide an overview of migrating ActiveMatrix BusinessWorks 5.x application to Mule 4 flows. In the sections below, we will discuss the migration of common components using ActiveMatrix BusinessWorks 5.x applications to Mule 4.x flow.
Even though both frameworks follow a similar approach to building applications, there are some differences in their terminology. ActiveMatrix BusinessWorks applications are called “Business processes,” whereas Mule’s applications are called “Mule Flows.” ActiveMatrix BusinessWorks’ single component is called “Activity,” whereas Mule’s component is called the “Message processor/component.” The entry point for Activematrix BusinessWorks applications is called “Process Starter Activity,” whereas the Mule flows endpoint calls it “Mule Source.”
Since they both follow a similar approach to building applications, most of the palettes in the applications built using ActiveMatrix BusinessWorks can be mapped to components in MuleSoft. Here are some of the guidelines for the migration of applications from ActiveMatrix BusinessWorks 5.x to Mule 4.x.
ActiveMatrix BusinessWorks (BW) has an activity called “Mapper,” which is used to transform the XML data from one message structure to another. These transformations use XPath and XSLT to transform the data. On the other hand, Mule provides DataWeave for transforming the data from one schema to another. DataWeave in MuleSoft’s proprietary expression language can transform the message formats, including DOM to XML, JSON to XML, Java objects to JSON, etc.
- Mapper palette in ActiveMatrix BW can be migrated to DataWeave in Mule flows.
- Xpath functions in ActiveMatrix BW can be migrated to DataWeave functions in Mule flows.
ActiveMatrix BW message routing between activities is based on transitions. Each transition has a condition to be met for successful routing, and transitions can define multiple routes based on the condition. ActiveMatrix BW uses Xpath/XSLT for defining transition logic. Routing in MuleSoft is provided by using “Choice” flow control, which can be routed to multiple message processors. Mule uses the Dataweave expression language for defining the logic, which is MuleSoft proprietary.
- ActiveMatrix BW’s conditional transitions can be migrated to Choice flow control in Mule.
- ActiveMatrix BW’s condition expressions can be migrated as Dataweave expressions.
ActiveMatrix BWs connect to external systems using Adapters, whereas Mule connects to external systems using Mule connectors. ActiveMatrix BW’s adapters are heavyweight, which needs to be installed to TIBCO Designer and runtime before using it, but Mulesoft connectors are lightweight, which can be configured in a pom file or can be added as modules that are dragged and dropped. There’s no need for installation required with Mule connectors.
Migration: ActiveMatrix BW’s Adapters are migrated to corresponding connectors in Mule.
ActiveMatrix BW connects to back-end databases using JDBC palettes, whereas Mule connects to back-end databases using Database connectors.
Migration: Each of the database activities in ActiveMatrix BW can be migrated to corresponding components from Database Module in Mule.
ActiveMatrix BW connects to files using File palettes, whereas Mule connects to files using File connectors.
Migration: Each of the file activities in ActiveMatrix BW can be migrated to corresponding components from File Module in Mule.
ActiveMatrix BW connects to remote FTP files using FTP palettes, whereas Mule connects to remote FTP files using FTP connectors.
Migration: Each of the FTP activities in ActiveMatrix BW can be migrated to corresponding components from FTP Module in Mule.
ActiveMatrix BW connects to JMS using JMS palettes, whereas Mule connects to JMS servers using JMS connectors. ActiveMatrix BW has separate palettes for Queues and Topics, but Mule has one component for both of them, which needs to be configured for Queues and Topics.
Migration: Each of the JMS activities in ActiveMatrix BW can be migrated to corresponding components from the JMS Module in Mule.
ActiveMatrix BW handles the SOAP using Service palette and SOAP Palette for SOAP listeners, whereas Mule uses APIKit for SOAP for Mule Source. For invoking the SOAP services, ActiveMatrix BW uses the SOAP Request Reply palette, whereas Mule uses Web Service Consumer for invoking the SOAP services.
- ActiveMatrix BW SOAP Event Source can be migrated to APIKit for SOAP in Mule
- ActiveMatrix BW SOAP Request Reply activity can be migrated to Web Service Consumer in Mule.
ActiveMatrix BW uses REST and the JSON Plug-in for REST APIs, whereas Mule REST API can use APIKit for REST, REST Connectors, and manually configure using HTTP connectors.
- ActiveMatrix BW REST APIs can be migrated to Mule using APIKit for REST or manually configured using HTTP Listener.
- ActiveMatrix BW REST invokes can be migrated to Mule using REST connectors or manually configured using HTTP Request.
Exception in ActiveMatrix BW is handled using the Catch Exception, Generate Error and Rethrow activities. Catch Exception is used to handle all exceptions or it can be configured to handle a particular exception. Generate Error is used to raise any business error based on condition, and Rethrow activity throws the exception caught by the Catch activity.
Mule exception is handled through the Error Handling scope, which uses on-error-continue and on-error-propagate components. The Raise Error component is for raising any business error based on the condition.
- Catch Exception in ActiveMatrix BW can be migrated to the Error Handling scope. If the Error does not rethrow to the parent process then the On-Error-Continue scope can be used in Mule. If the error is rethrown to the parent process, then the On-Error-Propagate scope can be used in Mule.
- Generate Error in ActiveMatrix BW can be migrated to Raise Error component in Mule
This blog provides guidelines XTIVIA recommends when migrating from TIBCO 5.X to MuleSoft 4.X. However, different approaches can be taken based on your enterprise/application needs, for example, overall system/application performance, responding to business agility, alignment to future goals, etc. We like to emphasize focusing on principles of MuleSoft like API-Led connectivity, self-service, etc., instead of migrating the project as-is.