Search Results okc_art_rels_interface_pk1

Overview

OKC_ART_RELS_INTERFACE is an interface (staging) table in the Oracle Contracts Core (OKC) module of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. It exists to capture relationships between standard clauses that originate in external systems, prior to their validation and import into the production clause relationship tables. All valid rows are promoted into OKC_ART_RELATNS_ALL by the XML Based Clause Import concurrent program. The table therefore acts as a controlled gateway that isolates external feeder data from the live contracts schema, allowing validation, error correction, and re-processing without touching production records.

The ETRM metadata classifies this object heuristically as standalone within a Data Vault modelling suggestion — it carries no enforced foreign key dependencies to other OKC tables, since it is a transient landing area whose payload is matched to production articles by title rather than by a hard referential constraint. Modellers should treat it as a staging hub for clause relationship records rather than a conventional hub, link, or satellite.

Key Information Stored

The table is documented with 18 columns; the most significant are:

• INTERFACE_ID — surrogate primary key, enforced by OKC_ART_RELS_INTERFACE_PK1. Uniquely identifies each staged relationship row.
• BATCH_NUMBER — groups rows belonging to a single import run, enabling batch-level processing, restart, and purge.
• SOURCE_ARTICLE_TITLE and TARGET_ARTICLE_TITLE — the business-key candidates that identify the two standard clauses being related. Because these are titles rather than IDs, resolution to ARTICLE_ID occurs during import.
• RELATIONSHIP_TYPE — the nature of the relationship between the two clauses (for example, related, supersedes, or references).
• ORG_ID — the operating unit under which the relationship is imported, supporting multi-org partitioning.
• ACTION — instructs the import program how to treat the row (create, update, or delete semantics).
• PROCESS_STATUS — the processing state of the row, typically used to flag pending, successful, or errored records.
• OBJECT_VERSION_NUMBER — optimistic locking column consistent with the OKC schema convention.
• Audit and concurrent program columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, PROGRAM_ID, PROGRAM_LOGIN_ID, PROGRAM_APPLICATION_ID, and REQUEST_ID.

The primary key is surrogate; the SOURCE_ARTICLE_TITLE / TARGET_ARTICLE_TITLE / ORG_ID combination functions as the practical business identifier for a relation.

Common Use Cases and Queries

The dominant use case is bulk migration of clause relationships from a legacy or external clause library. A typical workflow inserts rows into OKC_ART_RELS_INTERFACE, sets PROCESS_STATUS appropriately, and submits the XML Based Clause Import concurrent program, then queries results by BATCH_NUMBER.

Reporting and monitoring queries commonly include:

• Counting pending versus processed rows per batch: SELECT BATCH_NUMBER, PROCESS_STATUS, COUNT(*) FROM OKC_ART_RELS_INTERFACE GROUP BY BATCH_NUMBER, PROCESS_STATUS;
• Identifying errored relationships for correction, filtered on PROCESS_STATUS and ACTION.
• Auditing provenance using REQUEST_ID to link rows back to the specific concurrent request.
• Validating that source and target clause titles exist before submission, to reduce import failures.

Related Objects

• OKC_ART_RELATNS_ALL — the production table that receives all valid interface rows; the primary target of the import.
• OKC_ARTICLES_ALL (OKC_ARTICLES_B/TL) — source of the standard clauses identified by SOURCE_ARTICLE_TITLE and TARGET_ARTICLE_TITLE.
• OKC_ART_RELATNS_INTERFACE — sibling staging objects for other clause interrelationships.
• FND_CONCURRENT_REQUESTS — joined on REQUEST_ID to trace the import run.
• FND_PROGRAM / FND_APPLICATION — joined on PROGRAM_ID and PROGRAM_APPLICATION_ID for program identity.
• HR_OPERATING_UNITS / ORG tables — resolved via ORG_ID for multi-org context.

No enforcing foreign keys are documented for this table, consistent with its standalone staging classification.