Search Results sql_to_pl17




Overview
Explore in AI Chat

Overview

DPP_BPEL_UPDATEPO is an Oracle EBS Advanced Supply Chain Planning / Demand Planning (DPP) package body owned by APPS and classified under the ETRM taxonomy as OTHER. Its purpose is to broker data between the PL/SQL world and the SQL/BPEL orchestration layer that supports the Purchase Price (Purchasing Price) transactional services exposed through DPP_PURCHASEPRICE_PVT. The package implements paired conversion routines that serialize a PL/SQL record (DPP_TXN_HDR_REC_TYPE) into an object-typed SQL row (DPP_TXN) and deserialize that SQL row back into the PL/SQL record on return.

The naming convention visible in the source — PL_TO_SQL14, SQL_TO_PL14, PL_TO_SQL15, SQL_TO_PL15, and so on — reflects successive versioned generations of the same conversion contract. Each numbered pair represents a stage in an evolving interface, and the highest number (SQL_TO_PL18 / PL_TO_SQL18) typically corresponds to the current interface supported by the package in the 12.2.2 release. The header indicates this body was last modified in 2007 (dppvbudb.pls 120.3), so the 12.1.1 and 12.2.2 code lines share the same source, and behavior is consistent across both releases.

Key Procedures and Functions

All eleven documented units are conversion routines rather than business-logic procedures. They fall into two categories:

  • PL_TO_SQL14, PL_TO_SQL15, PL_TO_SQL16, PL_TO_SQL17, PL_TO_SQL18 — Functions that accept a PL/SQL transaction header record of type DPP_PURCHASEPRICE_PVT.DPP_TXN_HDR_REC_TYPE and return a DPP_PURCHASEPRICE_PVT_DPP_TXN object instance. Each function initializes the SQL object, copies field-by-field from the PL/SQL record (transaction header ID, transaction number, org ID, vendor ID, execution detail ID, provider process ID, provider process instance ID, last updated by, attribute category, and attributes 1 through 15), and returns the populated object.
  • SQL_TO_PL14, SQL_TO_PL15, SQL_TO_PL16, SQL_TO_PL17, SQL_TO_PL18 — Functions performing the inverse mapping, translating a DPP_PURCHASEPRICE_PVT_DPP_TXN SQL object back into a DPP_PURCHASEPRICE_PVT.DPP_TXN_HDR_REC_TYPE record so downstream PL/SQL consumers can act on the row in its native record form.
  • DPP_PURCHASEPRICE_PVT$UPDATE_ — The package's public entry point, which the ETRM registry exposes as the API-facing procedure for updating purchase price transaction headers.

The numbering scheme is significant: because the object type DPP_PURCHASEPRICE_PVT_DPP_TXN gained attributes across releases, each numbered pair locks in a specific attribute-set contract. Consumers must call the pair matching the version of the object type they compile against, which is why the same conversion logic is duplicated rather than overloaded.

Tables Accessed

ETRM documents one table reference for this package: PLITBLM, accessed through an APPS synonym. PLITBLM is the PL/SQL internal table utility, and its presence is consistent with the conversion routines' need to stage attribute arrays before populating the object constructor. The conversion functions also logically interact with the DPP transaction header storage underlying DPP_PURCHASEPRICE_PVT, but the ETRM metadata records no direct table DML for these functions beyond the PLITBLM reference.

Usage Notes

DPP_BPEL_UPDATEPO is not a standalone user-facing API. It is a helper layer invoked by the DPP_PURCHASEPRICE_PVT package and by BPEL business processes that exchange purchase price transaction data with EBS. The "BPEL" prefix in the package name confirms this role: the conversion routines allow BPEL callouts written in SQL/XML to construct and read DPP transaction objects without directly manipulating the PL/SQL record type. Because the package is referenced by zero other documented packages, callers reference it directly rather than inheriting it through a package dependency chain.

Customizations should call the highest-numbered pair that matches the object type version in the target instance; in 12.2.2 this is generally the SQL_TO_PL18 / PL_TO_SQL18 pair. Do not assume the numbered routines can be used interchangeably, and do not alter them, because the versions must remain synchronized with the corresponding DPP_TXN object type definition shipped by Oracle. The documented reference and the 2007 source date confirm the package is stable and unchanged between 12.1.1 and 12.2.2, so no release-specific branching is required when developing against it.