IBM TRIRIGA Support works on addressing problems through a problem ticketing system where each issue is logged as an IBM Service Request (SR) or Problem Management Report (PMR). We manage problems reported via this process.
IBM TRIRIGA Support provides a support landing page titled “IBM TRIRIGA Information and Support Resources” which has a lot of very helpful information. This page has a Support Resources Home section that provides numerous links to some great resources, including a link to our IBM Service Request system, where you can open a Service Request (SR). On the “IBM TRIRIGA Information and Support Resources” page, there are also IBM Support phone numbers.
Once an SR/PMR is opened, it can be tracked for updates via the SR tool. You may also request an update at any time and this will notify the Support team to follow up with you as soon as possible.
For the most efficient IBM TRIRIGA support experience…
- There should only be one problem per SR/PMR per customer environment. This helps to keep the focus on a particular issue…
- SRs/PMRs also have the concept of “severity”. This is a ranking that is set by the customer to indicate the urgency and importance…
- When opening your SR/PMR, try to be as complete as possible and provide as much of the critical information as possible…
[Admin: This post is related to the 07.14.15 post about collecting data to resolve PMRs, the 07.07.15 post about resolving PMRs as soon as possible, and the 04.26.17 about outlining the process for SRs, PMRs, and APARs.]
I want to understand how people are running their QA organization to support TRIRIGA implementations. What kind of automation is being used? What challenges are being faced? I’m trying to start up a discussion around QA testing for TRIRIGA.
[Admin: To see other related posts, use the QA tag or Testing tag.]
We imported an Oracle 12c database dump from a TRIRIGA platform running TRIRIGA 188.8.131.52 into another Oracle 12c server. The Oracle Data Pump Import (impdp) completed without error. The plan was to install and upgrade the TRIRIGA platform to 3.5.2. This is something we’ve done multiple times with different releases. So platform upgrades are usually painless.
We went right through the upgrade process dialogs, a successful database server conductivity test, but here’s something we’ve never experienced before. Instead of installing and upgrading the database to the new platform, “Installed by InstallAnywhere 17.0 Premier Build 5158” throws up the following dialog box.
“Upgrade Not Supported. An upgrade from the version of your platform is no longer supported. Please upgrade to 184.108.40.206 first, before upgrading to this platform version. Back or Exit.”
Does anyone have any ideas why we are getting this message?
We found the issue. The schema name was “TR1DATA”, not “TRIDATA”. The terminal font was not showing a clear distinction between “1” and “I”. We’d better take a much closer look next time. Thanks for the assistance from everyone.
IBM TRIRIGA Support does all that it can to assist our clients. However, there are processes in place to help all of our clients get a consistent level of help…
A Service Request (SR) or Problem Management Report (PMR) is created to request assistance from IBM TRIRIGA Support to help with investigating a problem or to request an answer to a question regarding TRIRIGA. Due to the complexities of the environments supported and the potential scope of work involved with enterprise software, it may take some time to complete an investigation and can result in a number of outcomes, such as the following SR/PMR resolutions:
- Resolved as a question answered.
- Resolved as a product working as designed (even when a client may disagree with the design).
- Resolved as a request outside the scope of support.
- Resolved as a defect (which will result in the creation of an Authorized Program Analysis Report, or APAR).
With each of these outcomes, IBM TRIRIGA Support has completed its investigation and the SR/PMR has been resolved. What happens next?
[Admin: This post is related to the 07.14.15 post about collecting data to resolve PMRs, and the 07.07.15 post about resolving PMRs as soon as possible. The same article is also posted in the Watson IoT Support blog.]
Component API documentation for developing applications with UX Framework is deployed with your TRIRIGA server. Component documentation can be accessed via the following endpoint:
- The [tririga-hostname:port] and [/context_path] are the specific values you’d normally use to access your IBM TRIRIGA environment.
Once at the component documentation page, you can browse or search the TRIRIGA delivered components that are available on your specific platform version using the left-hand panel. Further down in the list, you can find documentation for the available third-party components delivered with the corresponding version of Google Polymer. (This version varies, based on the TRIRIGA platform version. See the Support Matrix for more information.)
In the right hand panel, the documentation provides information about the selected component, generally with sample usage, styling and an API reference. In some cases, there are also demos available. You can toggle between the Doc and the Demo for a component using the buttons in the top right of the page…
[Admin: Similar content is also found in UX Article 2: Implementing UX. This post is related to the 12.11.15 post about the UX framework.]
As we approach the end of the first quarter, we thought we’d send a reminder about some of our IBM Watson IoT product versions and supported platforms that are currently scheduled for End of Support (EOS) in April 2017:
- 30 April 2017: 5725-F25, IBM TRIRIGA Portfolio Data Manager, 10.2.x
[Admin: This post is related to the 08.26.16 post about End of Support (EOS) plans for TRIRIGA versions.]