Search Results eng_invoke_eco_bo




Overview
Explore in AI Chat

Overview

ENG_INVOKE_ECO_BO is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It functions as a business object (BO) wrapper and message-handling layer for Engineering Change Order (ECO) processing within Oracle Engineering. Its principal public entry point, PROCESS_ECO, orchestrates the invocation of ECO-related business logic that ultimately delegates to the Engineering Change Order public API, ENG_ECO_PUB, and, where routing or bill of material operations are implicated, to the BOM business object and routing public APIs (BOM_BO_PUB and BOM_RTG_PUB).

The package also embeds a generic message-handling framework, allowing callers to accumulate, retrieve, and inspect messages generated during ECO processing without aborting execution. This design supports batch and programmatic ECO updates where collecting diagnostics across multiple records is preferable to failing on the first error. The package is classified as a standalone API (API classification OTHER), and the ETRM metadata records no other packages as depending on it, indicating it is consumed by forms, concurrent programs, or custom code rather than by other PL/SQL APIs.

Key Procedures and Functions

  • PROCESS_ECO — The primary business procedure. It drives the ECO processing workflow, invoking the dependent ECO and BOM business logic and recording outcomes through the package's message framework.
  • INITIALIZE — Establishes the package's internal state before a processing run, preparing the message structures used throughout the session.
  • RESET — Clears the package state and message collections so the package can be reused cleanly within the same database session.
  • APPS_INITIALIZE — The standard Oracle Applications initialization routine used to establish the correct application and session context for APPS-schema APIs.
  • GET_MESSAGE_LIST — Returns the complete collection of messages accumulated during processing.
  • GET_ENTITY_MESSAGE — Retrieves messages associated with a specific entity, enabling targeted diagnostics for individual ECO records.
  • GET_MESSAGE — Returns a single message, typically by position, from the message collection.
  • GET_MESSAGE_COUNT — Returns the number of messages currently held, allowing callers to test for errors or warnings.
  • DELETE_MESSAGE — Removes a message from the collection, supporting selective message management.
  • DUMP_MESSAGE_LIST — Outputs the full message list, useful for debugging or logging during batch execution.

These twelve documented procedures constitute the package's complete public surface. No parameter lists are documented in the available metadata and are therefore not reproduced here.

Tables Accessed

The ETRM metadata for this package documents no direct table references through APPS synonyms. Its data access is indirect: ECO records, change order lines, and related engineering data are read and written through the dependent public APIs — ENG_ECO_PUB, BOM_BO_PUB, and BOM_RTG_PUB — which encapsulate the underlying Engineering and Bills of Material tables. This encapsulation is deliberate, ensuring that all ECO manipulation passes through supported API logic, including validation, workflow hooks, and audit handling rather than direct DML.

Usage Notes

ENG_INVOKE_ECO_BO is intended for programmatic invocation. Typical callers initialize package state with INITIALIZE (or APPS_INITIALIZE for session context), invoke PROCESS_ECO to perform the required ECO action, then inspect results using GET_MESSAGE_COUNT and GET_MESSAGE_LIST or GET_ENTITY_MESSAGE before deciding whether to commit or roll back. RESET should be called between processing cycles within the same session.

Because the package is referenced by no other PL/SQL API, it is generally called from Oracle Forms-based ECO entry points, concurrent programs that mass-process engineering changes, or custom integration code in Oracle EBS 12.1.1 and 12.2.2. The message framework makes it particularly suitable for batch scenarios where per-record diagnostics must be captured and reported rather than raised as exceptions.