Aurora_Gaimon

CA PPM Application Housekeeping

Blog Post created by Aurora_Gaimon Employee on Dec 16, 2016

Many times I get the following question: “What are best practices / recommendations for CA PPM housekeeping?

 

In this post, I will explain some good practices regarding CA PPM application using OOTB (out of the box) jobs and workflows. Therefore, infrastructure housekeeping maintenance will not be covered.

 

 

OOTB Scheduled Jobs:

Schedule following general jobs to run on regular basis:

 

  • Purge Audit Trail: it's a good practice to set a max period to keep records in table. You need to set it on each object where audit trail is used. I’d recommend a max of 90 or 120 days, but all depends on how many attributes are being audited and your business needs.

 

Based on my experience, when table grows beyond 1 million records, it will cause performance issues.

Run the following query to check table size:

   SELECT COUNT(*) FROM CMN_AUDITS

       Ensure it does not grow beyond 1 million records.

 

  • Purge Documents: WATCH OUT!!!: Do not run it on regular basis unless this is what really you want, it will delete permanently documents!!!!  CA PPM administrator should always back up documents (“file store” files or DB dump if case they are stored in DB) before running job.

 

Job allows you to filter based on:

Purge All Documents for the Following Objects

[Or] Purge Documents and Versions Not Accessed for [n] Days

[Or Retail the [n] Most Recent Version and Purge the Prior Versions

All Projects

Project OBS

Specific Project

All Resources

Resource OBS

Specific Resource

All Companies

Company OBS

Specific Company

Knowledge Store

 

  • Purge Notifications: It's a good practice is to delete old notifications. Based on my experience, users don’t do it .... Relay on “From Created” “To Created” to purge based on “n” days old, otherwise, table will grow and may cause performance issues (similar to audit trail)..

 

  • Delete Log and Analysis: This job will be already scheduled by default to run once per day. Do not cancel it, just accommodate scheduled time to your non-working business hours.

 

  • Delete Process Instance: It's a good practice to delete “completed” and “aborted” processes older than “n” days on regular basis depending on how long you need to keep details. Bear in mind, when going to more than 200.000 completed processes, it may cause slowness or performance issues.

 

  • Oracle Table Analyze Job: (Just if Database vendor is Oracle and CA PPM On Premise).  It's a good practice to run it weekly during non-working business hours. In case of general performance, based on CA Support or CA Services recommendations, you may run it daily.

 

This job refreshes statistics that are used to determine the best path or execution for a query.

Analyze statistics under certain circumstances, such as when the schema or the data volume has changed.

 

Processes:

 

  • Review on daily basis all failed processes: Re-try them and if still failing, troubleshooting error messages. Do not leave them unattended in “error/failed” status.

 

  • When aborting processes (cancel them), ensure they are not stuck in “aborting” status. If they are, run following query:

UPDATE BPM_RUN_PROCESSES
SET STATUS_CODE = 'BPM_PIS_ABORTED'
WHERE STATUS_CODE = 'BPM_PIS_ABORTING'

      and restart BG service.

 

  • Delete “Completed” processes via job Delete Process Instance.

 

  • Delete “Aborted” processes via job Delete Process Instance.

 

  • Ensure there are not orphan records:

SELECT * FROM BPM_RUN_PROCESSES

WHERE PROCESS_VERSION_ID NOT IN (SELECT ID FROM BPM_DEF_PROCESS_VERSIONS)        

         In case it returns results, then proceed with following:

DELETE FROM BPM_RUN_PROCESSES

WHERE PROCESS_VERSION_ID NOT IN (SELECT ID FROM BPM_DEF_PROCESS_VERSIONS)

         and restart BG service.

 

  • Ensure there are not orphan Process Engine records: It’s a good practice to remove an outdated and unused Process Engine. You can run the following queries to identify the inactive process engines and delete them: 

      For Oracle:

SELECT * FROM BPM_RUN_PROCESS_ENGINES 

WHERE END_DATE != NULL OR END_DATE <= SYSDATE

      If it returns results, then proceed with following:

 

DELETE FROM BPM_RUN_PROCESS_ENGINES

WHERE END_DATE != NULL or END_DATE <= SYSDATE

        For MSSQL:

 

SELECT * BPM_RUN_PROCESS_ENGINES
WHERE END_DATE != NULL OR END_DATE <=GETDATE()

      If it returns results, then proceed with following:

DELETE FROM BPM_RUN_PROCESS_ENGINES
WHERE END_DATE != NULL OR END_DATE <= GETDATE()

       Restart the APP and BG services.

 

 

That’s all. Thanks for reading until here. Did you like it? Please, don’t be shy and share it.

Outcomes