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.]
We recently upgraded to TRIRIGA Platform 3.5.3 and we are still in Application 10.3. We have a custom cstWorkTask form and it has 133 form actions. In the “Shop Foreman” security group, we want to give access to over 125 form actions.
But it looks like there is a limit where you can only set 119 form actions. Because as soon as you select the 120th form action, the spinning wheel appears and never completes. We have tried clicking the “Select All” check box, but as soon as you click that, the spinning wheel appears and never completes. If we remove a couple of actions from the 119 already selected, then it lets you check two more without the spinning wheel. Is there any setting that controls how many form actions can be set in the security group? Or is this a known issue?
[Admin: To see other related posts, use the Security Manager tag.]
Our customer has seen an issue when installing TRIRIGA 3.5.3 (Linux, Server build number: 276955) on an existing database (on 3.4.2 / 10.4.2). Everything goes well until starting up the server. Generally, TRIRIGA will run a database upgrade on the first startup when a build number difference is detected.
In the OM log, we notice that TRIRIGA tried to import the upgrade OM package… The import process started with the triPlatformObjectLabelManager package, but it failed to import a navigation item, which is newly created for Object Label Manager. I haven’t found any log which can explain this failure. I’ve checked the NAV_ITEM table. This navigation item wasn’t there before the upgrade process. Then all of the other packages are stuck on a pending status. Nothing happens after “Creating package from Zip file”. This behavior causes a lot of SQL update failures.
Meanwhile, on our Dev environment (Windows, Server build number: 279835), the upgrade went very well. You can find the difference in the logs. The OM log was set on “Debug” level on both servers. Note that the build number is slightly different between these two enviroments. Have you seen this kind of issue? Where can I find more details about the navigation item import failure?
[Admin: This post is related to the 02.17.17 post and 05.19.16 post about inconsistent OM validation results. To see other related posts, use the Object Migration tag or Upgrade tag.]
We have upgraded the TRIRIGA platform to 22.214.171.124 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.]
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.]
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.]
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 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.]
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.]
We have already upgraded our platform to 126.96.36.199. We are currently in the process of upgrading our application from 10.3.2 to 10.5.2.
For the application upgrade, we have set up a staging environment with an initial install of 10.5.2 and we have configured all BOs, forms, and other objects to meet our current customization. My question is: What if we import the IBM upgrade OM packages (sequential from 10.4 to 10.5.2) to our current environment (which has all customization)? It would definitely overwrite all the customization and configuration, but does it affect the record data as well (e.g. lease records)?
When it overwrites the customization at the BO and form level, would it corrupt the record data since some of the custom fields on the records won’t exist at the BO level any more? And what happens after we import all our customization back in the current environment from the staging environment?
The short answer is: You wouldn’t apply the IBM upgrade OM packages. Instead, you’d build OMs in your now customized 10.5.2 environment and then apply them to your current environment.
[Admin: To see other related posts, use the Object Migration tag or Upgrade tag.]