Object Auditing Overhead

Objects can be changed by users and this is a potential cause of havoc. To allow you to trace and easily revert changes, the Active Auditing Module has been introduced. The Active Auditing Module allows you to set up rules which will either trace changes on objects only, referred to as Diff only, or trace changes and revert, referred to as Full auditing.

note

The Active Auditing Module requires the Module.Auditing license key to be present in your license.

note

Under certain circumstances, you will receive audits for objects you are not directly auditing. For example, if you audit submit frames only and add a submit frame element which is defined by a time window, you will receive audits for this time window as well as the submit frame. When you change the time window, you change the submit frame, indirectly.

Object auditing does not apply when the system makes a change.

Examples of where the system makes a change are:

• Automatically submitted process definitions, with wait events for example
• Changes to configuration as the result of running system processes, such as System_Mail_Configure or SAP_ImportCcmsMonitors for example

Redwood Server only audits changes, not access. We also only audit users, not the system. So if I make a change, and an audit rule matches, it will be audited.

Overhead

• Space in the database
  • Diff only - depends on change volume. An estimated 3 times the size of the change
  • Full - depends on object size. An estimated 2 times the size of the object
• Time overhead when users make changes - this is relatively small, but will be noticeable for things like large chains or large imports.

Diff-only

In diff-only auditing, both the old and the new value of anything that changed are recorded, plus some overhead for the XML wrapping. So if you change the name of a parameter from StartDate to StartDateTime,for example, both values need to be recorded, the field name (Name) plus some XML to wrap it.

note

The deletion of audited objects is always audited at full level to allow you to restore the deleted object.

Full Audit

In full recording, a copy of the object is taken before and after the change, for each change. While some of these may be duplicates, this ensures that:

1. System changes (particularly upgrades and changes to processes) are reflected correctly.
2. That you get the right results when auditing is turned off, changes are made and then it is turned on again. This is particularly useful for very large imports.

As far as export and import are concerned, nothing special is done. If you use Export or Export Tree, there will be no specific auditing. If you run one of the system processes, or create an export object, then there will be some auditing if audit rules are enabled, and because an object is created, there will be something visible even if you don't have auditing enabled. Export is just reading the database, so nothing is audited.

Imports follow similar rules, all imports result in a system process running and potentially an import object being created. If auditing is enabled, objects that are imported that match audit rules will be audited. This goes both ways, as imports can potentially be large, and the overhead significant in this case. You may want to disable auditing for large imports.