Search Results okc_rep_bookmarks

Overview

OKC_REP_BOOKMARKS is a Contracts Core (OKC) table that implements the user-facing bookmarking feature of the Oracle E-Business Suite Contract Repository. In release 12.1.1 and 12.2.2, the repository provides a centralized work area from which contract administrators, legal users, and buyers can locate and open contracts and related documents. Bookmarks allow an individual user to flag specific repository objects — most commonly contracts, templates, or clauses — so that they can be retrieved quickly without repeating a full search. Each row therefore represents a single bookmark created by a single user against a single repository object.

The table is owned by the OKC schema and is reported as VALID in the ETRM 12.2.2 physical schema, which documents ten columns and one unique index, OKC_REP_BOOKMARKS_U1, defined over (OBJECT_TYPE, OBJECT_ID, USER_ID, BOOKMARK_TYPE_CODE). The primary key constraint is OKC_REP_BOOKMARKS_PK, defined on OBJECT_ID. From a data modeling perspective, the mined relationship structure classifies this object as satellite-leaning: it is a user-specific, descriptive extension attached to a parent repository object rather than an independent business entity or an intersection of two peer entities. The satellite classification should be treated as a modeling suggestion, since the foreign key metadata is incomplete and the table mixes a polymorphic object reference with a personalization attribute.

Key Information Stored

The column set is compact and serves three logical purposes: identifying the bookmarked object, identifying the bookmarking user, and recording descriptive and auditing attributes.

• OBJECT_ID — the primary key column (OKC_REP_BOOKMARKS_PK) and the reference to the bookmarked repository object. It is a surrogate-style identifier for the target record, not necessarily a global sequence value.
• OBJECT_TYPE — discriminates the type of object that OBJECT_ID points to, allowing the same bookmark table to serve multiple repository entity types. It is the first column of the OKC_REP_BOOKMARKS_U1 unique key.
• USER_ID — the application user who owns the bookmark; bookmarks are private to a user, not shared.
• BOOKMARK_TYPE_CODE — a lookup-backed code that categorizes the bookmark, supporting multiple bookmark semantics (for example, personal favorites versus other user-defined groupings).
• OBJECT_VERSION_NUMBER — the standard Oracle EBS optimistic locking column used by the OAF/ADF framework to detect concurrent updates.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard "WHO" audit columns maintained by Oracle Application Object Library, recording row creation and last modification context.

The business-key candidate is the composite OKC_REP_BOOKMARKS_U1 (OBJECT_TYPE, OBJECT_ID, USER_ID, BOOKMARK_TYPE_CODE), which prevents a user from creating duplicate bookmarks of the same type for the same object. The distinction between the surrogate primary key and the unique business key matters when writing deduplication checks or upsert logic.

Common Use Cases and Queries

The most frequent requirement is to list a user's saved contracts for a personal worklist or dashboard region. Because OBJECT_ID is polymorphic, the query must filter on both OBJECT_TYPE and USER_ID:

• Retrieve all bookmarks for a session user: SELECT OBJECT_TYPE, OBJECT_ID, BOOKMARK_TYPE_CODE FROM OKC_REP_BOOKMARKS WHERE USER_ID = :p_user_id ORDER BY CREATION_DATE DESC.
• Count bookmarks per contract to identify the most frequently flagged contracts: SELECT OBJECT_ID, COUNT(*) FROM OKC_REP_BOOKMARKS WHERE OBJECT_TYPE = :p_type GROUP BY OBJECT_ID.
• Detect orphaned bookmarks after a contract is deleted or archived by outer-joining to the parent contract table and selecting rows where the parent key is null.
• Audit stale personalization by comparing LAST_UPDATE_DATE against a retention window to support cleanup scripts.

Reporting against this table is generally light; it is a transactional personalization store rather than a fact table. Any extract for a data warehouse should join through OBJECT_TYPE to the appropriate parent to resolve contract numbers, since the bookmark row itself carries no descriptive business attributes.

Related Objects

Direct dependencies are defined by the documented foreign key relationships and the polymorphic design pattern rather than by a large fan-out of child tables.

• OKC_REP_CONTRACTS / OKC_K_HEADERS — the principal target when OBJECT_TYPE denotes a contract; the join is OKC_REP_BOOKMARKS.OBJECT_ID = contract header identifier.
• OKC_REP_BOOKMARKS_PK — the primary key constraint enforcing uniqueness of OBJECT_ID.
• OKC_REP_BOOKMARKS_U1 — the unique index on (OBJECT_TYPE, OBJECT_ID, USER_ID, BOOKMARK_TYPE_CODE) that enforces one bookmark per user, object, and type.
• FND_USER — resolves USER_ID to a user name for reporting and administration.
• OKC_REP_BOOKMARK_TYPES / lookup types — the reference source for BOOKMARK_TYPE_CODE values.
• OKC_BUSINESS_TYPES / OKC_REP_OBJECT_TYPES — the source of OBJECT_TYPE decoding.

Because the ETRM foreign key metadata for this table is only partially populated, integrators should confirm the exact parent table for each OBJECT_TYPE value against the seeded repository setup in the target instance before building joins.