Search Results job_key

Overview

FND_OAM_CLONE_NOTIF is a table owned by the APPLSYS schema in the Oracle E-Business Suite Application Object Library (FND) product. Its documented purpose is to relate notifications to cloning jobs. In this role it functions as an associative bridge between Oracle Applications Manager (OAM) clone job records and the notification records generated during or after those jobs, allowing administrators to review which alerts were raised for which cloning operation.

Under the heuristic Data Vault classification mined from its foreign key structure, this object is modelled as a standalone entity rather than a true hub, link, or satellite. Administrators and developers should treat it as a junction-style relationship table: it carries no descriptive business payload beyond audit columns, and its identity is derived entirely from the pairing of the two referenced business keys. The documentation confirms a primary key constraint, FND_OAM_CLONE_NOTIF_PK1, defined over the composite columns JOB_KEY and NOTIFICATION_ID.

Key Information Stored

The documented physical schema for release 12.2.2 comprises seven columns. The two most significant are the composite primary key components:

• JOB_KEY — the identifier of the cloning job. Together with NOTIFICATION_ID it forms the FND_OAM_CLONE_NOTIF_PK1 primary key. This is the column most commonly requested when users search for "job_key", since it is the linkage to the OAM cloning job definition.
• NOTIFICATION_ID — the identifier of the notification record associated with the cloning job, completing the composite primary key.
• CREATED_BY — the user identifier that created the association row.
• CREATION_DATE — the date and time the row was inserted.
• LAST_UPDATED_BY — the user identifier responsible for the most recent update.
• LAST_UPDATE_DATE — the timestamp of the most recent update.
• LAST_UPDATE_LOGIN — the login identifier under which the update was performed.

No additional surrogate sequence column is documented; the composite pair JOB_KEY and NOTIFICATION_ID constitutes the natural business key and the only documented unique constraint. No standalone surrogate primary key is defined in the ETRM metadata. The five auditing columns follow the standard WHO-column convention used throughout APPLSYS tables.

Common Use Cases and Queries

The typical scenario is diagnosing clone job failures and auditing notification history. Because the table is narrow and carries no descriptive attributes, it is almost always joined to the parent cloning-job and notification tables.

• Retrieve every notification associated with a single cloning job by filtering on JOB_KEY.
• Identify which cloning jobs produced a specific notification by filtering on NOTIFICATION_ID.
• Produce an audit report of notification activity within a date range using CREATION_DATE.
• Reconcile orphaned notifications by finding NOTIFICATION_ID values with no corresponding clone job row.

A representative query pattern is:

SELECT job_key, notification_id, creation_date, last_updated_by
FROM applsys.fnd_oam_clone_notif
WHERE job_key = :p_job_key
ORDER BY creation_date DESC;

Because the composite primary key is (JOB_KEY, NOTIFICATION_ID), lookups driven by JOB_KEY benefit from the leading column of the FND_OAM_CLONE_NOTIF_PK1 index.

Related Objects

The relationship data classifies this object as standalone, so no foreign keys are documented to external tables; the linkage to cloning jobs and notifications is logical rather than enforced by a declared constraint. The following objects are the most significant points of reference:

• FND_OAM_CLONE_NOTIF_PK1 — the composite primary key unique index over JOB_KEY and NOTIFICATION_ID.
• Cloning job definition tables in the FND_OAM family — join on JOB_KEY to obtain job status, start and end times, and target details.
• Notification tables in the OAM / WF notification families — join on NOTIFICATION_ID to resolve notification subject, recipient, and delivery status.
• FND_OAM_CLONE_NOTIF audit columns — reference APPLSYS standard WHO columns and FND_USER via CREATED_BY and LAST_UPDATED_BY.

Because the schema documents no formal foreign keys, integrators must apply the JOB_KEY and NOTIFICATION_ID joins explicitly and should be prepared for orphaned rows where the parent job or notification has been purged.