As a transitional step, this site will temporarily be made Read-Only from July 8th until the new community launch. During this time, you can still search and read articles and discussions.

While the community is read-only, if you have questions or issues requiring TIBCO review/response, please access the new TIBCO Community and select "Ask A Question."

You will need to register or log in or register to engage in the new community.

Best practices for upgrading TIBCO BusinessWorks™ 5 Environments

Published:
9:10pm May 19, 2022

In lieu of the recent Apache Log4j vulnerabilities around Dec’21, almost every major enterprise felt the need to upgrade to the latest versions of their product stack along with their OpenSource dependencies primarily to remediate these security issues and data corruption problems. We at TIBCO, as an  Integration Platform provider, continue to release updated versions of its Integration products to keep our customers’ environment secure and vulnerable-free.

Apart from this pressing issue, we in general, hear a lot from our customers about the best practices and recommendations that they need to follow when it comes to the TIBCO BusinessWorks 5 products upgrade, as several of them keep on either getting retired or off maintenance. This article is going to highlight those aspects in detail.

 

Declarations:

  • This article will be limited to ActiveMatrix BusinessWorks (BW5), TIBCO Runtime Agent (TRA), and TIBCO Administrator (ADM) as part of the ESB (Enterprise Service Bus) architecture.
  • Detailed Product installation procedures are not included as part of this article. Please refer to the individual TIBCO Product Installation Guides for information on installing the individual TIBCO products and their compatibilities here.
  • This article does not cover other aspects of the ESB, including RAM/CPU requirements or usage, architectural improvements, capacity planning, performance, or high availability, and is limited to only upgrade considerations of these TIBCO products. 
  • At this moment, we have BW5.13.x, BW5.14.x, and BW5.15.x as part of the active BW5 offerings and we recently announced the BW5.13.x End Of Support. Please find the details here.
     

Considerations while upgrading to a newer TIBCO BW5 environment:

  • Minimizing downtime for any BW5 environment.
  • Providing a rollback strategy.
  • Minimizing the complexity of the product upgrades.
  • No new products or applications will be introduced during the product upgrades.
  • In most cases, projects developed in any version after BW5.2.0 (inclusive) can be deployed to BW5.15.x, but that couldn’t be guaranteed because of new features, fixes, and even some regressions.

 

Upgrade Strategies:

There are two different strategies that the customer can follow to upgrade their TIBCO BW5 environment from the versions currently they use to the latest versions. 

Upgrading Existing BW5 Environments:

The first strategy for upgrading the TIBCO BW5 product in the ESB environment is to upgrade from the current versions to the newer versions. This strategy is the more traditional approach as all of the current environment is upgraded, and new systems, network ports, etc. are not separately required. However, there can also be issues associated with this strategy, such as significant system downtime and limited rollback strategies. 
Best practices:
 
  1. No additional hardware is required (images, RAM, CPU, etc).
     
  2. Current TIBCO domains are maintained.
     
  3. In case of service pack/HF upgrade (BW 5.13.0 -> BW 5.13.2 / BW 5.14.0 HF1 -> BW 5.14.0   HF2), the BW engine points to the same BW_HOME, and there would be no major functional change and redeployment is not necessary before RT(Regression Testing). If the release notes of BW5.15.0 mention that it supports TRA 5.12.x / Administrator 5.12.x, then that should be fine to not touch those components, else we have to upgrade TRA and Administrator with the latest service release (for example TRA 5.12.0 and Administrator 5.12.0) at the same time BW is upgraded. We would recommend the customers to upgrade the whole stack of BW+TRA+Administrator as the configuration would include all the latest fixes in these components. In the case of BW upgrade, it is recommended to install the latest supported RV( in case it is used to manage data flows or used by Hawk to communicate with local micro-agents)  and EMS client version on the BW and Administrator servers and the latest compatible BW5 plugins and adapters.
     
  4. In case of a minor version upgrade with smaller gaps (BW 5.14.0 ->BW 5.15.0), only Redeployment is necessary before RT as the BW engine points to a different BW_HOME. In case errors are found, one can validate the project and rebuild the EAR. Any EAR that passes the RT can be reused without rebuilding and also considering the fact that rebuilding the EAR will not be necessary if we exclude the Plugins and Custom Java artifacts. We would recommend the customers to upgrade the whole stack of BW+TRA+Administrator as the configuration would include all the latest fixes in these components. In the case of BW upgrade, it is recommended to install the latest supported RV( in case it is used to manage data flows or used by Hawk to communicate with local micro-agents)  and EMS client version on the BW and Administrator servers and the latest compatible BW5 plugins and adapters.

     

  5. In case of a minor version upgrade with larger gaps (BW 5.11.0 ->BW 5.15.0), we would highly recommend rebuilding the EARs and saving time in RT and the same best practices can be followed as mentioned in point 4 as there is still a very high level of compatibility. In the case of BW upgrade, it is recommended to install the latest supported RV( in case it is used to manage data flows or used by Hawk to communicate with local micro-agents)  and EMS client version on the BW and Administrator servers and the latest compatible BW5 plugins and adapters.
     
  6. Post this, one needs to diagnose and fix the issues in RT. After completing the RT, apply the product upgrade and project modifications (if any based on the RT result) to the Production environment.
     

Running Parallel TIBCO BW5 Versions:

This strategy would be to install, configure, and run the new versions of the TIBCO BW5 products in a completely separate environment from the existing running versions at the customer’s end. This approach would allow for the use of the existing systems while running the two environments concurrently.
This strategy consists of installing and running the new versions of the TIBCO software on the same platform/OS as the existing software. To accomplish this, the following would be necessary:

 Best practices:

  1. Install the new versions of the TIBCO products in a separate TIBCO_HOME. Most of the TIBCO software product installations now provide the capability of installing the TIBCO software in a separate directory structure on the same machine without affecting the existing installations or configurations.
     
  2. The majority of the TIBCO products used by the customers, support running under the same user. However, there are a few products that do not, like MQ Adapter and BusinessConnect.Therefore, it is highly recommended to separate the software by user account.
     
  3. Create a new TIBCO Administration Domain for each of the environments associated with the individual ESBs. The new TIBCO Administrator can run on the same machine as the existing TIBCO Administrator. The following considerations should be taken:
     
    • New HTTP PORT for the Administrator’s URL
    • New Shutdown Port for the Administrator
    • New Rendezvous ports for Hawk (usually replaces 7474 and 7475)
    • New Rendezvous port for FT heartbeats (replaces 7500)
    • Additional ~1GB of RAM for the second TIBCO Administrator, RV daemon, and Hawk agent processes.  Will also require an additional ~250 MB of disk space.
       
  4. Other machines would join the new Administration domains. This would require that an additional set of RV Daemons and Hawk agents would run for each TIBCO Administration domain. This is estimated to require ~250 MB of additional  RAM, and ~250 MB of disk space, which should be verified by the customer at their end.
     
  5. The BW5  processes should not add any additional resources, as when the newer version of the process is started, the older version would be stopped.
     

Recommended Strategy:

It is highly recommended that the customer follow the second strategy, and build parallel TIBCO BW5 environments based on the new TIBCO product versions for each of their ESBs. Though there can be some disadvantages to this strategy, it is believed that the advantages of this strategy outweigh them. Here are some lists of advantages and disadvantages of this recommendation.

Advantages:

  1. Minimal downtime to upgrade to the new versions. In any environment (development, test, pre-prod, and production) for any of the ESBs, the actual downtime of BusinessWorks and the MQ Adapter will be minimal. In some instances, there may not be any downtime of the application.
  2. Straightforward rollback/downgrade strategy.  If for any reason, there are issues with the new TIBCO product versions, returning to the previous versions can be accomplished with minimal effort.
  3. Straightforward installation. All product installations are new, therefore, far less complexity with the installations, compared to upgrading existing installations.

Disadvantages:

  1. Adding more applications to the existing virtual servers. The different systems will take on additional loads during the testing of the different environments in each of the ESBs, requiring additional system resources. However, once testing is completed in each environment, and the new versions of the TIBCO product stack are in use, the old BW5 environments can be shut down and removed, regaining all system resources used during the upgrade and testing.
     
  2. New TIBCO administration domains must be configured to replicate all of the existing TIBCO administration domains currently in use. These will require new UNIX user accounts, TIBCO Administrator user accounts, HTTP and RV ports, database users/schemas for the repositories, etc.

    Note: All existing systems can be used to support both versions of the TIBCO products based on current usage. The system usage should increase mainly for additional Hawk and Administration processes.  However, The customer must verify current usage to ensure there are sufficient system resources available on the individual systems.

TIBCO BW5 Upgrade Impact from Java 8 to Java 11

Java 8 jar can run on a Java 11 VM and recompiling shouldn't be required and the EARs should work seamlessly, provided the Java 8 code is not using methods that are deprecated in Java 11, and also the Java code/activities shouldn't rely on 3rd party libraries that are not supported under Java 11. If there is any usage of features in Java 8 that are deprecated in Java 11, then the Java activities need to be recompiled and validated during the BW5 upgrade.

 

Summary

TIBCO continues to make your environment upgrade experience more reliable and streamlined. Version upgrades in Businessworks5 and its supplementary products allow for high data security, new features, and better performance. If there are any additional questions or queries about this post, please feel free to leave a comment or reach out to the Integration Product Management Team at integration-pm@tibco.com.