Print this Page
5.2 Audit
01. What Did I Do
Close this Page

1. What Did I Do:
An evidence trail of each request made to Eliza by an approved person is maintained for each day.
The evidence trail may include reply decisions made by Eliza and will include all page identities.

2. Structure:
A unique file indexed by the persons unique key is created per day for each approved person when they sign in.   The total number of files created is the number of unique people who sign in on a specific date.   The file is an evidence trail in date, time and request number order - it clearly shows what a person did in the order they did it.

3. Replay:
What did I do data can be viewed in a spreadsheet in date and time order so what page was shown to a person at any point in time can be identified.   Every data entry request is stored as evidence so the progress of how the application was used can be identified - behaviour is detected.
What did I do data can be replayed in quick time, to watch what a person was doing and how they were doing it - problems can be replayed many time to identify potential issues.

4. Mission:
1. What Did I Do is about Event Support Management and Incident Management for first and second level support can replay exactly what lead up to a reported incident.   The level of logging may be increased for part of the application service where more information is needed to fully diagnose the incident.
2. Simple statistical analysis can identify who long it takes to complete a process, how many procedures are done each day and how many warnings need to be issued.   Capturing behaviour is the true mission and while 95% of behaviour is normal and predictable, full recording of that other 5% is what can lead to improvements and better ways of working.

4.5.09 What Did I Do:
In 2004, the user audit trail was a daily text file stored in a folder by month.   In 2009, "What Did I Do" was configured as a database table.   In 2013, "What Did I Do" audit trail has evolved back to a text file stored in a folder by date.
Evolution will take our servers to "in memory computing" and we need to optimise the database to be always in memory.   That demands that WDID is removed from the database and stored in a normal log file.

Purpose:
WDID is an audit trail of every request that a user makes.   What a user did can be replayed by time to determine what and how requests happened.
WDID has a high value on the day it is written, but that value decreases over time so that after say a month is has relative no value.   WDID is used by support administration with users less interested in what they have done - available but not used.

Record Order:
The nature of all log files is time sequenced with data being appended tot he end of the file.   It is too expensive to try to write data to the beginning of a physical file.
WDID reporting has been presented in reverse time order with the last thing done at the top of the page, but this is expensive to present.   The entire file must be read into an array that is then sorted by time - this can become a massive memory drain and is not cost justified.
KISS - simplicity has prevailed and WDID data is presented in time order down the page.   This has the least impact on memory and processing requirements that is applicable to data with a relatively low value.

Data Structure:
The key field is a message area that contains one or more keyword parameters and values in the style "field=23".
The list of messages is indexed by:
1. User key as 6 digits that implies branch office
2. Date as 8 digits like YYYYMMDD
3. Time as 6 digits like HHMMSS (using GMT)
4. Page Number as 4 digits that implies application
5. Page Function as up to 8 characters such as CHANGE
6. Page Subject as 32 characters with underscores but no numbers
7. Message as one or more keywords and values

API:
"pdos_1001_what_did_i_do($message);"
No reply is returned.
The current date is implied and a folder for the current date will be created when needed.
The current user key is implied and a ffile for the current user will be created when needed.
The user key, page number, function and subject must be provided via session variables.

Debug Mode:
When operating in debug mode, every database SQL update request is fully recorded to WDID but this data can only be viewed by ZZZ role.   SQL insert requests are only recorded in debug mode and may only be viewed by ZZZ users.

Public Pages:
The user key for any request to a public page is assigned as "000000".   Search facilities enable public page requests to be viewed, but this is merged from all public page users.   The public IP address may be added to WDID to provide some kind of separation.
Public cookie testing is recorded as public WDID and can be viewed using the user key as "000000".

Procedure:
1. Each day that a user signs in a new WDID file will be created for that date and user key.
2. Every request made by the user will be appended as a new line to the WDID file.
3. A new folder with a obfuscated name as "WYYMMDD" is created each day that a user signs in where ""W" is a prefix to the short year, two months and two day numbers.
4. A new file with a obfuscated name as "WNNNNNN.LL" is created each day that a user signs in where ""W" is a prefix to the 6 digit user key with a ".LL" file type representing a plain text file.

Time Zone:
The server time is used.   One day, this shall be always retained as GMT, no matter where the server is located and no matter where the user is located.
Each user profile has the users local time zone with an adjustment on GTM - time will be presented to each user as local time as an adjustment on GMT that is recorded.

Addendum:
WDID is a very simple sequential list of each user request - WDID does not try to create statistics, management information or knowledge.
ZSIN is a database table with one record per user to record sign in time and is updated with the users latest request that can be used by the "TODAY" function - indexed by user key.
ZING is a database table to record sign in transactions good and bad.