What is the Database Table Manager tool in IBM TRIRIGA?


As an administrator, you can view, alter, drop, and create database table indexes in the Database Table Manager tool. This tool is not found in the IBM TRIRIGA Administrator Console. With the proper permissions, you can find the Database Table Manager by signing into IBM TRIRIGA and navigating to Tools > System Setup > System > Database Table Manager.

The Database Table Manager supports the following actions on IBM TRIRIGA database tables: viewing table indexes, altering table indexes, dropping table indexes, and creating new table indexes. These actions can be performed on any IBM TRIRIGA table. For environments that use a Microsoft SQL Server database, the actions of viewing, creating, and removing Sparse columns are also supported.

Full access to this tool is limited to admin users who have full access to the IBM TRIRIGA Administrator Console. Admin users who have read-only access to the Administrator Console can view the indexes and Sparse columns only. All other users don’t have access.

Continue reading

Migrating database table indexes

You can view, alter, drop, and create database table indexes in the Database Table Manager tool. In addition, the Database Table Manager supports the migration of database table indexes from one IBM TRIRIGA environment to another.

The process of migrating database table indexes is done through the migration of record data on the triPlatformDBTableManager module.

Continue reading

[Admin: This post is related to the 02.10.17 post about finding the performance best practices, and the 01.15.15 post about custom tuning indexes for performance.]

IV90171: Changing users in WF Agent requires server restart


If we add or remove users from the Workflow Agent settings on process servers (as per “best practices” to only have one “open” process server and others “restricted”), we have to restart all process servers for the change to take effect.

The 3.5.0 Administrator Console user guide [PDF] does not suggest that a restart is necessary and since this is the new “best practice”, it should be dynamic rather than require a system outage every time you make this change…

Continue reading

How can custom queries slow or kill TRIRIGA performance?


Depending on how you create your queries, custom queries can have an impact on the performance of your system. In your custom query, when you create an Association Filter, you want to avoid using –Any– for the module selection and avoid All for the business object selection. The reason to avoid those particular selections is that they can cause potential report performance issues. This is mentioned in the IBM TRIRIGA 3.4.2 Reporting User Guide. It is better to specify a specific association type in your Association Filter than to use –Any–.

If you have any fields that have a special character in them, like < > , & * or -, that can also impact your performance. While field names should not have < > , & * or – in them, it could happen somehow. If any of your fields manage to have special characters in them, then this is going to cause an issue, because the reports will not be built. So it is a good idea to avoid special characters. If you do have special characters in any of your field names, it is best not to have it referenced in a query. But, ideally, you will want to create field names that do not use a special character.

It is important to note that if you have modified your custom queries, you need to clear the Query Cache in the TRIRIGA Admin Console for the change to take effect.

Continue reading

Why doesn’t the organization hierarchy tree get displayed?


So I wanted to reload our Department and Division data in our Dev environment. All the records were in Draft state. I opened the Department form and selected all my records and clicked on the Delete button. Then I did the same with the Division form and clicked the Delete button, which just state-transitioned those records to a null state. Then I went to the Organization Hierarchy quick link from my portal. Now the tree doesn’t display and I get the following error:

“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.”

I thought it could be the cache. So I went into the Admin Console > Cache Manager, and refreshed the “Hierarchy Tree Data” and “Hierarchy Tree Data – with rebuild”. I checked the “Hierarchy Tree Cache Status”. The Organization hierarchy has not completed yet and the duration has been over 20 minutes. I only have less than 500 Department records and 20 Division records. So I am concerned that the rebuild shouldn’t take that long. How do I query or get the Organization hierarchy tree data back in order? Any suggestions?

So it looks like the only way to remedy this error is by retiring the records, and then deleting the records (which sets the TRIRECORDSTATESY to null), and then letting the Cleanup Agent run. After I did that, the Organization hierarchy was displaying correctly.

[Admin: This post is related to the 04.07.16 post about a corrupted cost code hierarchy, and the 06.18.15 post about the hierarchy tree cache taking a very long time to rebuild.]

Continue reading

What are the recommended maximum threads in IBM TRIRIGA?


What are the recommended values for maximum threads in the IBM TRIRIGA Admin Console > Thread Manager page? I need to set up maximum threads for better performance without causing problems to my system.

To control the number of threads that are started for each agent, use the Threads Manager menu in the IBM TRIRIGA Administrator Console. A single thread requires one connection to the database. A large value for the total of maximum threads can slow performance. As a guideline, a typical limit is no more than 2 to 3 times the core count of the database server. One must also add the number of servers and agents connected to the database.

If there are multiple Workflow Agents running against the same database, the sum total threads across all servers should not be more than 2 to 3 times the total core count of the database. As a reminder, the only scenario recommended for having multiple Workflow Agent instances running is when you have a User List associated to them. See more information in this wiki page: When to use Multiple Workflow Agents. For example, if the database has two Dual Core Xeon CPUs, the core CPU count is four (4 CPUs). So, you should have up to 12 threads connecting to the database (3 x 4 CPUs).

However, you have only a process server with a single Workflow Agent instance running as part of your topology. As such, you may share the 12 threads in this way when setting the Maximum Threads in the IBM TRIRIGA Admin Console > Threads Manager:

  • CAD Integrator: 2
  • Data Import Agent: 2
  • Scheduler Agent: 2
  • Workflow Agent: 4
  • Report Queue Agent: 2

[Admin: This post is related to the 05.06.15 post about when to use multiple workflow agents.]

Continue reading