Search Results get_party_org_id




Overview
Explore in AI Chat

Overview

EGO_SCTX is a public PL/SQL API in the Oracle E-Business Suite Applications (APPS) schema that manages the Security Context used by the EGO (Product Information Management / Item and Catalog) family of modules. Its role is to hold and expose session-level identity attributes — the current user, the party organization, and the party person — so that EGO-based functionality, such as item catalog browsing, attribute and value security, and personalized listings, can determine which data the current session is permitted to see. The package is declared with AUTHID CURRENT_USER, meaning its unqualified references resolve according to the invoking schema's privilege context, which allows it to be called from forms, concurrent programs, and custom code while respecting the caller's security profile.

Key Procedures and Functions

The package is organized as matched setters and getters around three identity values, with additional generic context and object-tracking utilities.

  • GET_USER_ID / SET_USER_ID — Retrieve and assign the current EBS user identity held in the security context.
  • GET_PARTY_ORG_ID / SET_PARTY_ORG_ID — Retrieve and assign the party organization identifier that scopes the session to a particular operating unit or organization party. This is the entry point that corresponds to the common search term set_party_org_id.
  • GET_PARTY_PERSON_ID / SET_PARTY_PERSON_ID — Retrieve and assign the party person identifier, used when the context is anchored to an individual rather than an organization.
  • SET_CTX / GET_CTX — Store and return arbitrary named context parameters by parameter name, providing a generic extension mechanism beyond the three fixed identity attributes.
  • SET_OBJECT_NAME / GET_OBJECT_NAME — Record and return the name of the object currently being processed within the context.
  • SET_OBJECT_KEY / GET_OBJECT_KEY — Record and return the numeric key of the object currently being processed.
  • SET_SESSION_LANGUAGE — Establish the language for the session, aligning context resolution with the user's language environment.

Collectively these routines let a caller populate a complete security context once and then read individual attributes as needed, without repeatedly resolving user or party information from other sources.

Tables Accessed

EGO_SCTX references two tables through APPS synonyms: FND_LANGUAGES and PLITBLM. FND_LANGUAGES is the Oracle Applications installed-languages repository, and it is accessed in support of SET_SESSION_LANGUAGE so that the session language can be validated and applied against the set of languages actually installed. PLITBLM is a PL/SQL internal table placeholder commonly used as a work area for bulk collection processing; its presence indicates that portions of the package perform set-based or array operations rather than single-row lookups. The metadata records no other direct table dependencies, which is consistent with the package functioning primarily as a state holder for context values rather than as a data-maintenance API.

Usage Notes

EGO_SCTX is referenced by eight other packages in the ETRM repository, indicating that it is a shared infrastructure component rather than an end-user-facing API. It is typically invoked at the beginning of an EGO-related transaction or session to seed the security context: a caller sets the user, party organization, and party person, optionally sets the session language, and then downstream EGO code reads those values to constrain queries. Because the setter and getter pairs are symmetric, context values may be established once at session start and read repeatedly by many routines. The generic SET_CTX and GET_CTX entry points allow additional context parameters to be carried without modifying the package interface. Customizations and extensions should call these APIs rather than writing directly to any context store, since the package encapsulates the current-user authorization behavior and the language validation logic. When porting or upgrading between 12.1.1 and 12.2.2, the API signatures remain the documented set listed above, so dependent code requires no change.