Search Results lookup_security_group

Overview

APPS.FND_GLOBAL is the foundational Oracle EBS server-side session context package. It exposes the runtime identity, responsibility, application, and concurrent program context that the EBS security model applies to every database session. Because the E-Business Suite uses a shared APPS schema with a single database connection pool, the database cannot rely on distinct Oracle users to identify an end user. FND_GLOBAL bridges this gap by publishing the values that Oracle Forms, concurrent managers, and self-service pages store in session-level state (notably through DBMS_APPLICATION_INFO and the FND_SESSION management logic) so that any PL/SQL program can determine who is running, under which responsibility, in which operating unit or business group, and in which language. In Oracle EBS 12.1.1 and 12.2.2 this package remains VALID in the APPS schema and is one of the most heavily referenced objects in the entire application, with the ETRM metadata recording 11,318 dependent objects. Effectively every product family—Advanced Supply Chain, Service (AHL), Financials, HRMS, and the AD patching and upgrade utilities—inherits its security and multi-org behavior from the context values FND_GLOBAL supplies.

Key Procedures and Functions

The package exposes 61 documented procedures and functions, classified in the ETRM metadata as OTHER (a utility package rather than a business API). Its accessors fall into logical groups:

• Session identity: USER_ID, USER_NAME, and LOGIN_ID return the FND_USER identity, while CONC_LOGIN_ID distinguishes the login used by a concurrent request.
• Responsibility and application context: RESP_ID, RESP_NAME, RESP_APPL_ID, APPLICATION_NAME, APPLICATION_SHORT_NAME, and SECURITY_GROUP_ID report the current responsibility, its owning application, and the security group.
• Concurrent program context: PROG_APPL_ID, CONC_PROGRAM_ID, CONC_REQUEST_ID, and CONC_PRIORITY_REQUEST identify the executing concurrent program and its request row.
• Organization and language context: PER_BUSINESS_GROUP_ID and PER_SECURITY_PROFILE_ID expose HRMS business group and security profile scoping, while LANGUAGE_COUNT, combined with the DBMS_SESSION-based NLS handling, governs the session language list.
• Formatting helpers: LOCAL_CHR, NEWLINE, and TAB provide locale-aware character and whitespace constants used when generating messages and reports.

The package also contains procedures that set the context (typically invoked by the EBS framework rather than by customer code), which write values into the session state read by the accessors above.

Tables Accessed

FND_GLOBAL reads the EBS foundation tables through APPS synonyms to validate and enrich the stored session identifiers, including FND_USER for user identity, FND_APPLICATION for application names and short names, FND_LANGUAGES for installed and session language data, FND_LOOKUP_TYPES for lookup metadata, and FND_PROFILE_OPTIONS together with FND_PROFILE_OPTION_VALUES for profile-derived settings. It queries ALL_TAB_COLUMNS for repository introspection, reads V$SESSION and V$NLS_PARAMETERS for database session and NLS state, and relies on PLITBLM for language and character utilities. Dynamic SQL is executed through DBMS_SQL, DBMS_UTILITY, and DBMS_SESSION, while DBMS_APPLICATION_INFO and DBMS_OUTPUT are used to publish and log session context. The package depends internally on FND_CONST.

Usage Notes

FND_GLOBAL is normally invoked implicitly: Oracle Forms, OAF pages, and the concurrent manager framework establish the context at session start, and downstream code simply calls the accessors. Custom PL/SQL, concurrent programs, and database triggers conventionally call FND_GLOBAL.USER_ID, RESP_ID, and RESP_APPL_ID when stamping WHO columns (CREATED_BY, LAST_UPDATED_BY) and when applying multi-org or security-group filters in SQL. Because its values are session-scoped, code that spawns a new database session—such as a Java or external connection—must explicitly re-establish context or the accessors will return null. The vast dependency footprint documented in ETRM (11,318 referencing objects) confirms that FND_GLOBAL should be treated as a stable, read-mostly platform interface: it is safe to reference from customizations, but its setter procedures should not be called outside the standard EBS initialization flow.