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.

@HalynaK2

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.

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.

@MarijeSchillern I am getting similar issue of empty pyGUID in Pega 8.7.4, what was the solution that Pega provided?

@APAL007 , is this issie resolved?, recently we also facing the same isse, our version is 8.8.3.

thanks,

Madhu

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.”

@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!!

@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.

@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.