Field level auditing problem
Hello everyone.
I have some very strange behavior with Field level auditing.
I Enable field audit on Settings tab for Case type in dev environment, everything is working fine.
When I deployed it into Test environment it does not work properly.
The problem is when I create a case the instances of audit properties is created without GUID... GUID is empty, so only last instance is saved....
The class rules are connected to database table correctly.
The first case auditing went good, but then stopped working...
What could have happened?
Any suggestion will helpful.
Thanks in advance.
***Edited by Moderator Marije to add BUG tags***
Accepted Solution
Updated: 2 Jun 2023 8:51 EDT
Pegasystems Inc.
GB
@HalynaK2 This sounds like the issue described in the forum question Field Level Auditing is displaying empty (--) records in Old Value and New Value has records
You can read about a similar issue in the Resolved Issues page for Pega 8.6.3.
Lventur
IN
Please check before pzInsKey of the case is getting generated Field Level Auditing rule is getting invoked and history is getting added in FLA audit table.
Ernst & Young
ES
Hello @Gunasekaran Baskaran
Everything is created and added to FLAudit table, but without GUID, that is marked to be generated automatically.
The problem is autogenerated GUID, is not created.
Accepted Solution
Updated: 2 Jun 2023 8:51 EDT
Pegasystems Inc.
GB
@HalynaK2 This sounds like the issue described in the forum question Field Level Auditing is displaying empty (--) records in Old Value and New Value has records
You can read about a similar issue in the Resolved Issues page for Pega 8.6.3.
Sunlife
CA
@MarijeSchillern I am getting similar issue of empty pyGUID in Pega 8.7.4, what was the solution that Pega provided?
Bank of Singapore
SG
My issue is resolved after "We have created a custom activity and set pyAutogeneratedKey to true for the audit class. This resolves the reported behavior."
Sunlife
CA
@Madhu Yasarla, Yes I have the fix which will not break anytime soon. Repurpose this activity - CL: FLAudit- ID: pySave, to generate unique ID and set to .pyGUID property. Problem Solved!!
Updated: 21 Mar 2024 5:39 EDT
Pegasystems Inc.
GB
@APAL007 @Madhu Yasarla the issue logged in this forum post was specifically for the symptoms described.
Field Audit was not working for the first change of the data selected/provided for a field. The audit was only reflected after the second change was made. When the property involved a series of hierarchies, for example pageprop.pagelist(1).pageprop, the FLA objects will initially use deferred saves and the generated pzinskeys will be added to a savedFLAMap object. However, when the last pageprop was not eligible to save, all the deferred saves of earlier records were cancelled but the inskeys were not removed from the savedFLAMap object. Because of this, the parent FLA records were assumed to have been saved already when those saves were actually deferred. This was a missed use case for hierarchical properties, and has been resolved by adding an update to remove the inskeys from the savedFLAMap object so that in the subsequent property change the audit's FLA records for the parent properties (pageprop.pagelist(1)) will be saved again.
Fixed from these patch versions onwards:
8.5.6: BUG-685369
8.6.3: BUG-685371
8.7.1: BUG-685370
8.8: BUG-689116
@APAL007 @Madhu Yasarla the issue logged in this forum post was specifically for the symptoms described.
Field Audit was not working for the first change of the data selected/provided for a field. The audit was only reflected after the second change was made. When the property involved a series of hierarchies, for example pageprop.pagelist(1).pageprop, the FLA objects will initially use deferred saves and the generated pzinskeys will be added to a savedFLAMap object. However, when the last pageprop was not eligible to save, all the deferred saves of earlier records were cancelled but the inskeys were not removed from the savedFLAMap object. Because of this, the parent FLA records were assumed to have been saved already when those saves were actually deferred. This was a missed use case for hierarchical properties, and has been resolved by adding an update to remove the inskeys from the savedFLAMap object so that in the subsequent property change the audit's FLA records for the parent properties (pageprop.pagelist(1)) will be saved again.
Fixed from these patch versions onwards:
8.5.6: BUG-685369
8.6.3: BUG-685371
8.7.1: BUG-685370
8.8: BUG-689116
You can do a key word search (see description in my screenshot earlier) and check out the Resolved Issues. and Resolved Issues
If you need further help, I suggest you log a support issue via the MSP.