Search Results csfw_servicerequest_pub_w




Overview

The APPS.CSFW_SERVICEREQUEST_PUB_W package is a public wrapper specification within the Oracle E-Business Suite service request (CSF) module. It provides a controlled, supported interface through which external callers—forms, concurrent programs, and custom PL/SQL code—can perform write operations against the service request data model without directly manipulating the underlying base tables. The package is declared with AUTHID CURRENT_USER, meaning that its procedures execute with the privileges of the invoking schema rather than those of the owning APPS schema. This design preserves the security model of EBS while still exposing the packaged business logic to authorized callers.

The package is part of the broader Service Request Management framework (often associated with the Foundation and Service Request functionality), and represents one of the supported public entry points for updating an existing service request or incident record. Its presence in the ETRM repository classifies it as an OTHER API, indicating it is a supported interface but not one of the flagship "PL/SQL APIs" with the full standard validation stack. The header comment $Header: csfwvsrs.pls 120.2 2009/02/11 ... syenduri ship $ confirms the specification has been stable since the 12.1.x code line.

Key Procedures and Functions

The documented specification exposes a single procedure:

  • UPDATE_REQUEST_RESOLUTION — Updates the resolution-related attributes of a service request identified by incident ID. Its purpose is to record the resolution code, resolution summary, problem code, and customer PO number against an existing incident, and to optionally commit the transaction. The signature includes parameters for the incident identifier, resolution code, resolution summary, problem code, customer PO number, commit and initialization flags, plus a set of standard EBS API OUT parameters (x_return_status, x_msg_count, x_msg_data) that follow the common PL/SQL API error-handling convention. An p_object_version_number parameter provides optimistic locking to detect concurrent updates, and an p_incident_severity_id parameter (defaulted to null) was added to support an enhancement delivered in the FSTP 12.1.3 project.

No functions are documented in the specification; the package contains only this single procedure.

Tables Accessed

The ETRM metadata does not explicitly enumerate the base tables referenced by this package, and no APPS synonyms are documented as directly referenced. Functionally, UPDATE_REQUEST_RESOLUTION operates against the service request / incident resolution data model, which in the CSF schema is centered on the incident and service request tables. The procedure writes resolution code, resolution summary, problem code, customer PO number, and severity to the incident record, so it necessarily updates the relevant incident detail table and, when p_commit is set, issues a commit. Because the specification is a wrapper, the physical DML is performed by the implementation body, which is not exposed in the specification metadata. Callers should consult the package body for the authoritative table list.

Usage Notes

CSFW_SERVICEREQUEST_PUB_W is invoked whenever an application or integration needs to programmatically close or annotate a service request with resolution information. Typical callers include the Service Request forms (when a user records a resolution during service request closure), concurrent programs that perform bulk resolution updates, and custom code or external integrations that must update incidents through a supported API rather than direct SQL. The presence of p_commit and p_init_msg_list permits use both as a self-contained transaction and as part of a larger transaction controlled by the caller. Because the package is AUTHID CURRENT_USER, callers must possess the necessary object and table privileges under their own schema; the wrapper does not escalate privileges. The standard OUT parameters must always be inspected: a caller should check x_return_status for FND_API.G_RET_STS_SUCCESS (or the equivalent constant used by this package) and, on error, retrieve messages via x_msg_count and x_msg_data. The p_object_version_number must be passed with the current version to prevent lost updates. No other packages are documented as referencing this wrapper, so it is an independently callable public interface.