Search Results wsh_itm_post_process_handler




Overview
Explore in AI Chat

Overview

The APPS.WSH_ITM_POST_PROCESS_HANDLER package is a PL/SQL database object owned by the APPS schema in Oracle E-Business Suite. It forms part of the Oracle Shipping Execution (WSH) module, specifically the In-Transit Inventory Management (ITM) framework. Its principal business function is to orchestrate post-processing logic that must execute after the primary transactional processing of in-transit inventory movement messages has completed. Within the shipping and receiving flow, in-transit inventory requests are generated and subsequently processed asynchronously; the WSH_ITM_POST_PROCESS_HANDLER package serves as a centralized handler invoked once the core movement logic finishes, allowing both standard application behavior and customer-specific extensions to run at that point.

The package holds a VALID status in the ETRM repository for both 12.1.1 and 12.2.2, confirming its continued role across these releases. Its API classification is recorded as OTHER, indicating it is an internally oriented utility package rather than a public, formally supported integration interface. The object is documented with two primary entry points and a small footprint of referenced tables, reflecting a tightly scoped responsibility focused on completion, validation, and custom extension of ITM processing.

Key Procedures and Functions

The ETRM metadata documents three program units within this package. Two are named as follows:

  • CALL_CUSTOM_API — This procedure provides the extension hook mechanism for the package. Its purpose is to invoke customer-defined or custom PL/SQL logic at the appropriate point in the post-processing sequence. By centralizing the call to a custom API, Oracle enables organizations to add site-specific business rules, validations, or downstream integrations without modifying standard code. This is the mechanism through which customizations are registered and executed during ITM post-processing.
  • CHECK_PENDING_CALL_API — This procedure performs a status or readiness check related to the pending custom API call. Its purpose is to determine whether a custom API invocation is outstanding or required before post-processing proceeds. This gating behavior ensures the custom extension is not skipped and that processing state is consistent prior to advancing the handler logic.

The metadata reports three documented procedures or functions in total; the two above are named within the ETRM content, with the third represented as an internal or supporting program unit. Consistent with the documentation, no parameter signatures are inferred here.

Tables Accessed

The package references the following underlying database objects through APPS synonyms:

  • WSH_ITM_REQUEST_CONTROL — A control and state-tracking table central to the in-transit inventory request lifecycle. The post-processing handler reads and/or updates this table to ascertain processing status and to coordinate the pending call logic performed by CHECK_PENDING_CALL_API.
  • FND_APPLICATION — The Oracle Application Object Library registry of installed applications. The package consults this table to resolve application context and identifiers used when invoking custom APIs or validating application-related configuration.
  • UTL_FILE — The Oracle-supplied PL/SQL file I/O package, listed among referenced objects. Its presence indicates the handler may produce diagnostic or log output to a file, or otherwise interact with the operating system file system during post-processing.

Usage Notes

This package is not typically invoked directly from Oracle Forms or by end users. It is an internal handler within the WSH ITM asynchronous processing chain. The dependency information shows it is referenced by APPS.WSH_ITM_ASYN_MSGMAP_ASSISTANT, which drives the mapping and dispatch of asynchronous in-transit inventory messages, and it is also referenced by itself, confirming internal recursion or shared internal program units.

Customization is achieved through the documented custom API hook. The CALL_CUSTOM_API and CHECK_PENDING_CALL_API procedures exist so that implementers can plug in site-specific logic during post-processing without altering Oracle-owned code, and so the framework can verify whether such a pending call remains. Invocation therefore occurs automatically as part of the standard ITM flow, and organizations extending it should ensure any custom API registered for the handler respects the expected state of WSH_ITM_REQUEST_CONTROL and is idempotent against repeated or re-driven message processing.