Clarity

<gel:log>*** TEST TEST TEST ***</gel:log>

</gel:script>

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 Information




Any pointers would be helpful.

Hi Rajat,

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.

Regards

Suman Pramanik 

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  

Regards

Suman Pramanik 

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 table
typically 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 Instance
job."

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.

Hi Ronald,

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_ERRORS
SELECT * 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,  or 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 

Regards

Suman Pramanik 

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.

Regards

Suman Pramanik