Search Results fs_svc_prefix




Overview

FND_WEBFILE is a foundational Oracle E-Business Suite utility package responsible for resolving and registering the web-accessible URLs of files produced by concurrent programs and generic services. In the 12.1.1 and 12.2.2 releases, its primary role is to translate an internal concurrent request identifier into a fully qualified HTTP location that a browser or external application can retrieve. This is the mechanism that allows the Oracle EBS framework to expose concurrent request log files, output files, and ad hoc temporary files to users through the Applications framework rather than through the file system directly.

The package also maintains the descriptive metadata stored in the FND_FILE_TEMP staging table, recording which node, directory, and transfer protocol a given file is served from. Several of its internal routines are declared with PRAGMA AUTONOMOUS_TRANSACTION specifically so that bookkeeping updates and commits do not interfere with the calling transaction that originates a file. The package is referenced by five other EBS packages, confirming that URL resolution for temporary output is a shared service consumed widely across the application tier.

Key Procedures and Functions

  • GET_URL — The principal public function. It accepts a file identifier and constructs the full service URL used to retrieve a concurrent request or temporary file. During execution it updates the page and transfer bookkeeping associated with the file before returning the address to the caller.
  • GET_REQ_LOG_URLS — Returns the request log URLs associated with a concurrent request, allowing callers to obtain the location of log output without knowing the underlying node or directory layout.
  • CREATE_ID — Generates and returns a new identifier for a temporary file entry, providing the key under which subsequent URL resolution and metadata updates are performed.
  • SET_DEBUG — Controls the package-level debug flag, enabling diagnostic output when tracing URL construction or file registration issues.

Internally the package body also defines GENERIC_ERROR, UPDATE_SVC, UPDATE_CFG_INFO, and UPDATE_PAGE_INFO. The latter three are autonomous-transaction routines that write node names, context file information, destination services, transfer types, page numbers, and page sizes into FND_FILE_TEMP. These are implementation details rather than supported entry points but explain how the documented functions persist their results.

Tables Accessed

FND_FILE_TEMP is the central working table, holding the file identifier, node name, destination node, destination file, transfer type, page number, and page size that together describe where and how a temporary file is served. FND_CONCURRENT_REQUESTS, FND_CONCURRENT_PROGRAMS, and FND_CONCURRENT_PROCESSES supply the request and program context needed to associate files with their originating concurrent job. FND_CONC_REQ_OUTPUTS and FND_CONC_PP_ACTIONS relate to request output and post-processing actions. FND_NODES and FND_OAM_CONTEXT_FILES identify the application tier node and the context file configuration that determine the web service address. FND_APPLICATION and FND_APPL_TOPS resolve the application short name and its configured base path, which are required to build the correct URL prefix. The FND_NODES and FND_APPL_TOPS data are also what effectively establish the file-serving service prefix (fs_svc_prefix) used to compose returned URLs.

Usage Notes

FND_WEBFILE is normally invoked indirectly. Concurrent manager infrastructure, the Oracle Applications Framework, and OAM-based file-serving features call GET_URL and GET_REQ_LOG_URLS when presenting log or output links to end users. Custom code that programmatically needs the URL of a generated file should call these documented functions rather than compose paths manually, because the package abstracts the node, context, and transfer-type logic. Debug tracing can be enabled through SET_DEBUG during troubleshooting. Because its update procedures run as autonomous transactions, callers should not expect the metadata writes to be controlled by their own commit or rollback scope.