Search Results rlm_inbound_sv




Overview
Explore in AI Chat

Overview

The APPS.RLM_INBOUND_SV package is a server-side PL/SQL service component belonging to the Oracle EBS Release Management / EDI Gateway architecture. As stated in the package header, its description is "Contains EDI Gateway transaction processor for the inbound demand." This package therefore serves as the processor that accepts inbound demand data delivered through the EDI Gateway and maps it into the Oracle application interface structures for subsequent import.

The package is owned by APPS and is classified as an "OTHER" API type in the ETRM 12.2.2 metadata. The current source header indicates version 120.1 with a build date of 2005/07/17, reflecting a long-standing object that has been progressively enhanced. Notably, the source comments record a MOAC (Multi-Org Access Control) enhancement that introduced the p_org_id parameter, and a timezone enhancement (referenced as "4316744: Timezone uptake") that added a new procedure for horizon date maintenance. These annotations confirm the package has been maintained to support multi-organization operating unit security and scheduling horizon accuracy across 12.1.1 and 12.2.2.

Key Procedures and Functions

The documented public interface of the package comprises three callable units:

  • PROCESS_INBOUND — The principal entry point and the object targeted by the "process_inbound" search. It is the EDI Gateway transaction processor for inbound demand. It accepts parameters governing the run, including an error buffer, return code, operating unit, file path and name, transaction type, map identifier, debug mode, an import flag, warning control options, child process count, and data file character set. It performs the mapping and population of the demand interface tables and can optionally trigger the downstream import.
  • GetCountInterfaceHeaderId — A function that derives the number of schedules based on the request ID. It accepts an x_request_id and returns a numeric count of interface header records associated with that concurrent request. This supports process control and scheduling logic.
  • UpdateHorizonDates — Added under the timezone uptake enhancement. It accepts a p_run_id and updates the horizon dates associated with the run, ensuring that scheduling horizons are calculated correctly under the session's timezone.

The ETRM documented procedure list separately records a unit named "NAME," which corresponds to an internal helper used for identification or naming within the package body.

Tables Accessed

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

  • ECE_MAPPINGS — The EDI Gateway mapping repository. It supplies the mapping definitions used to translate the inbound demand file into the interface structures based on the supplied map identifier.
  • RLM_INTERFACE_HEADERS_ALL — The multi-organization enabled interface header table. It stores the inbound demand header records after mapping, including organization-specific attributes.
  • RLM_INTERFACE_HEADERS — The interface header view or base table used for header-level processing and retrieval of run and schedule information.
  • PLITBLM — The standard PL/SQL table of strings used for passing and buffering collections of data during the inbound processing, typically for staging mapped values.

No other packages reference this package per the ETRM metadata, indicating it is an execution endpoint rather than a shared service library.

Usage Notes

RLM_INBOUND_SV is invoked as a concurrent program from the EDI Gateway / Release Management menu. The PROCESS_INBOUND procedure is the executable entry point registered for the concurrent program, with parameters supplied for organization, file location, transaction type, map, and debug settings. It may also be called from custom PL/SQL code that needs to trigger inbound demand processing programmatically. The p_run_import parameter allows the caller to control whether the mapping step and the downstream import are executed together or separately. Because of the MOAC p_org_id parameter, callers must supply the correct operating unit context to prevent cross-organization data visibility issues. The p_child_processes and p_debug_mode parameters facilitate parallel processing and diagnostics in high-volume environments.