Search Results cs_incidentlinks_pub_w

Overview

CS_INCIDENTLINKS_PUB_W is the public wrapper package for the Incident Links business object within the Oracle E-Business Suite Service (CS) module. Its principal role is to expose a stable, versioned PL/SQL interface through which external callers — forms, concurrent programs, workflows, and custom extensions — can create, modify, and maintain the relationships (links) that associate service incidents with other entities in the system. Incident links are the mechanism by which an incident is related to another incident, a customer, a product, a knowledge article, or an arbitrary object, and they underpin the "Related Items," reciprocal link, and linkage-segment functionality visible in the Service user interface.

The "_PUB_W" suffix identifies the package as a public wrapper rather than the underlying private implementation. The wrapper pattern is standard in Oracle Application Object Library development: it presents a clean, declarative signature to callers while delegating the actual validation and database manipulation to a private package. The package header carries the AUTHID CURRENT_USER declaration, so it executes with the privileges of the invoking schema, and the header comment ($Header: cswpsrls.pls) records the source file and revision history, confirming it is a shipped, non-customized Oracle object.

Key Procedures and Functions

• CREATE_INCIDENTLINK — Instantiates a link between an incident and a related object. The documentation exposes two overloaded signatures, which indicates that the procedure is designed to accept either a fully denormalized set of individual arguments or a caller-supplied primary key for the link and its related entities. Its out parameters return the standard API status triple (x_return_status, x_msg_count, x_msg_data), an x_object_version_number for optimistic locking, the newly generated x_link_id, and — where a reciprocal association is created — the x_reciprocal_link_id. The presence of p_link_type, p_link_type_id, and p_link_segment1 through p_link_segment4 shows that link classification and descriptive attributes are captured at creation time, while p_from_incident_id and p_to_incident_id support incident-to-incident relationships.
• UPDATE_INCIDENTLINK — Modifies the attributes of an existing link row. In keeping with the standard EBS API convention, it accepts the same entity-version control parameters, allowing the calling application to detect concurrent modification before the change is committed.

Both procedures follow the consistent Oracle interface contract: p_api_version for interface versioning, p_init_msg_list to control message stack initialization, p_commit to allow the caller to manage transaction boundaries, the standard FND_GLOBAL context parameters (p_resp_appl_id, p_resp_id, p_user_id, p_login_id, p_org_id), and the trailing out parameters for error reporting and versioning.

Tables Accessed

The ETRM metadata does not enumerate the base tables referenced by this package through APPS synonyms; they are reached indirectly via the private implementation body. Functionally, the package reads and writes the incident-link entity table (CS_INCIDENT_LINKS and its related link-type and link-segment definitions) together with the incident header table (CS_INCIDENTS_ALL) used to validate the incident identifiers passed in the API call. The link-type reference data ensures that only valid, enabled link relationships are created.

Usage Notes

CS_INCIDENTLINKS_PUB_W is invoked whenever an application needs to establish or amend incident associations programmatically. Typical entry points include the Service/TeleService forms that manage related-item lists, workflow background processes that auto-associate an incident with a newly created order or task, concurrent programs performing bulk link reconciliation, and customer-written PL/SQL extensions or OAF pages that must not bypass the API validation layer. Direct DML against the underlying link tables is not supported, because the package enforces attribute validation, link-type checking, reciprocal-link generation, and object-version stamping. Callers should always inspect x_return_status and, on failure, drain the message stack using FND_MSG_PUB before proceeding.