Search Results add_burst

Overview

FND_DELIVERY is a public PL/SQL package in the APPS schema that provides the delivery-layer API for Oracle E-Business Suite concurrent processing. It is used to define and manage how the output of a concurrent request or a business event is distributed to recipients after the request completes. The package supports a broad set of delivery mechanisms including e-mail, IPP printers, fax, FTP, SFTP, HTTP, WebDAV, custom delivery routines, and bursting. It is therefore a central component in the Oracle EBS delivery infrastructure, which supplies the foundation for distributing reports, XML output, and other generated artifacts.

The package is declared with AUTHID CURRENT_USER, indicating that its SQL operations execute with the privileges of the calling schema rather than the defining schema. This is significant because it interacts with FND_VAULT, the secure credential store, and with concurrent processing metadata on behalf of the invoking agent. The package header exposes a set of typed constants that identify delivery types (for example, TYPE_EMAIL, TYPE_IPP_PRINTER, TYPE_FTP, TYPE_HTTP, TYPE_WEBDAV, TYPE_CUSTOM, and TYPE_BURST) as well as printer orientation constants for portrait and landscape output. These constants are used by callers to construct delivery actions in a consistent, type-safe manner.

Key Procedures and Functions

The documented API comprises twenty procedures and functions. The ADD_* functions register a delivery destination of a given type. ADD_EMAIL registers an e-mail recipient using subject, sender, and recipient addresses. ADD_IPP_PRINTER registers an IPP-compatible printer, available in overloaded forms that accept either a printer name or a printer identifier together with copy count, orientation, and optional credentials. ADD_FAX registers a fax destination against a named server or server identifier. The functions ADD_FTP, ADD_WEBDAV, ADD_HTTP, ADD_CUSTOM, and ADD_BURST each register the corresponding delivery channel: file transfer, WebDAV share, HTTP endpoint, customer-supplied delivery routine, and burst output respectively.

Several functions support querying the delivery configuration. HAS_LOB_OF_TYPE and HAS_DELIVERY_OF_TYPE allow callers to determine whether a delivered object contains a large object of a specific type or whether a given delivery type has been configured. POST_PROCESSING_RESULTS handles the results of a delivery operation after it has been executed.

The credential-related routines, SET_SMTP_CREDENTIALS, GET_SMTP_CREDENTIALS, SET_TEMP_CREDENTIALS, GET_TEMP_CREDENTIALS, and DEL_TEMP_CREDENTIALS, manage authentication information for delivery services. Credentials are stored through FND_VAULT, using the package constants DELIVERY_SERVICE and SMTP_SERVICE as vault service identifiers.

Tables Accessed

The package works extensively with the concurrent processing data model. FND_CONCURRENT_REQUESTS and FND_CONCURRENT_PROGRAMS identify the request and program being delivered, while FND_APPLICATION and FND_LANGUAGES supply application and language context. Delivery actions and their options are persisted in FND_CONC_PP_ACTIONS, FND_CP_DELIVERY_COMMANDS, FND_CP_DELIVERY_OPTIONS, and FND_CP_DELIVERY_OPTIONS_S. Printer configuration is read from FND_CP_IPP_PRINTERS, and post-processing behavior is resolved through FND_RUN_REQ_PP_ACTIONS. Delivered binary content is retrieved from XDO_LOBS, the XML Publisher large object table, and DUAL is used for simple PL/SQL expressions.

Usage Notes

FND_DELIVERY is not typically invoked directly from an end-user form. It is called by the concurrent manager delivery agents and by the Oracle EBS delivery framework when a concurrent request completes and its output must be distributed. Developers writing custom delivery integrations may call the ADD_* functions from PL/SQL to register additional delivery destinations programmatically, and may use the credential routines when custom transports require authenticated access. The documented metadata indicates that this package is referenced by one other package, so most runtime access occurs indirectly through the delivery framework rather than through direct application calls. The package version header reflects a 12.2-level update, making it applicable to both 12.1.1 and 12.2.2 environments.