Search Results query_parameter

Overview

APPS.CSF_PARAMS_PKG is a parameter-management utility package in the Oracle E-Business Suite, associated with the Customer Support / Field Service (CSF) schema. Its business function is to centralize access to application configuration parameters stored in the parameter tables, so that other code modules do not have to query those tables directly. The package exposes overloaded retrieval functions and a bulk retrieval procedure that return parameter values by name, together with an application-supplied default when no stored value exists. Because parameter values in EBS are frequently stored as character strings but consumed by callers as either numeric or textual values, the package provides type-specific entry points that perform the necessary conversion, insulating calling code from conversion errors and from the physical storage layout of the parameter tables.

The documented API classification is OTHER, meaning the package is treated as an internal utility rather than a public, committed interface. It is not a workflow-enabled API, and there are no subscriptions or concurrent-program registrations implied by the metadata.

Key Procedures and Functions

• QUERY_PARAMETER (numeric overload): Returns a single parameter value converted to a number. The caller supplies the parameter name and a default value. If the named parameter is found, the stored character value is converted with TO_NUMBER; otherwise the numeric default is returned. This is the entry point used when the parameter expresses a numeric setting such as a limit, count, or identifier.
• QUERY_PARAMETER (character overload): Returns a single parameter value as a VARCHAR2 string. The caller supplies the parameter name and a character default. If the parameter exists, its stored value is returned unchanged; otherwise the supplied default is returned. This overload performs no conversion and is the safer choice for free-text or code-valued parameters.
• QUERY_PARAMETERS: A procedure that retrieves all parameter values in a single pass and stores them in a PL/SQL table (the documented parameter table type, paramtab, passed as an IN OUT NOCOPY argument). This is the bulk-access path, intended for callers that need many parameters at once and wish to avoid repeated lookups.
• UPDATE_PARAMETERS: Writes parameter values back to the underlying parameter tables. It is the maintenance counterpart to the query entry points and is used to persist changed settings.
• LOCK_PARAMETERS: Acquires locks on the parameter records so that concurrent updates cannot collide. It supports the safe invocation of UPDATE_PARAMETERS in multi-user environments.

Tables Accessed

The package operates against the following objects, referenced through APPS synonyms:

• CSF_PARAMS and CSF_PARAMS_S — the primary parameter storage tables holding parameter names and values. These are the source for all query operations and the target for update operations.
• CS_TRANSACTION_TYPES — Service transaction type definitions, used to resolve parameters that are maintained at the transaction-type level.
• CS_TXN_BILLING_TYPES — Billing type definitions for service transactions, used where parameters are scoped by billing type.
• PLITBLM — the PL/SQL table of VARCHAR2 used to materialize the bulk parameter result set returned by QUERY_PARAMETERS.

Usage Notes

CSF_PARAMS_PKG is typically invoked from Oracle Forms, from other PL/SQL packages in the Customer Support modules, and from custom extensions that need to read service configuration settings. The overloaded QUERY_PARAMETER functions are called for single-value retrieval when a default must be applied, while QUERY_PARAMETERS is used where an entire parameter set is required at once. Any caller that modifies parameters should call LOCK_PARAMETERS before UPDATE_PARAMETERS to avoid concurrent update conflicts. The ETRM metadata records no dependent packages referencing this package, so its consumers are expected to be forms, reports, and bespoke code rather than other documented APIs. Because the header dates from 2004 and the package is classified as OTHER, developers should treat the interface as stable but unsupported for external integration, and should always supply meaningful defaults on the query calls to avoid null or conversion failures when a parameter is absent.