There is object A in which XOG is performed using XOG account ABC by scheduled process. Since few fields in object A are audited out of the box trigger makes an entry by name ABC in cmn_audits table for any updates on object A.
I wanted the name of person who last updated object A to be shown in audit table. but this is not possible.
As i would need to touch the out of the box trigger or need to make entry into cmn_audits table directly which CA has not adviced to do.
Has anyone came across such scenario and how they get it worked?
Can anyone please help?
Well this is working 'correctly' of course - account "ABC" was the last account to update the record and so that it what is 'audited' in CMN_AUDITS.
If a user updates any fields on the record, then that will be recorded in CMN_AUDITS as the user.
So if you want to record the last "user" that amended the data on the record, then perhaps you will have to build that into your process's logic ; for example before the process runs the XOG to update your record, then get it to retrieve the last "user" who updated the record and store that in a custom-field (via XOG) or custom-table (via XOG or just SQL if not a Clarity object) somewhere?
Thank you for the answer. I have prepared the logic which would fetch the name of last updated by before the XOG is done and store in variable. Once the XOG is done I am updating the last updated by column of table A with the value of that variable.
I am referring the cmn_audits table to fetch the Audit changes on object A for custom Audit Portlet. For this single change its showing 2 rows in cmn_audits table of same time stamp, 1 with the name of ABC and another row with actual name of person who has last updated object A. Hence in Audit Portlet its showing 2 entries of ABC and clarity user for single change.
Can you please advise?
Sorry, it sounds like you are doing lots of "unsupported code" ; what I am suggesting is just that your specific 'requirements' are built entirely by yourself (i.e. not using the stock CMN_AUDITS functionality since this does not appear to match your 'requirement').
Within GEL (and your process that is performing the XOG), rather than take the 'last updated by' currently stored on the record, you can take the process instance ID variable instead (gel built-in value) and query the bpm_run_processes for the initiated_by field.
Once you have this, and a custom attribute on the object to hold the value for the 'xogged_on_behalf_of' user which you also audit, it should just be a matter of including that with your XOG write entry.
This would fix any issues of (near) concurrent UI updates by different people that then get XOG-audited as the same person since the process execution would be asynchronous. It's the same idea conceptually, but without depending on the changeable state of the row data whilst the process is in flight.
E.g. (describing a possible 'worst case scenario' without the logic revision proposed):
User1 makes change to the object
Process event fires for User1's behaviour, launches process1
User2 makes change to the object
Process event fires for User2's behaviour, launches process2
Process1 checks for last updated value on the object, finds User2
Process1 XOGs in the information, stores User2 as the user that made the change, whilst setting last_updated to the XOG account
Process2 checks for last updated value on the object, finds the XOG account
Process2 XOGs in the information, stores the XOG account as the user that made the change, whilst setting last_updated to the XOG account
In addition, I agree that it is better to avoid the unsupported code approach of directly manipulating the last_updated_by field values. Whilst not exactly the same as the scenario I wrote about in a blog post before, it is still a risky area to be interfering with as it explains: Impacts of direct database updates to the Audit Trail
( Small point, but I think - if I interpreted it correctly - that the original post was about a scheduled process rather than an auto-start / on-demand one, so the 'xogged_on_behalf_of' logic would just pick up the id of the user who scheduled the 'execute a process' job )
Think that Nick's blog post actually covers the underlying question in the original post though, much more than any of my ramblings!
Sandeep - I would advise you to use 2 separate attributes for saving different values for the 'Last Updated By' i.e. one original and second a custom attribute. There is no need to transfer the data from the custom attribute showing the actual resource's name into the original attribute showing the admin or the xog user. You will be required to define such a custom attribute in your custom object to show the name of the actual resource, who last updated the custom object/process, instead of the admin or the xog user. You can update the custom object view to show the custom attribute instead of the original attribute. And, this may also help to have a single value within the audit table for the custom attribute without any values for the admin or the xog user.
Hope this helps!