Feeding your TRIRIGA information needs

Tag Archives: Scripts

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.]

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.

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.]

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.]

We are running TRIRIGA 3.5.2.1 platform and TRIRIGA 10.5 application. We have a requirement from our customer, for Sarbanes-Oxley (SOX) compliance reasons, that we need to change the “System” user password in TRIRIGA. We have done this in the past. However, the old option now appears to have become read-only, so we can’t do it the same way. Any ideas how we can update this password now?

Here are some things that might be preventing you from updating the password:

1. The logged-in user does not have security access to update the password, or a workflow has triggered on the record that has modified the metadata, and made the password fields or its section non-editable.

2. The record is in a state that only supports read-only actions. This makes the record non-editable.

Therefore:

If you are logged in as Admin and cannot modify the password, I’d confirm that the System user is still part of the Admin group.

If you are trying to change the System password as another user that is not an Admin, I would put that user in the Admin group temporarily to see if this gets past your issue.

If you can confirm that a user in the Admin group cannot modify the record, I would look at workflows that are changing the metadata and the record state.

If you cannot access the account as the System user, you can temporarily clear the System password to blank (null), so that you can login as Admin and reset the password. For example, via an update SQL script:

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?