I am on version 15.3 and this basic script is not displaying any logs in the process messages
<gel:log>*** TEST TEST TEST ***</gel:log>
But when i am looking at the bg-ca.log i can see the following error messages
ERROR 2017-10-05 12:27:05,118 [Custom script execution pool-12-thread-13] utilities.BpmErrors (clarity:admin:5118300__249BBB92-EDEF-4036-AD40-DBADF4D76AE5:none) Begin Error Information: Step Action Id: 5014012 Process Instance Id: 5000041 Step Instance Id: 5000189 Error: bpm.raw.message Error Code: bpm.raw.message Exception Trace: *** TEST TEST TEST *** End Error InformationAny pointers would be helpful.
In 15.3 we have added a flag in CSA where you would like to store logs in BPM_ERRORS table, by default its set to Error and you want to do info logging then you would need to change
Restart the services and you should see its populating in the UI also. This is done to prevent the excessive logging.
We have documented it too in our release notes
Release Notes (On Premise) - CA PPM - 15.3 - CA Technologies Documentation
Thanks a lot Suman.
You prompt response is really appreciated.
Seems i have missed this in the documentation.
You are always welcome and I hope you are liking the CA PPM 15.3 release. Have a great day
Hi Suman, we just experienced this when verifying our DEV V15.3 environment which is SaaS. Our release notes only have:
"BPM_ERRORS Table Management: In previous releases, the size of the BPM_ERRORS tabletypically expanded with debug statements and process details. To reduce the size of this table,this release includes a new pre-scheduled daily recurring instance of the Delete Process Instancejob."
No mention of this new parameter, and as it is SaaS, I don't believe we have access to change it. Should the release notes for SaaS be updated to reflect this change, including contacting CA Support to request them to change it?
Additional observation, as part of the V15.3 upgrade, the upgrade deleted all records from BPM_ERRORS table. Appreciate why this parameter was introduced, but if we need this data (eg I may have scripts using it ), then the upgrade should not delete this data as part of the V15.3 upgrade, just because there is an introduction of a new parameter. Can this please be reviewed as part of the V15.3 upgrade process.
Very valid concern and thanks for letting me know. Rest be assured we don't delete the data and its moved to back up table BPM_ERRORS_BKP. As you are a SAAS customer, please raise a case and request the team to implement the solution. I have documented internally in a defect DE37432
Run the following query to get back the last 90 days of data into the BPM_ERRORS table.INSERT INTO BPM_ERRORSSELECT * FROM BPM_ERRORS_BKP WHERE LAST_UPDATED_DATE >= (SELECT (MAX(LAST_UPDATED_DATE)-91) CUTOFF_DATE FROM BPM_ERRORS_BKP)AND NOT EXISTS (SELECT 1 FROM BPM_ERRORS WHERE BPM_ERRORS_BKP.ID = BPM_ERRORS.ID);
On the setting in CSA, you can access make the change by going to http://CPPMXXXX/niku/nu#action:security.logs and then Edit configuration and you will see under
Many thanks Suman, I was able to reset this parameter, and in my case, it didn't need the Services to be restarted.
The two clients I have who are upgrading to V15.3 at this time, don't need the bpm_errors data, but glad to see it is backed up as I do have an additional client who still needs to schedule to move to V15.3.
Roland, You are welcome and I am sorry I got your name incorrect in my earlier post.