Search Results set_session_info

Overview

XLA_ENVIRONMENT_PKG is the environment-initialization utility package within the Oracle E-Business Suite Subledger Accounting (XLA) schema, owned by APPS and classified as a general-purpose (OTHER) API rather than a user-facing business API. Its principal responsibility is to establish and expose the runtime context in which Subledger Accounting processes execute. Subledger Accounting operates under multiple entry points — online form activity, concurrent program execution, and nested PL/SQL calls — and each of these contexts supplies different values for session identifiers such as login ID, concurrent program ID, concurrent request ID, application ID, and user ID. XLA_ENVIRONMENT_PKG centralizes the capture of these globals and the detection of the current execution environment so that downstream XLA packages can behave consistently regardless of how they were invoked.

The package body header identifies the original authoring date as 10-Feb-2001 and shows a header revision of 120.5, confirming the package has been part of the XLA foundation since the earliest releases of Subledger Accounting in Release 11i and carried forward unchanged in structure into 12.1.1 and 12.2.2. Because it is referenced by 123 other packages, it functions as low-level infrastructure rather than an application-level entry point.

Key Procedures and Functions

The ETRM metadata documents a single public procedure for this package:

• REFRESH — The documented public entry point. Its purpose is to re-initialize the package's cached environment state so that session globals and environment indicators reflect the current call context. This is necessary because PL/SQL package state persists for the duration of a database session; when control passes between concurrent requests, forms sessions, or nested program units within the same session, previously cached values become stale. REFRESH allows callers to force re-evaluation rather than relying on the initial initialization.

The package body additionally contains private supporting logic. A private procedure named set_login_info populates the package's global variables — login ID, program application ID, concurrent program ID, concurrent request ID, and user ID — by reading from the FND_GLOBAL package. A package-level Boolean initialization flag (g_init_flag) guards one-time initialization, and trace calls are routed through XLA_UTILITY_PKG for diagnostic output. These private elements are not callable from outside the package.

Tables Accessed

The package references the following objects through APPS synonyms:

• FND_PRODUCT_GROUPS — Used to determine the application installation context, including product group and release information needed to identify the EBS environment.
• FND_DATA_GROUPS — Used to resolve data group and responsibility/application associations that affect the current runtime environment.
• V$SESSION, V$PROCESS, V$MYSTAT — Dynamic performance views queried to identify the current database session, its operating-system process, and session-level statistics. These support environment detection and diagnostics, including distinguishing concurrent manager sessions from online sessions.
• DBMS_PIPE — Referenced for inter-session communication, typically to signal or detect environment state changes between database sessions.

The combination of FND tables and V$ views indicates the package correlates application-tier context (application, responsibility, concurrent request) with database-tier context (session and process identity).

Usage Notes

XLA_ENVIRONMENT_PKG is an internal infrastructure package. It is not exposed through a form or a standalone concurrent program; instead it is invoked as a dependency by the 123 XLA and related packages that call into it during their own initialization. Typical invocation patterns include being called at the start of Subledger Accounting concurrent programs, from Subledger Accounting Engine execution paths, and from packages that must determine whether they are running in an online or batch context before deciding how to resolve ledger, application, and session information.

Custom code should not normally call REFRESH directly unless it is itself acting as an environment boundary — for example, a custom concurrent program that invokes XLA APIs within a session that has previously executed unrelated XLA work. In such cases invoking REFRESH before calling XLA APIs ensures that cached environment variables are re-derived from the current FND_GLOBAL context. Because the package relies on session-level state, callers should be aware that stale values can persist in long-lived sessions such as those held by the concurrent manager, making explicit refresh the safest practice.