IV96326: Title is shown even if the REPORT_HEADER_COLUMN is “Name”


When a report is executed from “My Reports”, the title is shown as the header, even though we have changed the REPORT_HEADER_COLUMN property to “Name” in the TRIRIGAWEB.properties.

We needed to remove the REPORT_HEADER_COLUMN property since it is no longer being used. It was used in the out-of-support TRIRIGA 2.7.x platforms and older. Moving forward, the deprecated REPORT_HEADER_COLUMN property has been removed from the TRIRIGAWEB.properties file since it has not been used since the TRIRIGA 2.7.x platform releases.

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

Continue reading

How do you limit the upload file size to IBM TRIRIGA?


This is a common question from many TRIRIGA administrators. We have parameters to limit the file extensions for a while now, but limiting the file size was a missing capability, until…

In TRIRIGA 3.5.2, we introduced a new property in the TRIRIGAWEB.properties file called MAXIMUM_UPLOAD_FILE_SIZE_BYTES that allows administrators to configure the maximum permissible size for file uploads. If no value is set, the default is 20 megabytes. We hope you make good use of this feature after you upgrade to 3.5.2 or higher versions of the platform. I’m sure your storage specialist will owe you one!

Continue reading

How do you set the TRIRIGA session expiration warning in the portal?


The IBM TRIRIGA Application Platform has the ability to notify users on their portal if their session is about to expire. The message will not be displayed on any popups or modal windows, only on the main portal page.

To allow the alert message to be displayed on the portal to a user whose session is about to expire, set SESSION_WARNING_ENABLED=Y in TRIRIGAWEB.properties. By default, it is N. The default alert timeout threshold is 2 minutes before the session is set to expire, as follows: SESSION_WARNING_THRESHOLD=2.

The session expiration timeout itself can be found in the following locations:

  • WebSphere Liberty:
    • Edit wlp/usr/servers/tririgaServer/server.xml.
    • Update the invalidationTimeout value in seconds.
  • WebSphere:
    • In the Websphere Console, navigate to Servers > Application Servers > Your Server > Web Container > Session Management and/or Applications > Enterprise Applications > Your Application > Session Management.
  • Oracle WebLogic:
    • In the WebLogic Console, navigate to Your Domain > Deployments.
    • Expand the tririga-ibs deployment node. Expand the Modules node.
    • Click on the context root node. (The context root was selected during TRIRIGA install. The default name is “/”.)
    • Select the Configurations tab.
    • Enter a value for Session Timeout (in seconds), and Save.
    • You may be asked to select a location for Plan.xml, which will be generated upon saving.
    • You may need to restart the WebLogic Server.

Continue reading

How do you avoid the tree error after deleting hierarchy records?


I’m loading data via the Data Integrator into a Classifications business object. In the first load, my data is successfully loaded. However, I notice some data mapping issues. So I delete the records from a query, then I clear cache. In the second load, my data is successfully loaded. I go into the Classifications hierarchy form and get the dreaded message:

“Please contact your system administrator. The tree control reported this error while trying to draw itself: There was an error in the database or the query definition.”

When this happens, I tell myself that I deleted the records too quickly and didn’t allow the system to reset in time. The solution is the dreaded wait time for the Cleanup Agent to process records that takes 12 hours, 1 day, 3 days, or sometimes 1 week, before all records with a TRIRECORDSTATESY is null, are removed from the database. The only workaround seems to be to increase the Cleanup Agent time. However, is there a sequence of steps I need to follow before I delete records from a hierarchy form, so that I don’t get the dreaded message each time?

Regarding your scenario of loading hierarchy records, deleting them, then reloading the same records to cause the tree control to fail, that should be considered a platform defect. I would advise you to enter a PMR, so Support can look into this issue. The tree control should never fail to render as you describe it.

To help with your issue, there is an unsupported platform feature that allows the Cleanup Agent to delete data immediately. If you add the following property to your TRIRIGAWEB.properties file and set CLEANUP_AGENT_RECORD_DATA_AGE=2, the Cleanup Agent when run will delete records that are 2 minutes old. This allows you to immediately delete a bad data load, and allows you to run it cleanly again a second time without conflicts from that data already existing in a null state.

[Admin: This post is related to the 08.11.16 post about the Organization hierarchy tree not being displayed, the 08.04.16 post about unretiring and returning records to null, and the 02.24.16 post about executing the Cleanup Agent (a.k.a. Platform Maintenance Scheduler) after retiring a record.]

Continue reading

Is there a way to track the report runtime history in TRIRIGA?


Is it possible to determine query and report usage by username, date, and time? Can that history be retained in the application for a user-configurable period of time? If I want to track usage of any or all reports within TRIRIGA, is there a method to do so?

Yes. With the TRIRIGA 3.5.2 release, a “Track History” check box has been added to all reports that allows for a case-by-case tracking model to be used for report usage. Selecting that option will cause tracking in the “History” tab to take place. Clearing the option will cause the tracking to stop, but existing log data will be retained for a configurable period (days). This variable is found in the TRIRIGAWEB.properties file:

REP_HISTORY_AGE_CLEANUP 365

[Admin: This post is related to the 10.31.16 post about using the report run history to track performance.]

Continue reading