Search Results ar_conc_request_messages




Overview
Explore in AI Chat

Overview

AR.AR_CONC_REQUEST_MESSAGES is a Receivables (AR) module table that stores untranslated messages produced by server-side PL/SQL for concurrent request error and log reporting. It functions as a diagnostic repository: when a Receivables concurrent program executes a server-side PL/SQL routine and that routine encounters an error or emits a log entry, the message text is written here rather than being rendered through the standard Oracle Applications message dictionary. Because the stored strings are untranslated, the table is intended for developer and support-level diagnosis rather than end-user display in a localized environment.

The object is documented as VALID in the AR schema and carries seven physical columns in the ETRM 12.2.2 schema snapshot, a footprint unchanged in 12.1.1. The relationship metadata classifies this table heuristically as standalone. Under a Data Vault modeling suggestion, the absence of outbound foreign keys other than the association to AS_CONC_REQUEST_MESSAGES indicates the table behaves less like a transactional link and more like a satellite-style diagnostic record keyed by request context, with the natural parent being the concurrent request itself. Modelers should treat the request context as the hub reference and the message rows as dependent descriptive detail.

Key Information Stored

  • CONC_REQUEST_MESSAGE_ID — the surrogate identifier for each message row; part of the documented unique index alongside REQUEST_ID.
  • REQUEST_ID — the concurrent request that produced the message; the principal join key back to FND_CONCURRENT_REQUESTS.
  • ERROR_NUMBER — the associated error number for the failure or log event, used to categorize the diagnostic condition.
  • TYPE — classifies the message (for example, error versus log), governing how the row is interpreted by reporting and support tools.
  • TEXT — the untranslated message body emitted by the server PL/SQL layer.
  • CREATION_DATE — the audit timestamp of when the message was recorded.
  • CREATED_BY — the standard EBS audit column identifying the creating user or session.

The documented unique index AR_CONC_REQUEST_MESSAGES_U1 on (REQUEST_ID, CONC_REQUEST_MESSAGE_ID) is the best business-key candidate, exposing the fact that message rows are sequenced and scoped by concurrent request.

Common Use Cases and Queries

The dominant use case is troubleshooting a failed or partially successful Receivables concurrent program. Support teams retrieve all diagnostic output for a specific request by joining to the concurrent request definition:

  • Retrieve messages for a request: SELECT crm.error_number, crm.type, crm.text, crm.creation_date FROM ar.ar_conc_request_messages crm WHERE crm.request_id = :p_request_id ORDER BY crm.conc_request_message_id;
  • Correlate with the request record: SELECT fcr.request_id, fcr.concurrent_program_id, fcr.phase_code, fcr.status_code, crm.text FROM apps.fnd_concurrent_requests fcr JOIN ar.ar_conc_request_messages crm ON fcr.request_id = crm.request_id WHERE fcr.request_id = :p_request_id;
  • Reporting on recurring error numbers: aggregate by ERROR_NUMBER over a date range filtered on CREATION_DATE to identify systemic failures.
  • Logging-volume analysis: count rows per REQUEST_ID to detect programs that emit excessive diagnostic output.

Because messages are untranslated, extracts are typically consumed by technical staff or loaded into a centralized monitoring repository rather than published to business users.

Related Objects

  • AS.AS_CONC_REQUEST_MESSAGES — referenced through CONC_REQUEST_MESSAGE_ID; the documented relationship link for this table.
  • FND_CONCURRENT_REQUESTS — the parent concurrent request joined on REQUEST_ID.
  • FND_CONCURRENT_PROGRAMS — used with the request to identify the failing program.
  • FND_LOG_MESSAGES — the general EBS server logging table, complementary in diagnostic queries.
  • Receivables concurrent program server PL/SQL packages that write to this table as part of their error and log reporting logic.