Search Results dom_doc_publish_hist

Overview

The DOM_DOC_PUBLISH_HIST table resides in the DOM schema, which supports the Document Management and Collaboration (DOM) module of Oracle E-Business Suite. As its name and documented description indicate, this table stores document publish history — a persistent audit of each instance in which a document revision and version within a repository was published, typically through a publishing template and concurrent request. It captures the output artifact, the target repository and location, and the user and timestamp associated with the publish action. This makes it a transactional record of publishing events rather than a master definition table for documents or versions themselves.

Under a heuristic Data Vault classification mined from the foreign-key structure, this table is assessed as standalone. In Data Vault modeling terms, it behaves most like a satellite or event/transaction record: its grain is a single publish event keyed by the combination of document, revision, version, and publish identifiers, and it carries descriptive and auditable attributes (file name, date, user, location) around that event. There is no documented hub-to-hub link role; the only modeled foreign key is a reference to VEA_VERSIONS. Analysts designing a vault-style model should treat this as an event satellite attached to the version/document business keys.

Key Information Stored

The table contains 18 documented columns. The unique index DOM_DOC_PUBLISH_HIST_U1 establishes the business-key candidate as the composite of DOCUMENT_ID, REVISION_ID, VERSION_ID, and PUBLISH_ID — together these identify a distinct publish event for a specific document revision and version. The metadata does not document a separate single-column surrogate primary key, so this composite should be regarded as the effective identity of a row.

• DOCUMENT_ID — identifies the published document (business-key candidate).
• REVISION_ID — the revision of the document involved (business-key candidate).
• VERSION_ID — the version published; also a foreign key to VEA_VERSIONS (business-key candidate).
• PUBLISH_ID — the publish operation identifier completing the unique key (business-key candidate).
• TEMPLATE_CODE and PUBLISH_TEMPLATE_ID — the template controlling how the document was rendered on publish.
• PUBLISHED_FILE_NAME — the file name of the generated output.
• PUBLISH_DATE — the date the document was published; the primary event timestamp.
• PUBLISHED_BY — the user who executed the publish.
• REPOSITORY_ID and PUBLISH_LOCATION — where the published output was written.
• OUTPUT_FORMAT_ID — the format of the published file.
• CONCURRENT_REQUEST_ID — links the publish to the concurrent program request that generated it.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard Oracle EBS audit columns tracking row creation and modification.

Common Use Cases and Queries

Typical uses center on auditing and reporting publish activity: identifying which versions of a document were published, when, by whom, and to which repository. Support and audit staff use it to trace a published file back to its source version, and to correlate publish output with the concurrent request responsible for it.

Sample query patterns include:

• List all publishes for a document, ordered most recent first: SELECT DOCUMENT_ID, VERSION_ID, PUBLISHED_FILE_NAME, PUBLISH_DATE, PUBLISHED_BY FROM DOM.DOM_DOC_PUBLISH_HIST WHERE DOCUMENT_ID = :doc_id ORDER BY PUBLISH_DATE DESC;
• Find publishes attributable to a concurrent request: WHERE CONCURRENT_REQUEST_ID = :request_id;
• Report publishing volume by user or repository within a date range using PUBLISH_DATE, PUBLISHED_BY, and REPOSITORY_ID.

Related Objects

The documented metadata records a single foreign-key relationship; supplementary DOM relationships are noted for completeness.

• VEA_VERSIONS — referenced via DOM_DOC_PUBLISH_HIST.VERSION_ID; the authoritative source for version metadata.
• Documents / revisions objects (e.g., DOM/DOC document and revision tables) — joined on DOCUMENT_ID and REVISION_ID to resolve document and revision context.
• Concurrent request / FND tables — joined on CONCURRENT_REQUEST_ID to obtain request status and completion details.
• Repository definition objects — joined on REPOSITORY_ID to resolve the target repository.
• Publishing template definitions — joined on PUBLISH_TEMPLATE_ID or TEMPLATE_CODE to resolve rendering templates.
• Output format lookup objects — joined on OUTPUT_FORMAT_ID to resolve the published file format.

Collectively these relationships allow the publish history to be reconstructed into a complete audit trail covering document, version, template, location, format, and requesting user.