Can you run all patch helpers (10.3 to 10.5.2) after final OM import?


We have upgraded the TRIRIGA platform to 3.5.2.3 and started upgrading the application from 10.2 to 10.5.2 in incremental order (10.3, 10.3.1, until 10.5.2). To minimize the outage and complexity during production implementation, we have been suggested to take a final OM package after completing 10.5.2 deployment, and apply all the customizations which might have been impacted with the upgrade. This final OM package will contain all the changes from 10.2 to 10.5.2.

Our question is on the patch helpers: Can we run all the patch helpers (from 10.3 to 10.5.2 in order) after importing the final OM package?

Also, we are running the Varchar-to-Numeric script before importing the application upgrade packages. This script is taking a long time (almost a day in two test environments), but when we tried in another environment, it’s running for more than 2 days and still didn’t get executed. Is it normal for this script to run like that? Or will it be an issue? There are no differences between the environments.

I wouldn’t recommend doing the upgrade in one package. Usually, it ends up being quite large and it will cause issues. The IBM-recommended way is to perform each OM, then run the patch helpers. Once you have upgraded the OOB OM packages, you can have one OM which has your custom objects…

[Admin: This post is related to the 10.25.17 post and 04.28.17 post about running “SetVarcharColsToNumeric” scripts. To see other related posts, use the Scripts tag.]

Continue reading

Can you run the IBM TRIRIGA script after applying the 3.5.x fix pack?


Can I still run the TRIRIGA “SetVarCharColsToNumeric” script after I have applied the 3.5.x fix pack?

Yes. You can apply the script regardless of the TRIRIGA platform version. But it MUST be applied BEFORE upgrading the application.

[Admin: This post is related to the 04.28.17 post about running the MS SQL “SetVarcharColsToNumeric” scripts. To see other related posts, use the Scripts tag.]

Continue reading

Is there any tool which imports currency conversion rates?


We are looking for an integration solution which allows you to import currency conversion rates. It seems that this data is not based on a BO, so I think traditional integration tools such as DataConnect (DC), Data Integrator (DI), and Integration Object won’t work. Have you seen this kind of requirement? Are there any solutions other than using SQL script? I’ve tried the SQL below, and it seems to be working.

INSERT INTO BUDGET_CURRENCY_CONVERSION (CONVERSION_GROUP, FROM_CURRENCY_CODE, TO_CURRENCY_CODE, CONVERSION_RATE, START_DATE, END_DATE, INSTANCE_ID) VALUES (‘LIBA’, ‘Chinese Yuan’, ‘Euro’, 0.13, {ts ‘2017-01-01 01:00:00’}, {ts ‘2017-12-31 01:00:00’}, BUDGET_CURRENCY_ID_SEQ.nextval)

BusinessConnect (a.k.a. Connector for Business Applications or CBA) is the best method to use for this. Here’s the PDF. The putCurrencyConversionRates method is what you would want to use.

[Admin: To see other related posts, use the Currency tag.]

Continue reading

How do you delete records that exist in T_ table not IBS_SPEC table?


We have some corrupted records, which appeared across 2 different BOs so far. We can’t delete them from the application level, and the cleanup script won’t delete them either, because they can’t be found under the IBS_SPEC table. Does anyone have a SQL to properly cleanup those records from the T_ table?

[Admin: This post is related to the 02.10.15 post about purging records from a BO. To see other related posts, use the Cleanup tag or SQL tag.]

Continue reading

Changing functionality in TRIRIGA to fix security vulnerabilities


In this day and age, security is a very hot topic. As soon as one vulnerability is addressed and mitigated, another one is found. It is a vicious circle of identifying and addressing vulnerabilities that does not seem to let up. In our fix pack release notes, information regarding the mitigation of vulnerabilities that were addressed without an APAR is listed. And sometimes, a vulnerability is addressed as an APAR.

The reason I am mentioning security vulnerabilities is that sometimes, when they are resolved, there is an impact on existing functionality, which may not always be clear. Sometimes, the result of fixing vulnerabilities can “change” functionality. As an example, in the TRIRIGA 3.5.2 release, external URL navigation items will now open in a new window to avoid cross-origin scripting vulnerabilities…

As the product develops and security vulnerabilities are found and addressed, it could mean a change in how something works. Reading the release notes can be a source of information, but it may not always be clear why something changed. We all know change is hard, especially when we are so used to it working in a certain way. I don’t know about you, but if the change was made to address a security vulnerability, I can live with that and accept the change.

[Admin: This post is related to the 04.07.17 post about APAR IV94912 where “External URL” navigation items may no longer work. To see other related posts, use the Security tag or Vulnerability tag.]

Continue reading

Is there a way for the “Component ID” to stay permanent in TRIRIGA?


In TRIRIGA, the Component ID for a field changed after upgrading. For example, in TRIRIGA 3.5/10.5, the Component ID for the “User ID” text box on the login page was: textbox(“User Name”). But in 3.5.2/10.5.2, it changed to: textbox(“User ID”). This is impacting our automation test. Each time we upgrade to a new version, we need to check and change our automation test script. Is it possible to keep these Component ID values fixed?

[Admin: To see other related posts, use the QA tag or Testing tag.]

Continue reading