Search Results wms_api_hooked_entities




Overview
Explore in AI Chat

Overview

The WMS_API_HOOKED_ENTITIES table is a configuration and extensibility metadata repository within the Warehouse Management (WMS) module of Oracle E-Business Suite. It defines the mapping between Oracle WMS application programming interfaces and customer-defined or Oracle-supplied extension packages and procedures that are "hooked" into those APIs. In practical terms, this table governs how the WMS API layer invokes substitute or supplemental logic at defined extension points, enabling organizations to customize warehouse transactions—such as receiving, putaway, picking, and shipping—without modifying Oracle-seeded code. The object resides in the WMS schema and is documented in ETRM 12.2.2 with 17 physical columns. It exists in both the 12.1.1 and 12.2.2 releases, where it remains VALID.

From a data modeling perspective, the ETRM metadata classifies this table heuristically as standalone, with no child tables depending on its primary key. As a modeling suggestion, it can be characterized as a hub-like reference entity: it anchors a set of unique module hook identifiers, with business process and module type attributes acting as descriptive satellites. Because it carries effective-dating columns and audit columns rather than transaction facts, it is not a true Data Vault satellite, but it shares characteristics with both a hub (unique hook identifier) and a reference table (descriptive context).

Key Information Stored

The table stores the definition of each hook and the code objects it activates. The documented columns of primary interest include:

The surrogate primary key is MODULE_HOOK_ID. Business-key candidates include the combination of SYSGEN_CUSTOM_PACKAGE, SYSGEN_CUSTOM_PROCEDURE, and EFFECTIVE_FROM_DATE, which together distinguish a specific hook version, though the metadata does not document a unique index on those columns.

Common Use Cases and Queries

Administrators and technical consultants query this table to audit which custom code is currently hooked into WMS APIs, to troubleshoot extension behavior, and to verify that a customization is active for a given date range. A typical query retrieves all currently active hooks for a particular business process:

SELECT h.module_hook_id,
       h.module_description,
       h.hooked_package,
       h.hooked_procedure,
       h.effective_from_date,
       h.effective_to_date
  FROM wms.wms_api_hooked_entities h
 WHERE h.business_process_id = :bp_id
   AND SYSDATE BETWEEN h.effective_from_date
                  AND NVL(h.effective_to_date, SYSDATE + 1);

Reporting use cases include generating an inventory of all hooked packages for change management, comparing effective-dating ranges across releases, and validating that no expired hook remains active. Support teams also join this table to PAY_AU_MODULE_TYPES and CS_BUSINESS_PROCESSES to resolve descriptive names for module types and business processes.

Related Objects

  • PAY_AU_MODULE_TYPES — referenced via MODULE_TYPE_ID; supplies the module type description.
  • CS_BUSINESS_PROCESSES — referenced via BUSINESS_PROCESS_ID; identifies the associated business process.
  • WMS_API_HOOKS — the parent API hook registry that this table extends with entity-level hook definitions (logical dependency).
  • FND_FORM_FUNCTIONS — commonly joined to associate hook logic with form-level invocations.
  • FND_APPLICATION — used to resolve the owning application of hooked packages.
  • WMS_API_HOOKED_ENTITIES (self-referencing) — effective-dated rows for the same logical hook may be correlated across date ranges.

Because the table is classified as standalone, no downstream foreign keys reference it directly; its significance is primarily as a lookup and configuration source for the WMS extension framework.