Print Page | Close Window

Audit log implementation

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=246
Printed Date: 12-Jun-2026 at 1:26am


Topic: Audit log implementation
Posted By: MichaelNiemann
Subject: Audit log implementation
Date Posted: 13-Jul-2007 at 9:42am
I have reviewed the "Keeping an Audit Trail" example, and it is pretty primitive.

What I would like to do is obtain the "before image" from the before image (naturally), and the "after image" from the re-query after save.

Is this straightforward in the framework?

Regards, Mike


Replies:
Posted By: davidklitzke
Date Posted: 13-Jul-2007 at 5:01pm
Michael,
 
You should be able to see the "before image" in an a "Saving" Event Handler.  For an example of this, see the advanced tutorial on Abstract Classes".
 
You should be able to see the "after image" in a "Saved" Event Handler.  We have no code sample for this.  This may be more difficult because unlike the entities in the "Saving" Event Handler, the "Current Version" and "Original Version" of each entity are probably identical.

Posted By: MichaelNiemann
Date Posted: 16-Jul-2007 at 6:52am
DavidK,
 
Are you following me around? <g>
 
I mentioned to "after image" because triggers are used to finalize records being committed to the database.
 
And from your Concepts guide: 

Re-query After Save

DevForce immediately re-queries the entity after inserting or updating it successfully. Re-query is essential because the insert or update may provoke a data source trigger that modifies the data source object. We often use a trigger to update an optimistic concurrency column. A database-maintained timestamp is another common example. In such cases, the row in the database is no longer exactly the same as the row we wrote.

The PersistenceServer must update the entity and then send it back to the client’s PersistenceManagerr. The revised entity re-enters the cache, replacing its original; its RowState becomes Unchanged.

So I figured there would probably be support for both the "Being Saved" image, and the "After Save (re-queried after save) image. But as I said, the tutorial didn't go anywhere near this deep.

Mike

Posted By: davidklitzke
Date Posted: 16-Jul-2007 at 5:27pm
Michael,
 
It is easy enough to get the "after image".  You can see that in the "Saved Event Handler".
 
However, if you want to capture in an Audit record the "changes made by the database during the re-query", that is a lot more difficult.   This information is available to the Persistence Manager when it does a Merge of the returned data into the PersistenceManager cache.  Unfortunately,  there is currently no mechanism that will let a client auditing application access this information.
 

Posted By: MichaelNiemann
Date Posted: 18-Jul-2007 at 5:11am
Actually, it would be sufficient if there is an event hooked to ReQuery that would let me see the new state of the BO... since I could have captured "before changes" and "after changes but before committed to db". So just having the "after changes committed to db (requery)" would seem to be enough.

Mike

Posted By: davidklitzke
Date Posted: 18-Jul-2007 at 10:04am
Michael,
 
After thinking about this some more, it occurs to me that there is a way that you could get a list of the changes that occurred as a result of the requery.
 
(1) Turn off the requery using the ExcludeFromPostSaveRefetch property of the SaveOptions class.
 
(2)  Do a RefechEntities() and tie into the Fetching and Fetched events.
 
(3)  By comparing the Entities in the two Event Handlers, you should be able to discover what has changed.
 
I could also make a Feature Enhancment request, but I have no idea when or even if this Feature Request would be implemented.

Posted By: MichaelNiemann
Date Posted: 30-Jul-2007 at 7:58am
David, thank you for your response.

I was checking out this area because [as a newbie] auditing is an area that is important to our applications. I see that what we need is probably available (with a little work... which is OK, BTW).

Ultimately, the auditing functionality needs to be very close to the DBMS, because triggers can do things which are not visible to the front-end (unless you go thru the retrieve-after-update process). When I saw that was part of your framework, I thought DevForce may already have a pre-built solution to my problem.

Regards,
Mike

Posted By: davidklitzke
Date Posted: 31-Jul-2007 at 10:59am
Michael,
 
One of the critical considerations when considering an audit strategy is deciding whether you want to primarily audit changes that are occurring close to the database or changes that are happening at the client.  One reason that you might want to audit changes at the client is because you might want to know about changes that were made while the user was disconnected.  On the other hand, you might want to audit changes on the server if you were concerned about changes caused by database triggers.
 
DevForce is agnostic with respect to the best place to do the auditing.  We have some recommendations with respect to client-side auditing, but we are not experts on Database auditing packages as our software is as much as possible database vendor independent.  We do know however that there are some excellent packages that you can purchase.
 
If you want to get more auditing information about events on the server side, but you still want to primarily use client-side auditing, you could use RPC to call a static method on the Server.


Print Page | Close Window