Search Results xla_security_pkg




Overview
Explore in AI Chat

Overview

The APPS.XLA_SECURITY_PKG package implements Transaction Security for Oracle Subledger Accounting (XLA) accounting events within Oracle E-Business Suite. In EBS, Transaction Security allows an installation to restrict which subledger transactions a given user or responsibility can view or query based on organization, ledger, or subledger-specific attributes. XLA serves as the central accounting engine that receives events from multiple subledgers (Payables, Receivables, Assets, Payroll, and others), converts them into journal entries, and transfers them to General Ledger. Because accounting events flow from many sources and across many operating units, XLA requires a uniform mechanism to enforce access restrictions consistently at the database level. This package provides that mechanism.

The package source header confirms its purpose explicitly: it “contains code related to implementation of ‘Transaction Security’ on accounting events.” The header also shows an evolution path. Originally created in February 2001, it was reworked in November 2002 to become a functioning package, and in February 2003 the install_security procedure and the related xla_security_policy object were removed — presumably migrated elsewhere or superseded by the standard security setup performed during installation. The package is declared AUTHID CURRENT_USER, meaning privileges are evaluated against the invoking schema rather than the defining schema, which is appropriate for a security utility that must not inadvertently bypass caller-level restrictions.

Key Procedures and Functions

The ETRM metadata documents three callable entry points, all procedures:

  • SET_SECURITY_CONTEXT (application_id) — The foundational procedure that establishes the XLA security context for a given application. It initializes the session-level environment that subsequent queries against XLA accounting events will use. It is the simpler of two overloads.
  • SET_SECURITY_CONTEXT (application_id, always_do_mo_init_flag) — An overload that extends the base procedure with a flag controlling whether Multi-Org initialization is unconditionally performed. This allows callers to force or suppress the multi-org security initialization step depending on context, avoiding redundant initialization where it has already occurred.
  • SET_SUBLEDGER_SECURITY (application_id, security_function_name) — Configures security at the subledger level. The procedure accepts the application identifier and the name of a security function (normally registered under Application Object Library) that defines the filtering rule to be applied. This is the procedure that binds a specific subledger’s transaction security function to the XLA event inquiry and reporting infrastructure.

No parameter lists beyond those shown should be assumed; the above reflects the documented signatures only.

Tables Accessed

The documented table references, resolved through APPS synonyms, indicate the package’s dependency on both Oracle EBS and database-level security infrastructure:

  • FND_APPLICATION — Used to resolve and validate the application identifier passed into the procedures.
  • FND_MO_PRODUCT_INIT — Related to Multi-Org product initialization; accessed by the overloaded set_security_context when the multi-org initialization flag is exercised.
  • DBA_POLICIES and DBA_POLICY_GROUPS — Data dictionary views exposing existing Virtual Private Database (VPD) policies, used to determine whether the relevant XLA security policy is already installed or active.
  • DBMS_RLS — The Oracle-supplied package for administering Row-Level Security policies, invoked to attach, refresh, or manage the VPD policy that enforces transaction security.
  • PLITBLM — An internal EBS package frequently used for message-, initialization-, and context-related operations within PL/SQL security routines.

Usage Notes

XLA_SECURITY_PKG is a low-level infrastructure package rather than an end-user API. It is referenced by approximately thirty other packages, which is consistent with its role as the shared entry point through which XLA-aware modules initialize their security context before querying accounting events. Typical invocation occurs from XLA inquiry forms, accounting event reports, and subledger inquiry windows, where the calling form or concurrent program first calls set_security_context and then optionally set_subledger_security to apply the appropriate policy.

Because the package is AUTHID CURRENT_USER and manipulates VPD policies at runtime, customizations should avoid calling it directly unless replicating standard EBS behavior. For support and diagnostics, the package is useful for confirming whether the XLA row-level security context was properly initialized during a session. Its presence in the ETRM registry under classification OTHER reflects its technical, non-business-API nature.