Why is classification hierarchy corrupted after daily cleanup?


When you attempt to open the classification hierarchy, an error message is displayed in the hierarchy pane, and you cannot do anything at that point.

We modified the “Clause Type” classification hierarchy using the Cut/Paste and Delete actions in the hierarchy pane of the classification hierarchy view/window. These actions were successful and we saw no immediate issue. However, after the cleanup ran over the weekend, we started getting the error message that the hierarchy encountered an error trying to build itself.

The resolution to the issue was to add the “Classification” value to the TRIRIGAWEB.properties option for REBUILD_HIERARCHIES_ON_CACHE_REFRESH.

Continue reading

What is the TASK_RESULT_LIST table and CLEAN_TIMEOUT property?


In one of our production instances, we have a table called TASK_RESULT_LIST containing almost one billion rows. What is the intent of that table and is there someway we can clean it up?

Anyway, when the Cleanup Agent runs, it is stopped with an Agent Interrupt Exception after 120 minutes (as per CLEAN_TIMEOUT in TRIRIGAWEB.properties). Though, it seems the Cleanup Agent doesn’t start the next day when that happens (or any following day until the process server is restarted). Is there some flag saying that the agent is already running and that flag is not getting reset when the agent is stopped due to hitting the CLEAN_TIMEOUT?

That TASK_RESULT_LIST is used to record workflow step instances. It is not safe to directly modify the table. The Cleanup Agent (a.k.a. Platform Maintenance Agent) is supposed to keep this table clean. Check the following TRIRIGAWEB.properties…

To help work around this, I would set the CLEAN_TIMEOUT property to 300. This will allow the Platform Maintenance Agent to run for a longer amount of time and clean up more records. The reason the table got so large, is that you had workflow instance recording on. Our recommendation is that workflow instance recording is never run in production, or for long periods of time. It is also not safe to truncate that table, as user action and approval tasks would be deleted and would no longer process. We also increased the default value of CLEAN_TIMEOUT to 300 in our next release…

Continue reading

IV93757: Scheduled events not being removed from T_SCHEDULEDEVENTS


Scheduled events are not being removed by the Cleanup Agent from the table T_SCHEDULEDEVENTS after the scheduled events are completed. This causes this table to grow immensely, especially for companies that use recurrence events in their calendar. Identifying the records can be done via SQL…

The deletion of these records are currently not automated by the Cleanup Agent.

Moving forward, the completed scheduled events older than the value specified in the property CLEANUP_AGENT_SCHEDULED_EVENT_COMPLETE_DAYS will
now be marked for deletion.

Continue reading

Why are associations reappearing after the Cleanup Agent runs?


We are experiencing an issue where associations seem to be recreated after the Cleanup Agent has run, and I wondered if anyone else had experienced this before?

On a Capital Project template, we have associated some Work Task and Schedule Task templates, and these are successfully showing up in the query section on the Schedule tab of the Capital Project template. We have a Remove action on the query section, which, when we select a Task template and click remove it, de-associates the record from the Capital Project template. We have verified that the associations are deleted and the record disappears from the query section. However, after the Cleanup Agent runs, these removed task templates are reappearing in the query section of the Capital Project template and the associations have been recreated.

Is anyone aware of this behaviour, or of something in the Cleanup Agent that might be recreating these associations? If so, is there a way around it as users are starting to complain that records they have removed are showing back up again?

Continue reading

What is causing the Cleanup Agent error when using Oracle?


Our Cleanup Agent has been giving the following error for the last several days whenever it runs (either manually or scheduled). None of the deleted records in the system are getting cleaned out. We are using TRIRIGA 3.5.1.3. Has anyone seen this error before and know what could be causing it?

Caused by: java.sql.SQLSyntaxErrorException: ORA-01722: invalid number

It appears that Oracle thinks that there is a non-numeric value stored in the SPEC_ID. Try these statements and see if you can spot the value:

SELECT SPEC_ID FROM T_GROUPMEMBER ORDER BY SPEC_ID ASC;

SELECT SPEC_ID FROM T_GROUPMEMBER ORDER BY SPEC_ID DESC;

Continue reading

When and how do you clean up application server temp files?


Over time, the temp (temporary) directory may fill up with files on the application server or process server. You may want to clean up these files over time, it is generally safe to delete files over 2 days old. We suggest setting up a cronjob (Linux/Unix) or Scheduled Task (Windows) that deletes temp files owned by the user running the TRIRIGA application, over 2 days old.

As an example, on a Linux environment, the following command can be placed into a shell script file, then run nightly at 1 am.

(1) Shell script file: /path/to/script/cleanTririgaTemp.sh

find -mtime +2 -user tririga -exec rm {} \;

(2) Don’t forget to chmod to make it executable:

chmod u+x /path/to/script/cleanTririgaTemp.sh

(3) Then run crontab -e and set the script to run daily at 1am:

0 1 * * * /path/to/script/cleanTririgaTemp.sh

Continue reading

Why can’t the Cleanup Agent clean large number of records?


I have a problem with a TRIRIGA environment. Due to an inefficient integration, we have a large number of records with a negative Object ID ready to be cleaned by the Cleanup Agent. But it seems that the Cleanup Agent can’t clean that many records.

Can I configure something or execute something into the database to clean everything in parts? I guess that I cannot simply execute a delete into the database, where the object_id < 0, since there must be more things to clean.

No, you should not go into the back end and execute a delete on the database. There is a lot more to clean up. What do you mean the Cleanup Agent cannot clean that many records? Are you getting an exception? The OBJECT_ID must be negative, the OBJECT STATE should be null, and the UPDATED_DATE must be over 24 hours earlier for the Cleanup Agent to pick up the records to delete. It also might take a couple runs of the Cleanup Agent to delete all of the associated records.

[Admin: This post is related to the 02.24.16 post about cleaning up after retiring a record, and the 07.14.15 post about cleaning up millions of workflow instance records. As a side note, starting with version 3.4, the Cleanup Agent name was changed to Platform Maintenance Scheduler.]

Continue reading