Moving Middleware to the Cloud? Here’s How to Survive the TIBCO BWCE Migration

For the past couple of years, I have extensively worked on migrating applications from on-Premise to AWS cloud. In this article, I would like to discuss the process of migrating middleware applications developed in TIBCO Business Works (BW) 5.x version to its cloud-native successor, TIBCO Business Works Container Editions (BWCE) 2.x version.

Migration Process

Application Analysis

The initial phase is to evaluate the existing BW applications, to assess the dependencies such as shared modules, libraries, and adapters, as well as unsupported activities, components, custom Java code, and non-standard configurations that required modification to ensure compatibility with the cloud environment. Key focus areas also included local file systems, application configurations, and legacy middleware connections.

(https://docs.tibco.com/pub/bwce/2.6.1/doc/html/GUID-C47A2AE8-F35F-4A49-861F-B1CA987E25A5.html).

Migration Pre-requisites:

1.Before migrating the BW project, ensure that the project is validated and has no errors. Unlike BW, BWCE checks for schema namespaces. Schemas with missing namespaces should be refactored. If any schemas do not have defined namespaces, then these need to be defined before migrating. Also, any spaces in the namespace should be removed.

2. Also to avoid conflicts during the migration process, ensure that any schemas, WSDLS, or DTDs do not have the same name across the project, nor any special characters.
3. All BW Projlib’s must be converted into shared Modules.
4. Replace all the file palette activities with S3 palette activities.
5. Replace all EMS palettes with SQS-SNS palettes.

Process to Migrate:

Steps to migrate the code -

1.     Open TIBCO Business Studio for BW, choose Project, and select Migrate BW projects, it brings up Project Migration Wizard window.

2. In the Project Migration Wizard window, select either “Migrate Single BusinessWorks 5.x Project” (to migrate a single application) or “Migrate Multiple BusinessWorks 5.x Projects” (to migrate multiple applications at once).

   

3. When we migrate only a single BW project, we have the option to migrate selective processes or subprocesses. If we choose the option to migrate multiple projects, “Select Processes for Migration” check box will be disabled.

4. Click Migrate Project

The following picture shows a sample project process flow in BW and BWCE after the migration. Activities, transitions, and their associated mappings visible in ActiveMatrix BusinessWorks 5.x project in TIBCO Designer are displayed in TIBCO BusinessWorks Container Edition project in TIBCO Business Studio for BusinessWorks.

Post Migration Manual Steps After migration, check for problem markers that are related to activity input mapping, use “Show Check and Repair” and the “Fix Type-Casting Errors” functions to resolve the errors.

Show Check and Repair

1. To clear the problem markers in the migrated project, click project.bwp.

2. Click the activity in your project, then click the Input tab.

3. Click the Show Check and Repair icon. The Mapper Check and Repair window is displayed.

   

4. Click OK and run the project.

Fix Type-Casting Errors

To fix the construct functions errors, click the Fix Type-Casting Errors icon

Deployment on ECS

Once the code is stable with all errors and warnings resolved, deployed the applications on Amazon ECS. Tasks were defined with precise memory and CPU allocations to optimize resource utilization. AWS Application Load Balancers (ALBs) were configured to manage traffic and ensure high availability across multiple containers.

Monitoring and alerting BWCE applications on ECS

Modify the ECS task definition to specify the "awslogs" log driver and set the appropriate log group and stream prefix, also ensure IAM role has the necessary permissions to send logs to CloudWatch.  Lambda services, cloud watch alarms, and SNS are used to generate alerts and notifications.