Search Results audit_message

Overview

APPS.IBC_AUDIT_LOGS_V is a reporting and inquiry view in Oracle E-Business Suite Release 12.1.1 and 12.2.2, defined in the APPS schema over the IBC audit logging infrastructure. The view projects the audit trail rows persisted in IBC_AUDIT_LOGS and enriches each row with dynamically derived columns produced by the IBC_AUDIT_LOG_GRP package. Specifically, it exposes a human-readable audit message together with five ordered "extra information" slots (extra_info1 through extra_info5), each of which is computed on demand via IBC_AUDIT_LOG_GRP.get_extra_info(audit_log_id, n).

The view is intended for read-only consumption — user interfaces, concurrent programs, and integration extracts that require a flattened, descriptive representation of audit activity without replicating package logic in application code. Because the descriptive columns are function-based, the view encapsulates the presentation rules of the audit log in a single place, ensuring consistent interpretation of audit records across modules that share the IBC logging framework.

Underlying Base Objects

The view is defined over two documented objects:

• IBC_AUDIT_LOGS (referenced through a SYNONYM) — the base table holding one row per logged audit event. The view selects all of its principal columns, including audit_log_id, activity, user_id, time_stamp, object_type, parent_value, object_value1 through object_value5, description, internal_flag, application_id, creation_date, and object_status.
• IBC_AUDIT_LOG_GRP (a PACKAGE) — the PL/SQL package supplying the derived columns: get_audit_message(audit_log_id) produces audit_message, and get_extra_info(audit_log_id, n) produces extra_info1..extra_info5 for n = 1 through 5.

There is no write path through the view; INSERT, UPDATE, and DELETE are not supported because of the function-based columns. The underlying table remains the only valid target for audit log maintenance performed by the logging framework.

Key Columns

• AUDIT_LOG_ID — Primary identifier for the audit event, and the key passed into both package functions.
• ACTIVITY / OBJECT_TYPE / OBJECT_STATUS — Classify the logged action and the business object type and status affected by it.
• USER_ID / TIME_STAMP / CREATION_DATE — Identify the acting user and the event and row-creation timestamps.
• PARENT_VALUE / OBJECT_VALUE1..5 — Business keys and structured attributes captured at logging time.
• DESCRIPTION / INTERNAL_FLAG / APPLICATION_ID — Free-text description, internal-only indicator, and owning application.
• AUDIT_MESSAGE — The formatted, display-ready message returned by IBC_AUDIT_LOG_GRP.get_audit_message.
• EXTRA_INFO1..EXTRA_INFO5 — Positional supplemental detail returned by IBC_AUDIT_LOG_GRP.get_extra_info(audit_log_id, n). The specific content of each slot is determined by the package implementation, which typically maps the five object_value columns or item-type-specific attributes to labeled detail lines.

Common Use Cases and Queries

Typical scenarios include reconstructing the audit history of a configured object (an item, a transaction type, or a set of attributes), validating that audit records were written for a given activity, and feeding downstream extracts with display-ready audit text. A representative query retrieving the activity trail with enriched detail is:

• SELECT audit_log_id, time_stamp, user_id, activity, object_type, object_value1, audit_message, extra_info1, extra_info2 FROM apps.ibc_audit_logs_v WHERE object_value1 = :p_object_value ORDER BY time_stamp;
• SELECT audit_log_id, audit_message, extra_info1, extra_info2, extra_info3, extra_info4, extra_info5 FROM apps.ibc_audit_logs_v WHERE application_id = :p_app_id AND time_stamp >= :p_from_date;
• SELECT user_id, activity, COUNT(*) FROM apps.ibc_audit_logs_v WHERE object_type = :p_object_type GROUP BY user_id, activity;

Because extra_info1..5 are function-based, filtering or ordering directly on those columns invokes the package for each candidate row; performance-sensitive queries should filter on the base columns (AUDIT_LOG_ID, APPLICATION_ID, TIME_STAMP, or the object_value columns) and project the derived columns only in the SELECT list. Where the package functions raise exceptions for unrecognized audit configurations, outer-joining or wrapping the calls defensively is advisable.