Search Results as_conc_request_messages_pk

Overview

AS_CONC_REQUEST_MESSAGES is a table owned by the OSM schema within the Oracle E-Business Suite (EBS) Sales Foundation (AS) product family. Its documented purpose is to store error messages generated by concurrent programs. In Oracle EBS 12.1.1 and 12.2.2, concurrent processing is the engine that executes long-running batch jobs — order imports, pricing calculations, and similar Sales Foundation operations. When such a program encounters an error, the message line is persisted in this table so that the diagnostic context (error code, descriptive text, and the underlying database object involved) remains retrievable after the request completes.

From a data modeling standpoint, the mined Data Vault classification is standalone, meaning the table neither behaves purely as a hub, link, or satellite in the heuristic analysis. This should be treated only as a suggestion: the table has a single surrogate primary key and one outward foreign key, so a modeler could reasonably treat CONC_REQUEST_MESSAGE_ID as a hub key with the descriptive attributes as a satellite, but the documented evidence does not enforce that interpretation.

Key Information Stored

The table contains 15 documented columns. The most operationally significant are:

• CONC_REQUEST_MESSAGE_ID — the surrogate primary key, enforced by the unique index AS_CONC_REQUEST_MESSAGES_PK. It uniquely identifies each message row.
• REQUEST_ID — the concurrent request to which the message belongs; this is the principal join back to the concurrent manager's request records.
• TYPE — categorizes the message (for example, error versus informational), allowing consumers to filter only failures.
• ERROR_NUMBER — the numeric error code associated with the failure, typically an Oracle or application error.
• TEXT — the human-readable message body presented to the user or written to logs.
• TABLE_OWNER, TABLE_NAME, INDEX_OWNER, INDEX_NAME, INDEX_TEXT, INDEX_DATA — a group of attributes that capture the database object context in which the error occurred, including index metadata where relevant.
• SECURITY_GROUP_ID — the Multi-Org security group, foreign-keyed to FND_SECURITY_GROUPS.
• OBJECT_VERSION_NUMBER — the standard EBS optimistic-locking column.
• CREATED_BY and CREATION_DATE — the standard WHO audit columns recording insert identity and timestamp.

The only documented unique index, SYS_IL0000028883C00014$$, is a system-generated index on a LOB segment rather than a business-key candidate; the true business key is the surrogate primary key.

Common Use Cases and Queries

The primary use case is diagnosing concurrent program failures. A typical query retrieves all messages for a specific request:

• SELECT TYPE, ERROR_NUMBER, TEXT FROM AS_CONC_REQUEST_MESSAGES WHERE REQUEST_ID = :request_id ORDER BY CONC_REQUEST_MESSAGE_ID;
• Reporting on failure frequency, grouping by ERROR_NUMBER to identify recurring problems across many requests.
• Joining to concurrent request history to correlate error text with program name, phase, and status.
• Auditing index and table metadata captured during bulk processing errors, using TABLE_NAME and INDEX_NAME to pinpoint the failing object.

Related Objects

• FND_SECURITY_GROUPS — referenced by AS_CONC_REQUEST_MESSAGES.SECURITY_GROUP_ID, providing the Multi-Org security group definition.
• AR_CONC_REQUEST_MESSAGES — the Receivables counterpart, which references this table via CONC_REQUEST_MESSAGE_ID; this confirms the table serves as a shared message repository across EBS modules.
• FND_CONCURRENT_REQUESTS — the concurrent manager request table, joined on REQUEST_ID to obtain program, phase, and status context.
• FND_CONCURRENT_PROGRAMS — defines the executable behind each request, reached indirectly through the request row.
• FND_USER — resolves CREATED_BY to the user who triggered or logged the message.