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

Why do “ghost” lease records appear in TRIRIGA?


I found two “ghost” entries for (blank) lease records in TRIRIGA without any Status recorded or ID assigned. When I open the record, I can still see the “Create Draft” button on the record. Has anyone seen this situation?

Typically, these are records that were deleted by some process, but have not been fully removed by the Cleanup Agent yet. Usually, the application filters these out of the query views, but sometimes, for various reasons, they show up in queries as a blank row.

Continue reading

IV89144: CLEAN_TIMEOUT property not working as expected in 3.5.1


With the CLEAN_TIMEOUT property set to 10 minutes, 10 minutes is too low of a setting and not recommended. Typically, it is set to a value to prevent the Cleanup Agent from running too long.

How that property comes into play with the Cleanup Agent is that it runs each cleanup task in order. The cleanup process contains several tasks: cleaning up BO records, workflow instance history, doc tables, etc. Once a task is complete, it looks at the current running time, compares it to the property, and decides whether or not to continue with the next task. With that said, it doesn’t even look like it’s honoring the property at all, based on your logs, because it should have ended at this line:

2016-09-01 22:28:58,117 INFO [com.tririga.platform.dataconnect.JobControlManager](PlatformMaintenanceScheduler) DataConnect Tables Clean up completed at Thu Sep 01 22:28:58 CDT 2016 deleted 0.

Continue reading