Release 10.1A: OpenEdge Getting Started:
Core Business Services

> ## How auditing context is referenced by audit event records

> OpenEdge records application context information in one place and then references that context information from many individual audit records. This approach is much more efficient in terms of I/O, CPU, and disk space resources, but requires additional work when creating reports.

> When OpenEdge creates an auditing record, it automatically generates and inserts as the primary index a UUID value that is unique across time and space. The ID values are stored as compressed, character-encoded, Base64 values. The client session, application context, and audit event group records all have one of these ID index fields.

> When one of the database clients generates one of these auditing context events, it passes it to each of the connected databases. If the database connection is not audit-enabled, the context event is ignored. Each audit-enabled database connection will record the event according to the event’s configuration in the database’s audit policy. During this process, the primary index ID remains the same regardless of which database the event is recorded into. Even though each database’s event record might have a slightly different time stamp, the event record is essentially duplicated. During archival merging operations, these duplicates can be removed without harming the integrity of the auditing data.

> Within the auditing record are three indexed, foreign key, character fields that are used to hold the ID index values of client session, application context, and audit event group records. A fourth indexed character field holds the client’s database transaction ID.

> Figure 10–2 shows the relationship among the various auditing records.

> Figure 10–2: Auditing record relationship

> Each client’s database connection has storage for each of the four auditing context IDs. When the scope of a client session, application context, audit event group, or database transaction context begins, its ID is recorded in each audit-enabled database connection within the client. When the scope of a context ends, the context’s ID is cleared from each audit-enabled database connection so that it is no longer recorded in audit records.

> When an audit-enabled database connection generates and writes any auditing record, it will copy the context IDs from the connection’s storage into the record. This recording of the auditing context ID occurs regardless of whether or not the context event is physically recorded in the database.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095