DevForce Community Forum : Audit log implementation http://www.ideablade.com/forum/ This is an XML content feed of; DevForce Community Forum : DevForce Classic : Audit log implementation Fri, 12 Jun 2026 00:05:16 -700 Tue, 31 Jul 2007 10:59:34 -700 http://blogs.law.harvard.edu/tech/rss Web Wiz Forums 9.69 360 www.ideablade.com/forum/RSS_post_feed.asp?TID=246 DevForce Community Forum http://www.ideablade.com/forum/forum_images/IdeaBlade_logo_tm.png http://www.ideablade.com/forum/ Audit log implementation : Michael, One of the critical... http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=813#813 Author: davidklitzke
Subject: 246
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.
]]> Tue, 31 Jul 2007 10:59:34 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=813#813 Audit log implementation : David, thank you for your response.I... http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=800#800 Author: MichaelNiemann
Subject: 246
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


Edited by MichaelNiemann - 30-Jul-2007 at 7:59am]]> Mon, 30 Jul 2007 07:58:44 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=800#800 Audit log implementation : Michael, After thinking about... http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=719#719 Author: davidklitzke
Subject: 246
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.
]]> Wed, 18 Jul 2007 10:04:12 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=719#719 Audit log implementation : Actually, it would be sufficient... http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=715#715 Author: MichaelNiemann
Subject: 246
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
]]> Wed, 18 Jul 2007 05:11:37 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=715#715 Audit log implementation : Michael, It is easy enough... http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=706#706 Author: davidklitzke
Subject: 246
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.
 
]]> Mon, 16 Jul 2007 17:27:52 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=706#706 Audit log implementation : DavidK, Are you following me... http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=551#551 Author: MichaelNiemann
Subject: 246
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]]> Mon, 16 Jul 2007 06:52:11 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=551#551 Audit log implementation : Michael, You should be able... http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=547#547 Author: davidklitzke
Subject: 246
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.
]]> Fri, 13 Jul 2007 17:01:54 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=547#547 Audit log implementation : I have reviewed the &#034;Keeping... http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=541#541 Author: MichaelNiemann
Subject: 246
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



Edited by MichaelNiemann - 13-Jul-2007 at 9:42am]]> Fri, 13 Jul 2007 09:42:06 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=246&PID=541#541