Search Results transaction_type_validity

Overview

EGO_Globals is a lightweight session-state package in the Oracle E-Business Suite Applications (APPS) schema, delivered as part of the EGO (product information management / item and catalog) module family. Its package body, sourced from EGOSGLBB.pls and created initially in September 2002, exposes a small set of setter and getter routines that maintain a package-level record named G_System_Information. This record caches contextual values — language code, user ID, and business object identifier — so that other EGO packages can read consistent session attributes without repeatedly querying the database or FND profile facilities.

The package is classified as OTHER in the ETRM repository for 12.2.2 and is owned by APPS. It holds no business rules of its own; it is a shared memory container used to pass runtime context between cooperating PL/SQL units.

Key Procedures and Functions

Six documented program units make up the public surface of EGO_Globals:

• SET_LANGUAGE_CODE — assigns the supplied language code into the G_System_Information record, establishing the language context for the session.
• GET_LANGUAGE_CODE — returns the language code currently held in G_System_Information.
• SET_USER_ID — the routine most relevant to the "set_user_id" search; it stores the supplied user ID in G_System_Information.user_id. This is the canonical entry point for publishing the current FND user identity to the EGO package suite.
• GET_USER_ID — returns the user_id attribute previously set, typically by SET_USER_ID.
• GET_BO_IDENTIFIER — retrieves the business object identifier held in the global record, used by catalog and item-related logic to resolve the active business object context.
• TRANSACTION_TYPE_VALIDITY — a validity-check routine associated with transaction type handling within the EGO globals context.

Tables Accessed

The documented metadata lists no base tables referenced through APPS synonyms. EGO_Globals operates entirely against in-memory PL/SQL state — the G_System_Information record — rather than performing SQL against EGO or FND tables. Values such as the user ID and language code are supplied by the caller, generally after the caller has already read them from FND profiles or session utilities, and are cached here for downstream consumers.

Usage Notes

EGO_Globals is referenced by seven other packages in the EBS codebase, which is consistent with its role as a shared globals holder. Typical invocation patterns include:

• A calling package or concurrent program first invokes SET_USER_ID and SET_LANGUAGE_CODE to seed the global record at the start of its processing, then downstream EGO routines call GET_USER_ID and GET_LANGUAGE_CODE to obtain the current identity and language without further queries.
• Because state is held in package variables, values persist only for the life of the database session; they must be re-established in each new session, and callers in pooled or shared environments should not assume the record reflects the intended user without an explicit SET_USER_ID call.
• Custom code extending EGO functionality should call SET_USER_ID after switching effective user context (for example, after FND_GLOBAL.APPS_INITIALIZE) so that EGO routines record the correct user in audit and business object operations.

The package has changed little since its original creation; its header revision remains at version 120.1, indicating a stable, foundational utility whose primary value lies in the SET_USER_ID / GET_USER_ID pair and the associated language and business object accessors.