dmmckinn 1200006SCS Visits (1288)
End of Support (EOS) information is available in advance of planned dates to provide you with enough time to start planning your upgrades to newer product versions. When planning your upgrades, you should review the product releases you currently have installed and check to see if they have reached (or are nearing) their end of support. Below is a list of upcoming End of Support dates for some of our Watson Internet of Things products.
The following product releases are currently scheduled for End of Support. Further details can be found in .
Withdrawal from support date of 31-Dec-2019
Withdrawal from support date of 30-Apr-2020
Withdrawal from support date of 30-Sep-2020
For more information regarding planned End of Support (EOS) dates for other software products and releases seen Software Support Lifecycle.
dmmckinn 1200006SCS Visits (7730)
Are you planning an upgrade and looking for information about what product versions have reached or are about to reach their end of support?
There are a number of product vers
Below is a list of the most recent and upcoming End of Support dates for some of our Watson Internet of Things products.
This list was originally posted in September 2016 (see Plan
AcdntlPoet 2700019V2G Visits (8806)
Here's a quick and dirty rollup of the latest Maximo Anywhere upgrade information as well as the Maximo Asset Management iFix releases recently published via the Asse
Arun K Sriramaiah 2700076GE8 Visits (10472)
RTC upgrade from 5.0.2 to 6.0.3
HTTP Status 404 - ProxyServlet: /cqconnector/
Workaround tomcat library for CQ synchronizer 603 upgrade.
1. Before upgrading the CQ synchronizer from 5.0.2 to 6.0.3, take backup of tomcat libraries present in gateway/tomcat folder.
JeffLong 270005B0Q4 Visits (7847)
If you have installed IBM Tririga with WebSphere Liberty Profile, you may find a need in the future to update the JAVA version you are running in WebSphere Liberty Profile. If you need guidance on how to do so, please refer to the following documentation:
If you need additional assistance please contact support.
Many times, a client may hear a support engineer say that they should upgrade to the latest version. Why do I keep hearing that - especially if upgrading will take time, money, and resources? TRIRIGA, like all other software, evolves. We continuously fix defects and add new functionality. For instance, if you are on version 3.3.2, some of the features you cannot take advantage of include improved logging capabilities, which makes it easier for us to help you troubleshoot an issue. Also included is improved security and, more recently workflow versioning. Since complex software can sometimes have defects you never know when a defect might impact your business. But why wait for it to impact you? Upgrade so that it won’t happen. New functionality is also added into the software and you may want to take advantage of it.
Another reason to upgrade is that software uses various technologies, which changes faster than New England weather! Technology is constantly changing and TRIRIGA must keep up in order to keep it running. That technology can be in operating system updates, browser versions, application servers and Java to name a few. Support may often recommend staying current with product releases but it is always good to review the release notes for the current release. The release notes for each version show what has been fixed and functionality that has been added. You can find the release notes for TRIRIGA here:
Before upgrading, it is important to understand the structure of TRIRIGA because there are 2 very different procedures to upgrade. Those 2 structures are Platform and Application. The TRIRIGA Platform is the java code that IBM writes and is installed on a server. The TRIRIGA Applications are developed using the TRIRIGA Platform. Applications are not “written” but are developed using the Platform as a development tool. Applications are stored in the database as metadata and are not found in the TRIRIGA directory structure. Both the Platform and the Application have their own version number. How do I tell what number is for what? Platform versions are the lower of the 2 numbers associated with a TRIRIGA install. So the Platform version would be something like 3.5.1 or 3.4.2. Applications are the larger numbers associated with a TRIRIGA install. So the Application version would be something like 10.5.1 or 10.4.2. TRIRIGA 3.5.1/10.5.1 is Platform 3.5.1 and Application 10.5.1. But this can change. If IBM releases a 4.1.0/11.1.0 release, a client can upgrade to Platform 4.1.0 and leave the application at 10.5.1. But you can never upgrade the Application beyond the platform it was built on. So using the example of 4.1.0/11.1.0, you could not upgrade the application to 11.1.0 and still be on platform 3.5.1 because the functionality required to support the new Application exists in the new Platform.
The TRIRIGA Platform will always be there as it is required for the database to be run. The Platform never deprecates functionality. So if an application is developed on one release of the Platform, it will continue to function in future releases of the Platform. Ever since the 3.2 release, you can easily upgrade the Platform in under 2 hours. You simply stop the servers, install the new platform code, start one server to perform the database updates and when it is complete, stop the server, apply the latest fixpack, start one server and then start the rest. That’s it! The Platform will be upgraded. Security vulnerabilities, new technology, performance enhancements, new properties and more are ready to use. You should plan to perform a Platform upgrade at least once a year.
Applications can be substantially more complex. If you have never done one, I would strongly recommend that you consider engaging our IBM Global Business Service (GBS) or one of the IBM TRIRIGA certified business partners to help you through an application upgrade. Since the applications are actually data in the database, an upgrade involves updating data, which is always a tricky task. On top of that, clients have the ability to configure and modify functionality associated with an application. A wrong step could overwrite data and damage functionality. To add to it, application upgrades must be done one version at a time. If you on 10.3.1 and are going to 10.5.1, then you will need to upgrade to 10.3.2. Then 10.4.0, 10.4.1, 10.4.2, 10.5.0 and finally 10.5.1. We strongly recommend that you plan for an Application upgrade at least once every two years to minimize the number of versions between platform and application. In addition, audited functionality may require Application upgrades. Customers who use the Lease functionality in TRIRIGA will know that government rules around leases are called FASB. Clients who need to be compliant with FASB rules will need to be on the latest Application release.
Fixpacks are important too! If a defect is found in a release, we will identify the defect as an APAR and develop a fix that can be applied to the installed software. It is recommended that customers set aside time and resources once a quarter to apply any fixpacks.
When a support engineer recommends that the user should upgrade to the latest version, the first thing that should be done is plan! Just because the platform may not take a lot of time to do, you should put in the proper planning. Here are somethings to ask yourself when planning your upgrade:
Fabio L Pinto 270003DRX7 Visits (9183)
(CK01) Third party considerations
IBM TRIRIGA support cannot help on 3rd party installation, configuration, setup and troubleshooting. Please, consult your 3rd party vendor support for help.
For other IBM products (IBM WebSphere & IHS - IBM HTTP Server), kindly route your questions & issues via PMR to the specific teams. Make sure you let this clear on the description that you want support for that specific product and properly classify that PMR.
(CK02) Sizing recommendations
IBM TRIRIGA support cannot help on specific sizing recommendations since this goes beyond support scope and it needs lots other relevant business information: business needs, business policies, business strategy, business resources, business growth plan, etc.
IBM TRIRIGA has the following Wiki page for some relevant sizing considerations when working with your sizing process:
If customers do need sizing recommendations, IBM TRIRIGA support needs to point customer to IBM Services (GBS) for addressing their request and needs. For these cases, please contact IBM & You (Sales) using the contact information available on this IBM page:
- Directory of worldwide contacts - http
(CK03) Preparing the environment - prerequisites
IBM TRIRIGA needs minimum environment requirements that may need to be reviewed in terms of adapting to business needs, growth and workload. Although a minimum required configuration and resources are required for running our product, this may not be enough depending and further sizing assessment needs to be engaged - See SU02 item above.
Kindly review the following IBM TRIRIGA documents for the hardware requirements:
- Overview of hardware configuration - http
Kindly review the following IBM TRIRIGA documents for the software requirements, meaning the compatibility requirements we need for 3.5.1 version:
(CK04) Upgrading the Platform (framework)
If you are upgrading from old Platform versions 2.5.x, 2.6.x, or 2.7.x, please refer to this document:
- Upgrade to TRIRIGA Platform 3.5.x (platform only) if upgrading from TRIRIGA Application Platform version 2.5.x, 2.6.x, or 2.7.x; and TRIRIGA application version 9.x - http
If you are upgrading from more recent versions (> 2.7.x), please refer to this document:
It is import keeping a good backup copy of your database before and after the upgrade process. There will be post upgrade tasks listed on the Upgrading guide, this includes checking up the installation and upgrade logs looking for errors and relevant warnings.
See that IBM TRIRIGA Platform upgrade or Fix Pack deployment has cumulative approach: this will comprehend all fixes and enhancements for the previous releases at time of this cut-off date. Check the respective Release Notes and/or the respective IBM TRIRIGA Fix Pack README files for more information:
For downloading the 3.5.1 required software, please review this link:
- IBM TRIRIGA 10.5.1 and IBM TRIRIGA Application Platform 3.5.1 Download Instructions - http
For downloading any available IBM TRIRIGA Fix Pack (FP) for your release, along with its respective README file (that will contain the FP install instructions), please review:
- How can I download a IBM TRIRIGA Platform Fix Pack? - http
About questions on IBM WebSphere regular product (ND & Single Alone) versus IBM WebSphere Liberty profile, see below:
i. Installation instructions for WebSphere Liberty Profile: "Installing TRIRIGA Application Platform on a WebSphere Application Server Liberty Core profile" - http
ii. Questions on how to choose: "Traditional WAS or Liberty: how to choose?" - http
iii. See that our IBM TRIRIGA is fully compatible with WebSphere Liberty, our Installer brings already its code and that will be only a check mark for installing WAS Liberty along with IBM TRIRIGA product. WAS Liberty brings High Availability (HA) possibilities (see SU07 item below), it is easier to implement and maintain and can support the most of the IBM TRIRIGA running, tuning and workload requirements scenarios, otherwise you do have a very specific business need in place (really rare scenario, see item ii above).
Keep IBM TRIRIGA support team aware of your upgrade and any relevant deployment (regarding IBM TRIRIGA solution, like other components and hardware changes). Send us a note (use any one of your IBM TRIRIGA support engineer who has previously worked with you) and provide us the following:
Q01) About any recent deployments (software / hardware) related to IBM TRIRIGA solution:
Q01-a) What is the from/to versions for the recent upgrade or deployment you've got?
Q02) About any planned deployments (software / hardware) related to IBM TRIRIGA solution:
Q02-a) What is the from/to versions going to be upgraded / deployed / changed?
With the set of information above, we will be able to know where you are, where have you been in terms of previous deployments, and where you intend to be in future, so that we can prepare ourselves to provide you support (for instance, on-call support during go-live process) when necessary. I'd suggest you to include questions & answers Inn, Q01 and Q02 in all PMRs you create from now on. This will speed up our support service cycle and provide you better assistance.
(CK05) Upgrading the IBM TRIRIGA Portfolio Data Manager (Application):
For IBM TRIRIGA Portfolio Data Manager (Application) upgrade, see this is NOT a cumulative process, meaning you do need to install each one of the available versions from your original one to the target one. More details about that, is available on the following IBM Support technote:
- What are the steps for upgrading IBM TRIRIGA Application (Portfolio) to recent versions? - http
Keep IBM TRIRIGA support team aware of your upgrade and any relevant deployment (regarding IBM TRIRIGA solution, like other components and hardware changes). Send us a note (use any one of your IBM TRIRIGA support engineer who has previously worked with you) and provide us the same set of questions & answers addressed above as Q01 and Q02 set on item SU04.
(CK06) Tuning your IBM TRIRIGA product - product requirements
It is a requirement customers tune their IBM TRIRIGA installs following the IBM TRIRIGA Best Practice for System Performance recommendations. Some of them are starting tuning set up and may be reviewed and changed due to some specific sizing concern or changes on system workload and/or topology.
There may be other required tuning, recommendations and assessments needed to be addressed for better performance and stability of your system.
All these recommendations and initial tuning information are addressed here:
(CK07) IBM TRIRIGA High Availability considerations
As part of your Capacity plan and Scalability assessments & process, you may need to change your topology for accommodating your business needs and required High Availability(HA). See the following IBM TRIRIGA support documents containing information about such subject:
- How can I have multiple IBM TRIRIGA application servers (user sessions) working on a Load Balancing and a High Availability implementation? - http
- How can I have multiple IBM TRIRIGA process servers (agents runs) working on a Load Balancing and a High Availability implementation? - http
You may want event to implement BROS (BIRT Report Only Server), meaning you want to have all your BIRT reports running on a separate server. See more information here:
- Advanced reporting in IBM TRIRIGA - http
See that even if you are using 3.5.1 product with WebSphere Liberty Profile, we do support High Availability for this implementation. See below:
- High Availability with Liberty - http
(CK08) IBM TRIRIGA SSO & Seamless Login information
IBM TRIRIGA product does support SSO and Seamless Login implementation, but the most of the required install and configuration is made on the 3rd party layer actually. See more information here:
- What is necessary to implement Single Sign-On (SSO) over IBM TRIRIGA product? - http
- Does IBM TRIRIGA support Seamless Sign On without challenging Internet Browser for credential information)? - http
- What are the methods of inserting the user name into an HTTP header supported by IBM TRIRIGA SSO-enabled environments? - http
- What are the available SSO properties for IBM TRIRIGA? - http
(CK09) IBM TRIRIGA TLS & SSL (HTTPS) support
IBM TRIRIGA supports TLS & SSL implementation, as properly documented here:
- Does IBM TRIRIGA support HTTPS, SSL and TLS? - http
But see this is not IBM TRIRIGA configuration and setup at all. This happens on the Application Server (WebSphere, WebLogic) and Web Server layer actually, not handled and controlled by our code at all. If you need support on that, contact your vendor support for such products.
Just as a sample of how we could be configuring TLS & SSL over WebSphere, please review the following (it is just a sample, as it is, your environment may have other requirements depending on the versions, topology and solutions you may have):
- Enable HTTPS in WebSphere for Maximo, SCCD, TSRM, and TRIRIGA - http
There you are, planning an application and platform upgrade for your IBM TRIRIGA installation and you think everything is working just fine. You roll out to production and for the first few days afterwards, all is quiet. Suddenly, out of the blue, you notice that the floor plan graphics no long render. Where the graphics should appear, you do not see the No Graphic Available message where the graphic used to appear. What you do notice is that, in the lower right hand corner "Error 2" is displayed and the rest of the space where the graphic would normally appear is blank. This blog post will address one of the potential causes of this problem and also a means of finding the problem before you upgrade your production environment.
In order to determine the root cause, we need to know what the errors are that are referenced in that "Error 2" text in the graphics section. Clicking on the text will open a pop-up box that contains the actual error messages (2, hence the "Error 2") related to the issue. That alone will not help the support team diagnose the problem. The errors should indicate an MID number. That MID number should also be found in the server log with a time stamp associated with when the graphic should have been rendered. In a issue I was working for a client, we determined from that information that there was a problem with the graphic layer configuration records. In particular, they were missing their corresponding IBS_SPEC entries. This required removing the records from the database using SQL run against the database back end. The application is unable to delete the records because the application relies heavily on the IBS_SPEC table entries to perform the actions necessary to delete the records. Once the records were removed and the layer configuration records rebuilt, the graphics once again started to display.
Great, that fixed the immediate problem, but how do you prevent this from happening in the future? When planning your upgrade, you need to insure that all graphical functionality is tested before making the decision to roll the upgrade out to your production environment. Upgrade plans should always include CAD Integrator testing. In older releases of the IBM CAD Integrator tool and the IBM TRIRIGA Platform, there was a great deal of backward compatibility. As a result of this backward compatibility, most clients did not include steps to insure that graphical elements were unaffected and, instead, focused on the business process logic to insure that the non-graphical data was correct. With the later releases of IBM TRIRIGA (3.3 or later, to be more precise) the CAD Integrator tool became much more tightly coupled with the platform release. Best practice for upgrade planning should now include upgrading the CAD Integrator tool to the release that was created specifically for the platform release to which you are upgrading. As a result of adding the CAD Integrator to your upgrade plans, you should naturally expect to add more time to the validation of all CAD related graphics that appear in your IBM TRIRIGA instance.
If you found this blog post useful, be sure to 'like' the post. If you have any comments about this blog, please provide that feedback in the comments section.