Search Results ar_conc_request_messages_u1

Overview

AR.AR_CONC_REQUEST_MESSAGES is a transaction-data table in the Receivables (AR) schema of Oracle E-Business Suite, present and valid in both release 12.1.1 and 12.2.2. It functions as a transient message repository for the Customer Merge concurrent program, storing the untranslated error and status messages that the merge process emits while it runs. Rather than writing diagnostics directly to the concurrent manager log, the program stages each message line as a discrete row keyed to the originating concurrent request. This design allows message text to be captured, associated with a specific request, and later rendered into the log or output file, and it permits selective suppression or translation depending on the TYPE flag.

Because the row lifecycle is tightly bound to a single concurrent run, the table is best understood as an append-only journal of program feedback rather than a master or reference entity. From a Data Vault modeling perspective, the mined FK structure classifies this object as standalone, meaning it does not participate in a classic hub-and-link topology. It is most naturally modeled as a satellite-style record attached to the concurrent request, since it carries descriptive, run-specific attributes (message text, error number, translation disposition) rather than keys that link independent business entities. Treated heuristically, the concurrent request acts as the effective parent, and each message line is a descriptive child.

Key Information Stored

The table holds seven documented columns. The most important are:

• CONC_REQUEST_MESSAGE_ID (NUMBER 15) — the unique identifier for every message line inserted. Although mandatory and unique in isolation, the documented unique index pairs it with REQUEST_ID, so it is the surrogate key of the message record rather than an independent business key.
• REQUEST_ID (NUMBER 15) — the concurrent request identifier of the program that generated or last updated the row, documented as a foreign key to FND_CONCURRENT_REQUESTS.REQUEST_ID. Together with CONC_REQUEST_MESSAGE_ID it forms the composite business-key candidate in index AR_CONC_REQUEST_MESSAGES_U1.
• ERROR_NUMBER (NUMBER) — the numeric error code associated with the message, used to distinguish hard errors from informational status output.
• TYPE (VARCHAR2 30) — translation disposition, holding either "Translate" (the message should be translated before display) or "No Translate" (render verbatim).
• TEXT (VARCHAR2 500) — the actual message text passed from the merge program; this is the payload rendered into the log or output file.
• CREATION_DATE (DATE) and CREATED_BY (NUMBER 15) — the standard WHO columns recording when and by which user (FK to FND_USER.USER_ID) the row was created.

The table's documented unique index, AR_CONC_REQUEST_MESSAGES_U1, resides in the APPS_TS_TX_IDX tablespace, while the table body is stored in APPS_TS_TX_DATA with PCT Free 10.

Common Use Cases and Queries

The primary operational use is post-run diagnostics: reviewing why a Customer Merge concurrent request produced warnings or errors, and identifying which rows must be manually remediated before a re-run. Support and reconciliation queries typically join to FND_CONCURRENT_REQUESTS to obtain the request name and completion status alongside the captured messages.

• Retrieving all messages for a specific request:

SELECT CONC_REQUEST_MESSAGE_ID, ERROR_NUMBER, TYPE, TEXT
FROM AR.AR_CONC_REQUEST_MESSAGES
WHERE REQUEST_ID = :p_request_id
ORDER BY CONC_REQUEST_MESSAGE_ID;

• Isolating hard errors versus informational output by filtering on ERROR_NUMBER IS NOT NULL.
• Auditing translation disposition by grouping on TYPE to confirm which messages were flagged "Translate" versus "No Translate".
• Correlating messages with the owning user and creation time using CREATED_BY and CREATION_DATE for chronological troubleshooting.

Because rows are tied to a single run, queries should always constrain on REQUEST_ID to avoid scanning messages from unrelated merge executions.

Related Objects

The table sits within a small, well-defined dependency graph:

• FND_CONCURRENT_REQUESTS — joined on REQUEST_ID = FND_CONCURRENT_REQUESTS.REQUEST_ID; supplies the request name, phase, and status.
• FND_USER — joined on CREATED_BY = FND_USER.USER_ID; identifies who initiated or last touched the row.
• AR.AS_CONC_REQUEST_MESSAGES — the source object referenced by the CONC_REQUEST_MESSAGE_ID foreign key relationship, serving as the message-definition counterpart.
• APPS.AR_CONC_REQUEST_MESSAGES — the APPS-synonym or view through which the table is commonly accessed in application code and reports.
• Customer Merge concurrent program — the consuming process that inserts and reads these rows during merge execution.

The table references no other database objects beyond the documented FK relationships, confirming its narrow, request-scoped purpose.