FAT availability in the Data Lake.

Having FAT in the Data Lake is a requirement that both internal audit as well as external auditors are looking for.

At nVent we have ER # 64280 posted, and it is too light in terms of endorsement in order to Infor to take action on it.

I would be interested to see if other folks have the same requirement being in the cloud environment, and if not how they have created a sustainable work around

Find more posts tagged with

Comments

Legacy Contributor

Hi Maurice, in MT Datalake land you don't really need FAT anymore

all changes, ie variations, are stored in the datalake

so as long as the underlying table is published in DL then you can show and audit of all changes

example of tracking bank account changes below, note this example ignores system updates from change ID (CHID) MECSVC, being a service account from an interface.

hope that helps

--*includeDeletionsWithMaxVariations=cbanac

--*includeAllVariations=cbanac

--*includeInSelectAll=s/g/p/l

select variationNumber, CHID, CONO, DIVI, BKTP, ACHO, BKID, BKNO, STAT, BANA, BAF1, BAF2, BAF3, BAF4, RGDT, RGTM,

accountingEntity, deleted, timestamp

from CBANAC

where

CONO = 100 and RGDT > 20210723 and CHID != 'MECSVC'

and (cast(CONO as varchar) + DIVI + cast(BKTP as varchar) + ACHO + BKID) in

( select cast(CONO as varchar) + DIVI + cast(BKTP as varchar) + ACHO + BKID

from CBANAC

group by CONO, DIVI, BKTP, ACHO, BKID

having count(1) > 1 )

ORDER BY CONO, DIVI, BKTP, ACHO, BKID, variationNumber desc

Legacy Contributor

George, thank you for your response.

I wonder what would happen if for whatever reason we would need to purge the DL, wouldn't that render this approach to be not useful?

Billy Willoughby

Greetings;

If being used for a legal or government audit purposes, I would almost feel the need to replicate the tables you need to audit into a on prem database with staging using the ETL tool. You could build the merge from ETL staging into a final audit database to only allow inserts, so any purges or rebuilds in the Data Lake would not be passed on the the final audit repository database. This would absolutely make sure the records are not removed or modified.

It is a little heavy on the initial investment, but if the audit is critical, this is how I would build it. There are several variations you could use like this, but that's my first thought.

Hope that helps with ideas;

Billy

Legacy Contributor

HI Maurice, yes if for some reason you purge production data lake this would impact this, however, that would have massive data impacts for a lot of things, Billy is correct you cold export to local store including all variations if this was important.

Just checking but you are aware you can export from the Field Audit trail admin panel ?

Copyright © 2025 Infor. All rights reserved.