Search Results fnd_function




Overview
Explore in AI Chat

Overview

The APPS.FND_FUNCTION package body provides the runtime and maintenance engine for Oracle E-Business Suite function security. In the EBS layered security model, a "function" is the atomic unit of authorization: a form, subfunction, JSP, or non-form executable that can be granted to a responsibility. FND_FUNCTION is responsible for compiling the function grants held by responsibilities and menus into a flattened, denormalized cache held in FND_COMPILED_MENU_FUNCTIONS. That compiled cache is what the runtime menu and function-security checks consult, so this package effectively determines whether a given user, acting under a given responsibility, may invoke a given function.

In Oracle EBS 12.1.1 and 12.2.2, the object is shipped in the APPS schema with status VALID. It is a high-fan-in utility: the ETRM metadata records that APPS.FND_FUNCTION is referenced by 103 other packages, while it is not itself referenced by any database object. It is classified as OTHER in the API taxonomy — an internal framework package rather than a supported public API, and therefore one that should generally not be called directly by customizations.

Key Procedures and Functions

The ETRM documentation lists 18 procedures and functions, all centered on compilation, marking, and validation of function security data:

  • COMPILE — the core compilation routine, converting function and menu grant rows into compiled menu function entries.
  • COMPILE_ALL_MARKED, COMPILE_ALL_FROM_SCRATCH, COMPILE_CHANGES — bulk compilation variants that process marked responsibilities, rebuild the entire cache, or process only changed definitions, respectively.
  • COMPILE_MENU, COMPILE_MENU_MARKED — menu-scoped compilation, including the marked subset.
  • FAST_COMPILE — an optimized compilation path used when only limited changes require recompilation.
  • MARK_MENU, MARK_ALL, QUEUE_MARK, ADD_QUEUED_MARKS — marking routines that flag menus, responsibilities, or individual grants as requiring recompilation, optionally queued for later batch processing.
  • IS_FUNCTION_ON_MENU — a validation check determining whether a function is present on a given menu.
  • AVAILABILITY — establishes availability of the compiled function data for runtime use.
  • GET_FUNCTION_ID — retrieves the identifier for a named function.
  • TEST, TEST_ID, TEST_INSTANCE, TEST_ID_SLOW — diagnostics that verify whether a function, function ID, or function within an instance is accessible.

Tables Accessed

The package reads the definitional security tables and writes the compiled cache:

  • FND_FORM_FUNCTIONS — the master definition of functions and their parameters.
  • FND_MENUS and FND_MENU_ENTRIES — menu definitions and the function/submenu entries they contain.
  • FND_RESPONSIBILITY and FND_RESP_FUNCTIONS — responsibilities and the functions excluded from their menus.
  • FND_COMPILED_MENU_FUNCTIONS — the principal compiled output consumed at runtime.
  • FND_DATA_SECURITY — integrated for security group and data-filtering behavior.
  • DBMS_LOCK, V$INSTANCE, PLITBLM — used for concurrency control, instance identification, and low-level character/collation handling.

Utility dependencies include FND_PROFILE, FND_GLOBAL, FND_MESSAGE, FND_LOG, FND_FILE, and FND_JOBS_PKG, supporting profile lookups, session context, messaging, logging, file output, and background job submission.

Usage Notes

Typical invocation is indirect. The standard path is the Function Security compilation step performed from the System Administrator responsibility (Compile Security), backed by concurrent programs that call COMPILE_ALL_MARKED or COMPILE_ALL_FROM_SCRATCH. When a function, menu, or responsibility grant changes, the framework marks the affected rows via the MARK_* procedures and compiles them on the next run. The TEST* procedures are diagnostic, useful for confirming that a function resolves for a user or responsibility. Because the package is internal framework code and maintains its own locking and batch behavior, custom code should rely on supported interfaces and concurrent compilation rather than calling these procedures directly.