cancel
Showing results for 
Search instead for 
Did you mean: 
Walter.Koller
Level 11
Status: New
When archiving session logs in BP it should be possible to chose another target location than file system. It should be possible to specify a target DB.

The session log table takes huge amount of space and regular archiving is inevitable. Normally only very few days are kept online in Blue Prism DB. Any investigation or analysis on log data needs first to restore from file system back into DB. 
The target of the restore has to be BP instance, thus may impact existing environment or new environment has to be set up.

The idea is to archive session logs into another table (in another DB) instead of file system. This opens several possibilities:
- DB Backup and Restore can be used (whose implementation is normally more sophistiscated than file system backups)
- Table organization can be utilized (eg partitioning)
- Data in this table can still be easily access and used 
- Backup and Restore to/from this table is independent of and won't affect BP instances
- Archived data in the table will be a snapshot at the time of archive (see below for implications)

Currently the session logs (and also archived logs) have references to other DB objects like resource, process, ... Although the deletion of the referenced records is prohibited as long as the session logs are online, they can be deleted when logs are archived. 
Restoring session logs may then have an incomplete view of what happened in the past since referenced resource, user and process may already been deleted or otherwise lost (eg upgrading BP into new BP instance).
Therefore those references have to be resolved into their names (in addition to their IDs) before writing into archive table.
1 Comment
This is a great idea. It would be really helpful if the underlying database was better structured to facilitate archiving/purging of data from the Blue Prism database to more easily enable the production database to be maintained at a manageable size. It is important to consider what format the archived data is exported/retain in to enable query on that archived data if required (and this may mean bringing over those foreign key values like process, resource, etc).