Search Results cs_sr_contacts_ext_audit_s

Overview

CS_SR_EXTATTRIBUTES_PVT is the private implementation package body for the Service Request extensible attributes framework in Oracle E-Business Oracle Service (TeleService / Customer Support). It belongs to the APPS schema and carries an API classification of PVT, meaning it is intended to be called by other service-layer packages rather than directly by end-user code. The package provides the internal PL/SQL logic that reads, validates, persists, and audits the user-defined (descriptive flexfield style) attributes associated with service requests and their contacts.

Oracle Service stores these user-defined attributes in dedicated extension tables, principally CS_INCIDENTS_EXT and CS_SR_CONTACTS_EXT. When a service request or contact is created, updated, or viewed, the attributes must be materialized for display and written back on save. CS_SR_EXTATTRIBUTES_PVT encapsulates that read/write cycle and, critically, maintains a parallel audit trail. The presence of CS_INCIDENTS_EXT_AUDIT_S and CS_SR_CONTACTS_EXT_AUDIT_S among the documented dependencies indicates that the package supports the audit shadow tables required when the E-Business Tax / attribute auditing features are enabled. The metadata confirms the package is referenced by four other packages, confirming its role as a shared internal dependency rather than a standalone entry point.

Key Procedures and Functions

The documented API surface comprises seven procedures and functions:

• GET_SR_EXT_ATTRS — Retrieves the extensible attribute values for a service request or contact, resolving attribute definitions through the EGO (Application Object Library extensibility) views and returning them for display or downstream processing.
• PROCESS_SR_EXT_ATTRS — The principal driver that coordinates the handling of a set of extensible attributes, orchestrating retrieval, validation, and persistence.
• CREATE_EXT_ATTR_AUDIT — Builds the audit records reflecting changes to extensible attributes, populating the audit tables that track before/after values.
• MERGE_EXT_ATTRS_DETAILS — Performs an upsert-style merge of attribute detail rows, inserting new attributes and updating existing ones in the extension tables.
• INSERT_SR_ROW — Inserts a service request extension row into the incidents extension table.
• INSERT_PR_ROW — Inserts a corresponding primary/contact row (SR contact extension) associated with the service request.
• POPULATE_EXT_ATTR_AUDIT_TBL — Bulk-populates the audit table structure used to record extensible attribute history.

No parameter lists are documented in the ETRM metadata, so signatures should be confirmed against the live package source.

Tables Accessed

• CS_INCIDENTS_EXT — Stores user-defined attribute values for the service request (incident) header.
• CS_SR_CONTACTS_EXT — Stores extensible attribute values at the service request contact level.
• CS_INCIDENTS_EXT_AUDIT / _S and CS_SR_CONTACTS_EXT_AUDIT / _S — Audit shadow tables and their sequences that preserve historical attribute values; these correspond directly to the searched object name cs_sr_contacts_ext_audit_s.
• CS_HZ_SR_CONTACT_POINTS — Resolves the contact points linked to a service request.
• CS_INCIDENTS_ALL_B — Base table for the service request / incident record.
• CS_LOOKUPS — Provides lookup validation values.
• DUAL and PLITBLM — Used for scalar selection and PL/SQL index-by table bulk operations.

The package also draws on EGO extensibility objects (EGO_ATTRS_V, EGO_USER_ATTRS_DATA_PUB/PVT, EGO_ATTR_GROUP_REQUEST_* ) and the FND_API, FND_MSG_PUB, and FND_LOG utilities for error handling and logging.

Usage Notes

Because this is a PVT package, it is not invoked directly by forms or concurrent programs. Instead, it is called by the public service-request APIs — notably CS_SERVICERequest_PUB and CS_SERVICERequest_UTIL, both of which appear in the dependency list. The typical flow is: a caller invokes a public API; the public API delegates attribute handling to CS_SR_EXTATTRIBUTES_PVT; the private package reads or merges values and, where auditing is enabled, writes the audit shadow rows. Customizations should therefore call the public API layer rather than this package, to preserve validation, message-stack handling, and audit integrity. Administrators troubleshooting the cs_sr_contacts_ext_audit_s sequence should note it is consumed during the audit-creation path exercised by CREATE_EXT_ATTR_AUDIT and POPULATE_EXT_ATTR_AUDIT_TBL.