Search Results as_utility

Overview

AS_UTILITY_PUB is a public utility API owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. The package header (asxputls.pls, version 120.1, dated 05-JUN-2005) identifies it as a "public utility API developed from Sales Core group." It was originally created on 11-AUG-1999 as AS_UTILITY and was subsequently updated on 09-SEP-1999 to change to the JTF_PLSQL_API standard, reflecting the broader migration of Sales-family PL/SQL APIs toward the JTF (Oracle CRM Technology Foundation) PL/SQL API framework.

The package exists to supply common validation and messaging infrastructure to the Sales Core family of APIs. It defines the four canonical validation levels used across that API family: item level, record level, inter-record (table) level, and inter-entity level. Item level validates an individual attribute; record level checks missing-field and cross-field dependencies; inter-record level checks cross-record dependencies within a table; and inter-entity level performs cross-entity validation for multi-instance child entities, where execution order depends on business logic. The header explicitly notes that public APIs must perform full validation on all data passed to them, and therefore no validation levels are defined for public APIs; the p_validation_level parameter belongs to private APIs, which retain greater flexibility.

In the ETRM 12.2.2 metadata, AS_UTILITY_PUB is classified as a PUB API and is referenced by 60 other packages, confirming its role as foundational shared code rather than an end-user-facing business process.

Key Procedures and Functions

The documented API surface of AS_UTILITY_PUB consists of a single public program:

• GET_MESSAGES — The sole documented procedure or function in the package. Consistent with the package's stated purpose as utility infrastructure, GET_MESSAGES provides message retrieval capability, allowing calling code to obtain messages associated with an API invocation. It supports the messaging and error-reporting conventions expected of the JTF_PLSQL_API framework, under which the package was standardized in 1999. No parameter list is documented in the available metadata and none should be assumed.

The package also exposes four public constants corresponding to the validation levels described in the header: G_VALID_LEVEL_ITEM, G_VALID_LEVEL_RECORD, G_VALID_LEVEL_INTER_RECORD, and G_VALID_LEVEL_INTER_ENTITY. These constants are part of the package specification and are used by calling APIs to signal the desired depth of validation when private validation routines are invoked.

Tables Accessed

The ETRM metadata documents no tables referenced by AS_UTILITY_PUB via APPS synonyms. This is consistent with a pure utility package whose responsibilities are validation semantics, constant definitions, and message handling rather than direct persistence. Any data access performed on behalf of callers is handled by the calling APIs themselves; AS_UTILITY_PUB operates on data structures passed to it rather than querying or mutating base tables directly.

Usage Notes

AS_UTILITY_PUB is not intended for direct invocation by end users, Oracle Forms, or concurrent programs. It is a programmatic dependency consumed by other PL/SQL APIs in the Sales Core and related JTF-based stacks. The metadata records that 60 other packages reference it, which indicates that it is invoked indirectly throughout the Sales order, quotation, and related CRM processing paths whenever those packages require shared validation-level constants or standardized message retrieval through GET_MESSAGES.

Custom code that extends or integrates with Sales Core APIs may reference AS_UTILITY_PUB for the validation-level constants, but such use should be approached with care given the package's age and its 2005-vintage header. Because the package is declared AUTHID CURRENT_USER, privileges are resolved according to the invoking schema rather than the definer, which is a relevant consideration when granting execution rights to custom database users in 12.1.1 or 12.2.2 environments. Implementers should treat the documented GET_MESSAGES program and the four validation-level constants as the stable public contract of this package.