User story
Minor User Story :
=======
In order to manage and audit my ECM system I want to be able to :
- select a document and view it's full history : creation / modification / workflows ...
- make reporting on platform usage (who logs in, to see what).
In order to keep a clear view of the activity of my co-workers, I want to be able to :
- view what document my co-workers have worked on
- view what tasks have been resolved by my teams
- view who consulted the last documents I wrote
= TimeLine
The Dev Story :
=========
Because Audit logs will be used for business reports and monitoring, it must be easy to configure what data in stored in audit log.
Idealy, I don't want to write code for that :
- simply configure where is stored my table
- configure fields that are attached to audit records
I want to be able to feed or query the Audit Logs from Java code.
For synchronization purpous, I want to have a REST or WS API to fetch "what happened" in the platform for a give time frame.
What we have for now :
=============
A Log persistence engine based on JPA.
A pluggable EntityBean factory.
A local local and remote API for :
- creating / getting a log record
- make basic JPA Query
A JbossWS based Web Service that exports the uuids of modified documents for a given time frame.
Design notes :
========
Storage engine :
---------------------
If there is no way to make JPA flexible, we should either use direct JDBC or use SQL Directory.
Using SQL directory would be very good (we can define a dedicated SQLDirectory API if needed).
Audit format config :
--------------------------
Configuration of Audit format could be defined by el-expression with a plugable evaluation context (default to : user, event, document).
=> It's easier to define EL expression and eventually extend Context than contributing a JPA class.
LogEntry API :
------------------
Current implementation returns Entities.
This is a problem for several reasons :
- contributing entities in a pain
- for remote EJB3 access and multi-JVM deployment this is a problem since
entity implementation class needs to be present both client side and server side - client code have to do an explicit cast or use java instrospection to use extended fields !
Target LogEntry implementation should extend exisiting LogEntry interface and simply wrap a HashMap for additionnal attributes.
JMS dep :
------------
Audit is for now dependent on JMS.
If we really want to make audit part of the Core Services and let it deploy into a Servlet Container, we should probably move the
loging code into a helper class that the could be called from a MDB or a CoreListener.
