Search Results g_execute_api_callouts

Overview

HZ_UTILITY_V2PUB is a public PL/SQL utility package in the Oracle E-Business Suite Trading Community Architecture (TCA) schema, owned by APPS. It provides the shared validation and instrumentation primitives that the TCA V2 public APIs (for parties, contacts, accounts, sites, and relationships) rely upon for consistent input checking and diagnostics. Rather than embedding common validation logic in each of the individual entity APIs, Oracle centralized this logic here, allowing the roughly 280 other packages that reference HZ_UTILITY_V2PUB to reuse the same routines. The package conforms to the TCA V2 API standard, which requires that every public API expose a return status out parameter (typically x_return_status) and a message list through FND_MSG_PUB. In Oracle EBS 12.1.1 and 12.2.2 the package is present in the APPS schema and is invoked both by Oracle-delivered code and by customer extensions that call TCA APIs programmatically.

Key Procedures and Functions

The documented interface contains 54 procedures and functions. The validation procedures form the core:

• VALIDATE_MANDATORY — checks that a required column carries a value. It is overloaded for VARCHAR2, NUMBER, and DATE column types, and honors a create/update flag so that a column may be optional on update but mandatory on create.
• VALIDATE_NONUPDATEABLE — enforces that a column which must never change after creation is not modified during an update.
• VALIDATE_START_END_DATE — verifies that a start date precedes its associated end date.
• VALIDATE_CANNOT_UPDATE_TO_NULL — prevents an existing populated column from being cleared during an update.
• VALIDATE_LOOKUP — confirms that a supplied value exists in the relevant lookup.

A second group supports debugging and diagnostics: ENABLE_DEBUG, DISABLE_DEBUG, DEBUG, and DEBUG_RETURN_MESSAGES. The last of these, the object associated with the search term, writes the contents of the API message stack to the debug log, allowing developers to trace which validation failed during an API call. The remaining documented functions are standard TCA WHO-column accessors — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, APPLICATION_ID, and PROGRAM_UPDATE_DATE — which populate and read audit and concurrent-program context. GET_SESSION_PROCESS_ID returns the session process identifier used when logging.

Tables Accessed

The package reads and writes the following tables through APPS synonyms:

• FND_LANGUAGES and FND_LOOKUP_VALUES — for language and lookup validation performed by VALIDATE_LOOKUP.
• HZ_CODE_ASSIGNMENTS, HZ_ORIG_SYSTEMS_B, and HZ_RELATIONSHIP_TYPES — reference data used to validate classification codes, originating systems, and relationship types.
• HZ_CONTACT_POINTS, HZ_CONTACT_PREFERENCES, HZ_ORG_CONTACT_ROLES, HZ_ORGANIZATION_PROFILES — contact and organization profile data checked against TCA rules.
• HZ_CUST_ACCT_SITES, HZ_CUST_SITE_USES, HZ_PARTY_SITES, and HZ_PARTY_SITE_USES — customer account and party site records.
• HZ_DNB_REQUEST_LOG — the DUNS/Data Universal Numbering System request log.
• SO_LOOKUPS — the legacy Order Management lookup view used for certain value validation.

Usage Notes

HZ_UTILITY_V2PUB is not exposed through a forms window or a standalone concurrent program. It is invoked from within other PL/SQL packages, including the TCA V2 public APIs, and therefore runs under whichever execution context the caller uses — an Oracle Forms session, a concurrent program, or custom code. Because validation procedures write to the API message stack rather than raising exceptions, a caller that receives REPORT_FAILURE or unexpected status should call DEBUG_RETURN_MESSAGES (after ENABLE_DEBUG), or retrieve FND_MSG_PUB.G_MSG_DATA, to obtain the failing-message text. Debugging via G_EXECUTE_API_CALLOUTS is controlled through the HZ_EXECUTE_API_CALLOUTS profile option, which governs whether API callout logic is executed. When extending TCA functionality in 12.1.1 or 12.2.2, custom code should reuse these validation routines rather than duplicating mandatory and non-updateable checks, ensuring consistent message generation and audit-column population across the TCA schema.