New Posts New Posts RSS Feed: Audit log implementation
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Audit log implementation
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
MichaelNiemann View Drop Down
Newbie
Newbie


Joined: 12-Jul-2007
Posts: 10 		Post Options Post Options   Quote MichaelNiemann Quote  Post ReplyReply Direct Link To This Post Topic: Audit log implementation
    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
Back to Top
davidklitzke View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 14-Jun-2007
Posts: 715 		Post Options Post Options   Quote davidklitzke Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
MichaelNiemann View Drop Down
Newbie
Newbie


Joined: 12-Jul-2007
Posts: 10 		Post Options Post Options   Quote MichaelNiemann Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
davidklitzke View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 14-Jun-2007
Posts: 715 		Post Options Post Options   Quote davidklitzke Quote  Post ReplyReply Direct Link To This Post 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.
 
Back to Top
MichaelNiemann View Drop Down
Newbie
Newbie


Joined: 12-Jul-2007
Posts: 10 		Post Options Post Options   Quote MichaelNiemann Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
davidklitzke View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 14-Jun-2007
Posts: 715 		Post Options Post Options   Quote davidklitzke Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
MichaelNiemann View Drop Down
Newbie
Newbie


Joined: 12-Jul-2007
Posts: 10 		Post Options Post Options   Quote MichaelNiemann Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
davidklitzke View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 14-Jun-2007
Posts: 715 		Post Options Post Options   Quote davidklitzke Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down