TIBCO announced the successor of their Active Matrix Business Works (BW) suite over two years ago on April 14th, 2014. The customers have been slow to adopt the new platform and we still see many solutions running or being developed on the older 5.x versions. The difference in the GIU for BW6 (Eclipse-based product vs TIBCO’s Designer) as well as the underlying architecture has been the main concern our clients have not upgraded yet.
According to TIBCO, when the clients are ready to migrate they should expect a smooth transition using the out-of-the-box migration tool which migrates the resources to the BW6 version with a high success rate. This article will explore the migration process and will try to answer the following questions: Is it really possible to move a huge project into the BW6 platform without significant code rework and more importantly – is it worth it?
Projects you migrate with the BusinessWorks Process Migrator tool
The best candidates for migration are code repositories that are stable, have no changes, and have been successfully running in production for a while. With this approach, you can eliminate the risk factors of adding new functionality that can make the migration more difficult. According to the documentation, TIBCO gives us a strong opinion that the BusinessWorks Process Migrator tool provides a pretty high success rate on code conversion and the following table explains what the tool converts automatically:
In addition to the core resources, the BW Process Migrator will transfer activities, transitions, and their associated mappings.
We tested the migration on a large customer repository and approximately 95% of the resources were transferred. Although the rate is high, the migration mostly translates the resources into the BW6 version (with lots of validation errors) and that’s pretty much it. It turned out that there are still quite a bit of items that we need to manually fix:
- Schema and WSDL locations require some fixing since the project structure changed and the BW Process Migrator cannot track all the references between those resources;
- Schema namespaces and prefixes need cleanup before fixing any broken XPath mappings;
- BW6 fully supports XPath 2.0, which means that some of the existing BW5 XPath custom functions or workarounds need to be updated;
- Multiple startup processes need merging in a single Module Activator process. This is because of the nature of BW6 of having a single Activator process with two service operations, On StartUp and On ShutDown;
- The exception handling process flows are treated in a separate way in BW6 EventHandler/Catch/CatchAll and there’s some additional work around that, in terms of figuring out how to achieve the same exception handling logic as in BW6;
- Broken Iteration groups;
- Some activities, like EngineCommand, need to be replaced with the corresponding activity types in BW6;
(TIBCO has documented only 3 activities as “Not supported” for the migration process (Notify, Get Context, Set Context) and 16 more are marked as “BW 6 Construct Under Consideration” EngineCommand is one of them. “Supported with Limitations” are all from REST and JSON Plug-in);
Having said this, the amount of work to migrate a project is less than building from scratch, but not insignificant as some may think after just reading the migration documentation. This is the reason why a non-changeable stabile project would be the best choice for a migration process, manual updates are unavoidable.
Projects that would require rework/redesign
There are more reasons why you need to consider remodeling your existing solution to better suit the new BW6 concepts and resources rather than just migrating the existing BW5.x code. The reason for this is that BW6 is a completely new tool in terms of application architecture and development patterns standpoint.
There are numerous advantages over the previous version that should be considered when making a decision on whether to migrate or continue using BW5:
- Microservices Architecture
You can build your microservice-based, lightweight platform using BW6 with out-of-the-box REST native support. This means that building a REST service is no longer the “workaround” you had in BW5 without the Plug-in for REST and JSON.
- Swagger 2.0 support with Swagger
You can now visualize and test RESTful services defined by the Swagger specification. It specifies the format (URL, method, and representation) to describe the REST web services.
- Compensation Handler
The compensate handler activity can reverse the overall process transaction when a fault is encountered outside a scope even if some activities passed successfully.
- Stateless Services
There’s an option available to choose between stateful and stateless design for a given service. For processes that involve related message exchanges between the same or different consumers, conversations correlated by the engine can be used to maintain state across operations.
- Runtime Architecture
BW6 moved forward towards a more flexible and scalable runtime environment. The applications run in an AppNode JVM which is similar to the BWEngine in BW5.x and the Domain logical isolation is still there for maintaining separate environments. The AppSpace is a new perk in BW6 and represents a logical isolation per application and can contain one or more AppNodes across multiple machines.
- Services can be created and deployed independently from each other. The level of modularity contributes to agile development and scalable solutions.
Our Advice
The reality is that TIBCO tries to help out the migration with the built-in migration feature, but they are too shy to admit that BW6 is a completely new product. Satisfied customers should be able to recognize TIBCO’s efforts to expand their flagship product which has been out there for more than a decade.
The new aspects of BW6 change the overall architecture mindset and embrace new ideas in designing a solution, which will definitely be better than the one designed years ago, keeping in mind the limitations and building style of BW5. There are more options for building and tailoring a new BW6 application, which will be in track with modern standards, and easier to organize, maintain, and extend.
According to our tests, the TIBCO out-of-box migration will only help you out with finalized, small, and lightweight solutions (with a fair amount of work in figuring out the errors and validation issues). We recommended to use the results of the TIBCO Migration Tool as a mapping reference.
For any larger and ongoing solutions we would not recommend straightforward migration, because even if the application is running in a brand-new container, it’s the same old BW5-like design and architecture running under the hood. In this case, getting back to the drawing board is probably the best approach.
