Search Results xml_transfer

Overview

GR_XML_REPORTS is a PL/SQL package body owned by APPS that supports XML-based reporting within the Oracle EBS Process Manufacturing / Quality (Oracle Quality, GR) product family. Its primary business purpose is to generate structured XML output for dispatch history information, allowing users to extract, transfer, and downstream-process data related to dispatched materials, recipients, document categories, and item/ingredient details. The package leverages Oracle's built-in XML generation utilities — DBMS_XMLGEN for query-to-XML conversion and DBMS_LOB for handling large character objects — to assemble report data into CLOB structures suitable for consumption by reporting tools, external systems, or file-based interfaces.

The package is classified as "OTHER" in ETRM, meaning it is not a public, fully-supported API but rather an internal utility called from reporting infrastructure. It is not referenced by any other documented packages, indicating it functions as a leaf-level reporting component rather than a shared library.

Key Procedures and Functions

The package exposes two documented procedures:

• DISPATCH_HISTORY_REPORT — The principal reporting procedure. It accepts an error buffer and return code (standard concurrent program OUT parameters) along with a set of filter criteria such as organization, item range, recipient range, document category range, date sent range, CAS number, and ingredient item. It constructs a dynamic SQL query against the dispatch history view and passes that query to DBMS_XMLGEN to produce an XML result set. The date parameters are converted from canonical (character) format to Oracle DATE using FND_DATE.CANONICAL_TO_DATE before being incorporated into the query. The procedure supports flexible range filtering, applying AND conditions conditionally depending on which parameters are supplied, and includes an ORDER BY parameter for output sequencing.
• XML_TRANSFER — A supporting procedure whose name indicates its role in transferring or writing the generated XML content. It is associated with the XML output lifecycle initiated by DISPATCH_HISTORY_REPORT, presumably moving the CLOB result to a target location (file, staging table, or interface).

No parameter lists are documented beyond what appears in the excerpt for DISPATCH_HISTORY_REPORT; XML_TRANSFER's exact signature is not reproduced in the available metadata.

Tables Accessed

The package references the following objects (via APPS synonyms):

• DBMS_XMLGEN — Oracle's built-in package used to convert a SQL query (passed as a VARCHAR2 handle) into an XML document. The ctxhandle and CLOB result types declared in the procedure (l_queryctx, l_xml_result) are derived from this package.
• DBMS_LOB — Oracle's built-in large object utility, used to manipulate the CLOB that holds the generated XML.

The dynamic query embedded in DISPATCH_HISTORY_REPORT also reads from GR_DISPATCH_HISTORY_V (the dispatch history view) and FND_DOCUMENT_CATEGORIES_VL (the document categories view), joined via an outer join on document category name. However, these are accessed through dynamic SQL embedded in a string rather than through direct static references, so they may not appear in the ETRM "tables referenced" list.

Usage Notes

GR_XML_REPORTS is typically invoked in one of three ways:

• As the underlying implementation of a concurrent program — the standard errbuf/retcode OUT parameters on DISPATCH_HISTORY_REPORT strongly indicate it is registered as a concurrent program executable (likely a PL/SQL stored procedure) that users submit with filter parameters through the Submit Requests form.
• From a Reports or XML Publisher integration layer, where the generated CLOB is consumed as an XML data source for formatted output.
• From custom code, where developers require programmatic access to dispatch history in XML form — though because the package is classified as OTHER and unsupported, direct invocation is discouraged for production extensions.

The "xml_transfer" search term that led to this object reflects the package's role in the XML generation and transfer pipeline. Because the dynamic SQL concatenates user-supplied filter values directly into the query string, the procedure is susceptible to SQL injection if invoked with untrusted input, a consideration relevant to any custom wrapper that calls it. In 12.1.1 and 12.2.2, the package remains an APPS-owned object with no cross-package dependencies, making it self-contained but tightly bound to the GR dispatch history data model.