Try OpenEdge Now
skip to main content
Core Business Services - Security and Auditing
Auditing : Developing an Audit-enabled OpenEdge Application : Audit-enabling your OpenEdge application : Implementing additional auditing options
Implementing additional auditing options
Auditing has a number of options that you as the application developer can choose to implement in your ABL product. If you implement changes in your application, those options will be available at the production site. If you do not implement the changes, the production site will not have this auditing optional feature. This section lists those development-time options.
If your auditing needs are nonexistent or the OpenEdge databases record auditing is all that is necessary (with no execution context, and if the user who connected to the database is the user to record in the audit log), you do not need to enable auditing for your application.
The databases record provides the following support, without you making any application changes:
*Support of CREATE, UPDATE, and DELETE record operations
*Support for identifying which record was affected
*Support for identifying which record fields were affected
*Support for recording field values at the time the record operation took place
*Identifying which database transaction the record operation was part of
*Identifying which sequence record operations occurred within the transaction
*The date, time, and time zone of the record operation
*The user who made the change, provided the user is either the blank user or the one whose account is in the OpenEdge databases _User table, and that account was authenticated through startup/connect -U and -P options and/or the ABL SETUSERID function to the _User table
If you do not make application changes to support auditing, you will not have any application execution context available to know which application performed the record operation (SQL or ABL), who the user was (if the ABL application uses its own user accounts), or any other details about the environment in which the record operation was performed.
* Supplying OpenEdge application context information
* Supporting user accounts outside of the _User table
* Using a dedicated OpenEdge database for auditing
* Setting up READ auditing
* Using a custom audit data/policy archive tool
* Bootstrapping the audit administrator user
* Creating audit policy and report templates
* Supporting custom audit policy tools