How do you clean up the SESSION_HISTORY table?

The SESSION_HISTORY table uses 500GB of disk space in our production environment. What is the best way to clean it up?

You would want to make appropriate backups and test this thoroughly, but this is something that can be done via the Platform Maintenance Scheduler (formerly Cleanup Agent) in the IBM TRIRIGA Admin Console. You can develop SQL to do the cleanups as they meet your business requirements, add that as a new cleanup command at the bottom section of the window, and then add a new Cleanup Schedule event in the top section of the window to have it run periodically.

This may be something that you want to reach out to a business partner for assistance with, depending on your skill and comfort level in implementing such a change. If so, you can search the IBM PartnerWorld portal.

[Admin: To see other related posts, use the Sessions tag or History tag.]

What happened to the performance monitors in the Admin Console?

In the IBM TRIRIGA Administrator Console, under Performance Monitor > Monitor a Single Value, several monitors are no longer listed.

The following changes were made in the Administrator Console, under Performance Monitor > Monitor a Single Value:

• CRYSTAL_QUEUE_AGENT_RUNNING is renamed to REPORT_QUEUE_AGENT.
• CLEANUP_AGENT_RUNNING is renamed to PLATFORM_MAINTENANCE_SCHEDULER.
• KEYWORD_PARSER_AGENT_RUNNING and WAREHOUSE_AGENT_RUNNING were deprecated in a previous release and are now removed from the Performance Monitor.

Since the CRYSTAL_QUEUE_AGENT_RUNNING and CLEANUP_AGENT_RUNNING monitors are used for integration, only the performance monitor names are changed, not the values or URLs.

[Admin: This post is related to the 07.14.15 post about renaming CleanupAgent (Cleanup Agent) to PlatformMaintenanceScheduler (Platform Maintenance Scheduler). To see other related posts, use the Monitoring tag.]

How do you change CI Organization Mapping from Org Name to Org ID?

We have multiple organizations with the same name. We would like to change the CAD Integrator > Batch Associate > Organization Mapping to display the Organization ID instead of the Organization Name. How can I change the list from showing Organization Name to show Organization ID?

You will need to change both the Organization Mapping and the query to call only the Organization ID. After that, clear all caches in Admin Console and do a Full Sync in the CAD drawing. Following these steps, we changed the Organization Mapping from showing Name to showing ID and changing it back. It does not appear to have any negative impact, but there has been no detailed regression testing…

[Admin: To see other related posts, use the CAD tag or Integrator tag.]

Why aren’t servers in the “Active Servers” table in Admin Console?

We are seeing servers dropping out of the “Active Servers” table in the Admin Console > Agent Manager page. We are running multiple environments, each with platform version 3.5.2.2 with two UI and two process servers, and have experienced this across multiple environments. Current observations:

• Both UI and process servers can drop out, and it’s not the same server every time.
• Servers can be accessed and logged into, even if they are gone from the “Active Servers” table.
• A restart of the server will make the servers appear again.

Our current approach is to monitor daily and when a server drops, take a look in the logs for that day. Any other ideas? What controls when servers are listed or not in the “Active Servers” table in the Admin Console > Agent Manager page?

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

Is there a way to clear server caches without Admin Console?

Is there a way to clear server caches without logging into the Admin Console?

Beginning in IBM TRIRIGA Platform 3.5.1, TRIRIGA delivered an enhancement for this to be done via workflow. The pertinent release notes can be found from this wiki page. Here is an excerpt from the release notes on the topic:

A custom task class has been added for workflow which triggers a global cache clear across all servers. 

You can create a custom task and specify the following in the class field: com.tririga.platform.admin.cache.web.CacheProcessingCustomTask $RefreshAllCache

The custom task will perform a global cache clear on the server where the workflow runs as if it were triggered from that server’s Administrator Console. (Tri-211723)

[Admin: To see other related posts, use the Admin Console tag or Cache tag.]

How do you configure TRIRIGA for Tivoli Directory Integrator (TDI)?

You can configure TRIRIGA to use Tivoli Directory Integrator as its ETL runtime engine to run ETLJobItems from within TRIRIGA.

Before you begin

Install Tivoli Directory Integrator, if not already installed, on all the TRIRIGA systems that could run a TDI ETL Job Item.  During the TDI install:

• Make note of the installation directory you enter on the Destination panel. You will enter this value later in TRIRIGAWEB.properties.
• Select either installation type. TRIRIGA requires only the TDI Server component.
• When prompted for the location of the Solution Directory, you can select any option. TRIRIGA specifies its own solution directory at runtime.  However selecting the option “Use Install Directory” may simplify troubleshooting.
• Make note of the value you enter in the Server Port field on the Server Port Values Panel. You will enter this value later in TRIRIGAWEB.properties.
• Clear the “Start the Configuration Editor” check box on the Install Complete panel.
• Note: This step is very important for TDI/TRIRIGA integration to work. After you have installed Tivoli Directory Integrator, update it with the recommended fix packs (per TRIRIGA support matrix). TDI must be at least at FP04 (7.1.1.4) or it  will not automatically start the TririgiaETLDispatch.xml assembly line which will result in ETL job items failing to run successfully.

Procedure

1. Edit TRIRIGAWEB.properties file to enable TRIRIGA to manage TDI server.  Set the following properties…
2. Install a JDBC driver library so that Tivoli Directory Integrator can use it to access TRIRIGA database…
3. Edit TDI global.properties file to allow TRIRIGA to check and stop the TDI server from localhost without requiring authentication and authorization certificates. Set the api.remote.ssl.on property to false to tell TDI to trust requests from localhost…
4. Start Tivoli Directory Integrator Agent from TRIRIGA Admin Console and verify that it starts successfully…

[Admin: This post is related to the 08.03.16 post about installing, upgrading, or uninstalling TRIRIGA TDI, and the 05.01.16 post about documentation on developing TDI with TRIRIGA. To see other related posts, use the TDI tag.]

Do you need to clear server cache if floor plans aren’t visible?

After performing a TRIRIGA platform upgrade, some of the floor plans are not visible in the forms. Why aren’t they visible?

The TRIRIGA server cache needs to be refreshed. In other words, you need to clear the caches and restart the server. Here are more-detailed steps to clear your TRIRIGA cache and log folder:

1. Login to the Admin Console.
2. Go to the “Cache Manager” managed object.
3. Click on the “All Caches (Global)” link and then “Hierarchy Tree Data – with rebuild” link. The process might take some time.
4. Go to the “Database Manager” managed object, and click on the “Reprocess published drawings” link. Give the process some time to finish. Go to the current server log, and look for a related entry saying that the reprocess published drawing actions are finished. You will find a message similar to the following:
   “INFO [com.tririga.platform.graphics.vector.drawing.DrawingService](http-0.0.0.0-21001-7) Finished re-processing drawings”
5. Logout of the Admin Console.
6. Stop the TRIRIGA JVMs via the WebSphere Admin Console.
7. Delete the logs in the <TRIRIGA install>/log folder that has server.log.
8. Clear the WebSphere temporary cache folder.
9. Restart the TRIRIGA JVMs via the WebSphere Admin Console.

[Admin: This post is related to the 07.15.16 post about floor plan graphics disappearing after an upgrade, and the 09.29.14 post about clearing the TRIRIGA application server cache area. To see other related posts, use the “floor plan” or “clear cache” search phrase.]

IV96795: User without access can add security via Admin Console

A user who has limited access to people records (such as an External Vendor Admin), and who should not have access to add/delete licenses and security groups, is able to add licenses and security groups to an external vendor by running a command in the TRIRIGA Admin Console.

Moving forward, a client-side vulnerability that could allow a user to escalate their privilege, has been resolved.

[Admin: To see other related posts, use the Vulnerability tag or CVE tag.]

How do you use the “Lock” status in the TRIRIGA Admin Console?

In the TRIRIGA Admin Console, under “System Manager”, there is an option to “lock” the server so that maintenance can be done. When the server is up and in a “locked” status, users will not be able to log into TRIRIGA, but administrators can. Users will get a message when they attempt to log in that the system is “locked”.

It is important to know that if your agents are all stopped when you put the system in a “lock” status, and you restart your server, the server will not start back up. This is by design, because the server thinks an upgrade is being done, and you do not want to start up your server if an upgrade is in process.

[Admin: This post is related to the 11.28.12 post about disabling user logins to perform system maintenance.]

IV95382: Agent performance monitors not working properly

In the Admin Console, Performance Monitor, when monitoring a single value, it returns bad results. Returns wrong agent’s status. Returns “false” for an agent status even if the agent is running. Returns “0” for the number of agents running even if multiple agents are running.

We needed to update the calls to various platform status APIs. Moving forward, we updated the Admin Console, Performance Monitor, Single Value to correctly obtain the status of the active agents. This means the AGENTS_RUNNING_COUNT, OBJECT_PUBLISH_AGENT_RUNNING, SCHEDULER_AGENT_RUNNING, and all other agent-related monitors will now correctly report the agent status and count. We also removed the calls to KEYWORD_PARSER_AGENT_RUNNING and WAREHOUSE_AGENT_RUNNING as these no longer exist.

[Admin: This post is related to the 04.08.15 post about performance monitoring tools, and the 02.10.17 post about performance best practices.]