ValuD: What are the best practices for TRIRIGA application upgrade?

Part 1: Introduction

With 150+ IBM TRIRIGA completed projects across the globe, ValuD has the largest and most experienced team focused exclusively on IBM TRIRIGA. ValuD offers a variety of delivery models to meet our clients’ needs to ensure customer success whether for a new implementation or an upgrade. In the first of a four-part series, we share our best practices for TRIRIGA application upgrades…

Part 2: Lease Accounting

In our earlier post, we shared best practices followed by ValuD during IBM TRIRIGA upgrades. In this post, we highlight the best practices for IBM TRIRIGA 10.5.3 upgrades especially related to FASB/IASB lease accounting standards…

Part 3: Modifications & Metadata

Our earlier posts focused on IBM TRIRIGA application upgrade steps adopted by ValuD. In this post, we share best practices following the actual upgrade process…

Part 4: Record Data

In our last and final post on this series, we talk about record data tips and IBM TRIRIGA application upgrade delivery best practices that ValuD recommends…

[Admin: This post is related to the 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 Object Label tag.]

Advertisements

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

UX: How do you get access to the new UX apps (Service Request)?

How do I get access to the new UX apps listed on this page? We are on TRIRIGA 3.5.3 and 10.5.0. But we only see the Space Assessment and Space Management Perceptive apps in our environment.

The Move Me and Group Move applications were added in the Application 10.5.2. The Workplace Services portal, Service Request, and Room Reservation were added in the Application 10.5.3. The apps are delivered in the Application Upgrade. When you upgrade from Application 10.5.0 to 10.5.3, you will see the new apps.

[Admin: To see other related posts, use the UX Framework tag or Perceptive tag.]

UX: Why does Group Move UX app stop working after 10.5.3 upgrade?

I’m seeing an issue in the Group Move UX app. After application upgrade to 10.5.3, the Group Move application stopped working on “Production Mode”. After activating “Development Mode”, the Group Move worked again. So I think the problem came from the vulcanized code of 10.5.3 OM package. For now, I’ve just vulcanized the Group Move application manually and it works now. Have you seen a similar issue?

We confirmed the defect related to the vulcanized code for the Group Move UX app. It is being addressed for the next full release under APAR IJ01969. Meanwhile, the manual solution you have followed is the workaround. Here are the details:

“The Group Move UX Perceptive application should no longer contain syntax errors and the search feature should work now. Customers who run into this issue on previous app versions can vulcanize the application following the steps outlined on this wiki page. (Tri-IJ01969-5886)”

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

Why does IBM TRIRIGA 3.5.3 install give errors on WebSphere 8.5.5.11?

I am attempting a clean install of TRIRIGA 3.5.3 and according to the logs, it appears that the installation was successful within the was-ant.log. But I receive this error in the ant.log… When I access the application, I was unable to pull up the login page. Checking the server logs, I noticed these errors… The odd thing is that when I did a TRIRIGA 3.5.3 install on WebSphere Liberty, it worked perfectly…

The errors seem to indicate that you selected an upgrade, not a new install. Are you sure you selected a new install? Some of the environment properties that are needed to start up do not seem to be available. Did the database get created or are you pointing at an existing database? What happens if you do a select * from environment_properties on the database you are using?

The DB2 exception you are receiving seems to indicate you are running out of statement handles, but it’s hard to see this happen with a successful install.

[Admin: To see other related posts, use the WebSphere tag or “install error” search phrase.]

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

What is the optimal cursor size for large OM package imports?

We are seeing an Oracle error during OM package import related to the number of open cursors. We checked the documentation, but there is no recommendation of what the cursor size should be for large OM package imports. We are currently on 500. Has anyone seen this issue or performed a successful upgrade in this regard? What is the optimal cursor size being used by different clients?

I checked with one of the senior TRIRIGA architects, and he said he would recommend setting open_cursors to at least 2000 for an OM package import. I hope this information helps!

[Admin: To see other related posts, use the Object Migration tag or Upgrade tag.]