Improvements in IBM TRIRIGA Performance
By Rick Rhea & Jay Manaloto
What has the IBM TRIRIGA performance team been up to? Over the last few years and last few releases, our performance team has focused on areas that aren’t normally covered by our standard benchmark tests, and on tools that can help customers to resolve performance issues on their own. If you’re interested, here are a few of our recent improvements in lease and platform performance.
- Lease Benchmark Testing: Not only are database server and process server resources especially important, but using multiple process servers improves performance.
- New Recommended Indexes: Several additional indexes were identified and added to the best practices to obtain the best response times and resource utilization of the database server.
- Lease Journal Entries: By redesigning journal entry processing with parallel and batch processing, and multiple process servers, our test results took only about 2.5 hours instead of over 90 hours.
- Platform Enhancements: Dynamic workflows can now pass and return parameters, the Query task can now return the number of records instead of the actual records, and the Trigger Action task can now run the asynchronous event that occurs after the transition by a user other than the currently logged-in user.
- BIRT Reporting & Lease Disclosure Reports: In Version 3.6.1, the reporting was modified to improve running on a separate BIRT server, and to avoid the problematic “params.displayText”.
- Performance Analyzer Tool: In Version 3.5.3, this tool was introduced to allow a customer to run specific logging types without using the Admin Console, and to view easy-to-read reports.
- Module Level Associations, Early Adopter Feature: In Version 3.7.0, the platform was enhanced to support Module Level Associations (MLA) tables where the records in the IBS_SPEC_ASSIGNMENTS table are distributed into smaller tables that are created by module type.
By applying the above finding and tools, our recent IBM TRIRIGA 10.7.0 / 3.7.0 release has demonstrated a significant improvement in performance over previous releases. But we’re not done yet! Our performance team will continue to dig deeper into weaker areas or potential opportunities to make our products stronger or faster. So stay tuned for any upcoming developments!
Note: For future releases, “Module Level Assignments” will be renamed “Module Level Associations”.
[Admin: This post is related to the 07.27.17 post about the Performance Analyzer. To see other related posts, use the Performance tag.]
Part 1: Leasing Software
Earlier posts focused on the best practices followed by ValuD during IBM TRIRIGA application upgrades. In this blog series, we highlight the best practices that ValuD advocates for an IBM TRIRIGA 10.5.3 leasing software implementation…
Part 2: Data Readiness
Our earlier blog focused on the key learning from ValuD’s 10.5.3 implementations. In the next couple of blogs, we list our recommendations for each stage of the implementation life cycle. In this post, we focus on data readiness, data migration, and the design phases…
Part 3: Journal Entries Setup
Continuing with our recommendations for each stage of the implementation life cycle, today we focus on the build process and general ledger (journal entry) integration steps…
Part 4: Testing & Training
In our final blog of this series, we list our recommendations for the last two phases of the implementation life cycle: TRIRIGA testing and training…
[Admin: This post is related to the 01.10.18 post, 08.07.17 post, and 09.24.15 post about the best practices for configuring and upgrading TRIRIGA applications. To see other related posts, use the Best Practices tag or Implementation tag.]
We have upgraded the TRIRIGA platform to 220.127.116.11 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.]
Is anyone using automated testing tools with TRIRIGA 10.5.3? I’m trying to use C# and Selenium to run automated test cases and I’m running into problems locating elements that I can control. Specifically, I’m having difficulty grabbing elements inside of tables for leases where there are no IDs. I’ve tried using XPath, but I keep getting “Element not found” errors.
[Admin: This post is related to the 05.31.17 post about running your QA organization. To see other related posts, use the QA tag or Testing tag.]
Testers found that they had the ability to add reports to the My Reports page in TRIRGA, even though the links for New, Copy, Delete, Copy as Community Report, and Share Report were not present for the read-only users.
Moving forward, an privilege escalation issue in Report Manager has been resolved.
[Admin: To see other related posts, use the Vulnerability tag or CVE tag.]
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.]
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.]
Is it possible to (OM) migrate integration object records? I’ve created two integration objects in my Dev environment. But I’m not sure which BO to use to (OM) migrate my two records to my Test environment.
[Admin: To see other related posts, use the Integration Object tag.]
I found this technote on the minimum required database permissions for TRIRIGA:
Following are the minimum permissions.
Anything else is untested and unsupported.
ALTER USER $dbuser$ QUOTA UNLIMITED ON $data_tblspace$;
ALTER USER $dbuser$ QUOTA UNLIMITED ON $index_tblspace$;
GRANT ANALYZE ANY TO $dbuser$;
GRANT CREATE VIEW TO $dbuser$;
GRANT CREATE TABLE TO $dbuser$;
GRANT ALTER SESSION TO $dbuser$;
GRANT CREATE SESSION TO $dbuser$;
GRANT CREATE SYNONYM TO $dbuser$;
GRANT CREATE TRIGGER TO $dbuser$;
GRANT CREATE SEQUENCE TO $dbuser$;
GRANT CREATE PROCEDURE TO $dbuser$;
GRANT DROP PUBLIC SYNONYM TO $dbuser$;
GRANT CREATE PUBLIC SYNONYM TO $dbuser$;
GRANT CONNECT TO $dbuser$;
ALTER USER $dbuser$ DEFAULT ROLE CONNECT;
But the following permissions are restricted for our customer:
DROP PUBLIC SYNONYM
CREATE PUBLIC SYNONYM
Can you tell me if these permissions are only needed for installation? Or are they also required for runtime?
The IBM TRIRIGA product team does not test nor validate lower permissions than what is documented. All permissions granted to the user are required for the support of TRIRIGA, and removing permissions can lead to unexpected behavior, performance problems, and possibly data corruption.