Search Results oki_refreshs




Overview
Explore in AI Chat

Overview

OKI_REFRESHS is a table in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 data model belonging to the OKI product, commonly labeled Contracts Intelligence. It stores information about the latest refresh of a summary table, meaning it acts as a control and status registry for materialized views or summary tables that are periodically rebuilt within the Contracts Intelligence reporting framework. The table records which summary object was refreshed, the concurrent request or program execution that performed the refresh, and when that refresh occurred, enabling administrators and reporting consumers to determine the currency of aggregated contracts data.

In the ETRM 12.1.1 documented schema, the object is owned by the OKI schema and contains fourteen columns. The metadata notes that this object is obsolete and is not implemented in the documented database, so its historical role is chiefly relevant to upgrade analysis, custom code remediation, and inventory of legacy Contracts Intelligence artifacts.

Regarding Data Vault classification, the mined heuristic classifies OKI_REFRESHS as standalone. As a modeling suggestion, this means the table is not modeled as a hub, link, or satellite tied into a wider integration pattern; instead it stands alone as a metadata registry whose rows are self-contained refresh events. Any Data Vault treatment would therefore be optional, likely as a satellite attached to the summarized object rather than as a central integration structure.

Key Information Stored

The column set divides into three functional groups.

A surrogate primary key is not explicitly documented in the supplied metadata; OBJECT_NAME and the request or job identifiers are the most plausible business-key candidates for uniquely identifying a refresh event, while OBJECT_VERSION_NUMBER supports transactional consistency rather than identity.

Common Use Cases and Queries

The principal use case is monitoring the currency of Contracts Intelligence summaries. A typical query joins the refresh record to the concurrent request to confirm the last successful run:

  • Select OBJECT_NAME, MV_YN, REQUEST_ID, and PROGRAM_UPDATE_DATE from OKI_REFRESHS ordered by PROGRAM_UPDATE_DATE descending, to build a freshness report for all summarized objects.
  • Filter by OBJECT_NAME to answer “when was this specific summary last rebuilt,” supporting reconciliation before financial or contractual reporting.
  • Join to FND_CONCURRENT_REQUESTS on REQUEST_ID to surface request status, phase, and completion text, distinguishing successful refreshes from failed attempts.
  • Aggregate counts by PROGRAM_ID or JOB_RUN_ID to profile refresh frequency and identify stale or repeatedly failing summary objects.
  • Include SECURITY_GROUP_ID in predicates where multi-organization or security-group partitioning applies, since the column references FND_SECURITY_GROUPS.

Because the object is marked obsolete and not implemented, these patterns are primarily diagnostic and historical rather than part of current production reporting.

Related Objects

The documented foreign key relationship is limited, and the standalone classification suggests few hard dependencies. The significant related objects are:

  • FND_SECURITY_GROUPS — referenced through OKI_REFRESHS.SECURITY_GROUP_ID, the only documented foreign key, providing security-group scoping of refresh records.
  • FND_CONCURRENT_REQUESTS — joined on REQUEST_ID to resolve request status, phase, and completion details.
  • FND_CONCURRENT_PROGRAMS — joined through PROGRAM_APPLICATION_ID and PROGRAM_ID to identify the refreshing concurrent program.
  • FND_APPLICATION — resolves PROGRAM_APPLICATION_ID to an application short name for readable reporting.
  • FND_USER — resolves CREATED_BY and LAST_UPDATED_BY to the user who initiated or amended the refresh record.
  • OKI summary and materialized view objects identified by OBJECT_NAME — the logical dependents whose freshness this table describes; these are referenced by name rather than by a declared foreign key.

No APIs or public synonyms for OKI_REFRESHS are documented in the supplied metadata, consistent with its obsolete, non-implemented status.