Typically, when you develop your application, you create all of the application events that the application is able to generate. You define what is an auditable event, depending on your application. Generally, an auditable event has two characteristics:
It represents some operation or point of execution within your application that you want securely and reliably reported.
There is no OpenEdge-defined raw database record or internal event whose reporting can properly represent the information you want reported.
When you deploy your application, you provide any documentation and tools support necessary for the deployment site to create the audit policies for generating an audit trail with the events you have defined. An audit-enabled database can contain one or more audit policies that specify specific database, internal, and application events (from all available events) that can be included in the audit trail recorded in that database. The actual audit events generated, depend on what audit policies are active. The sum total of active audit policies specify all of the audit events that the application actually generates when the connected database is audit-enabled.
As you design and code the application, you might need to organize auditing events within different auditing contexts that group audit events in different ways. You can specify all of the context information required in your application for organizing audit events, except the transaction context for database events, which is controlled entirely by OpenEdge. For more information on planning application events and their context, see OpenEdge Getting Started: Core Business Services - Security and Auditing.
It represents some operation or point of execution within your application that you want securely and reliably reported.