Search Results cp_component_id




Overview
Explore in AI Chat

Overview

CS_SYSTEM_SR_LINKS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the CS (Service) product family. The view exposes the intersection of service request (SR) incidents and the customer systems to which they are linked, combining the association records held in CS_SYSTEM_SR_LINKS with descriptive and status attributes drawn from the incident and system entities. In ETRM 12.2.2 the object is documented as a VIEW with STATUS VALID.

Its primary role is to flatten a three-way relationship — incident, link, and system — into a single queryable row set, so that reporting tools, concurrent programs, and integration interfaces can retrieve incident context without writing the joins themselves. Because the view is a stored SQL definition and not a table, it carries no independent storage and always reflects the current state of its underlying sources. The ETRM documentation excerpt lists the full column inventory, which spans incident status, type, urgency, severity, ownership, resource identification, customer and account identifiers, and the configuration-management columns including CP_COMPONENT_ID, CP_COMPONENT_VERSION_ID, CP_SUBCOMPONENT_ID, CP_SUBCOMPONENT_VERSION_ID, and CP_REVISION_ID.

Underlying Base Objects

The documented view text joins three sources:

The join predicates are CS_SR_LINK.INCIDENT_ID = INCVL.INCIDENT_ID and CS_SR_LINK.SYSTEM_ID = CS_SYSTEM.SYSTEM_ID. The ETRM metadata records the referenced base objects as CS_INCIDENTS_ALL_VL (VIEW), CS_SYSTEMS_ALL_VL (SYNONYM), and CS_SYSTEM_SR_LINKS (SYNONYM). Consequently, row cardinality is driven by the link table: an incident associated with multiple systems appears multiple times, once per system.

Key Columns

INCIDENT_ID and SYSTEM_ID form the composite key of the link and are the natural join columns for downstream queries. NAME carries the system name from CS_SYSTEMS_ALL_VL. INCIDENT_STATUS_ID, INCIDENT_TYPE_ID, INCIDENT_URGENCY_ID, and INCIDENT_SEVERITY_ID provide the standard classification and triage attributes of the service request. INCIDENT_OWNER_ID and SR_CREATION_CHANNEL identify the assigned resource and the originating channel. CUSTOMER_ID, ACCOUNT_ID, and CUSTOMER_PRODUCT_ID anchor the incident to the installed-base hierarchy, while INVENTORY_ITEM_ID and INV_ORGANIZATION_ID identify the affected inventory item and its organization.

The request specifically concerns CP_SUBCOMPONENT_VERSION_ID, which is exposed alongside CP_COMPONENT_ID, CP_COMPONENT_VERSION_ID, CP_SUBCOMPONENT_ID, CP_REVISION_ID, and INV_ITEM_REVISION. These columns describe the configuration of the product recorded against the incident: the component, the component version, the subcomponent, the specific subcomponent version, and the revision. INCVL.OBJECT_VERSION_NUMBER, LAST_UPDATE_DATE, and the audit columns are also exposed, supporting incremental extraction patterns.

Common Use Cases and Queries

Typical uses include reporting incidents by system, resolving the component and subcomponent version context of a defect, and feeding data warehouse or integration extracts that require incident-to-system linkage.

Listing incidents for a given system:

SELECT incident_number, summary, incident_status_id, cp_component_id, cp_subcomponent_version_id FROM cs_system_sr_links_v WHERE system_id = :p_system_id;

Locating all incidents touching a specific subcomponent version:

SELECT incident_number, customer_id, account_id, cp_component_version_id, cp_subcomponent_version_id FROM cs_system_sr_links_v WHERE cp_subcomponent_version_id = :p_subcomponent_version_id AND incident_status_id NOT IN (SELECT incident_status_id FROM cs_incident_statuses WHERE closed_flag = 'Y');

Incremental extraction using the audit columns:

SELECT incident_id, system_id, name, incident_number, cp_component_id, cp_subcomponent_version_id, last_update_date FROM cs_system_sr_links_v WHERE last_update_date >= :p_since;

Because CS_INCIDENTS_ALL_VL and CS_SYSTEMS_ALL_VL are multi-lingual views, queries should filter on the appropriate language columns in the base objects when multilingual installations are in scope. ETRM documentation for this object is limited to the view text and column list; performance and indexing behaviour are governed by the underlying tables, and the view itself should be treated as read-only.