Search Results bom_security_pub




Overview
Explore in AI Chat

Overview

BOM_SECURITY_PUB is a public PL/SQL package in the APPS schema that centralizes the security-checking logic used across Oracle Bills of Material (BOM) functionality. Its role is to determine whether a given application user is authorized to view, maintain, or otherwise act upon a specific bill of materials structure and the items it contains. Rather than embedding privilege logic directly inside each explosion, implosion, or copy routine, Oracle EBS exposes this logic through a single published API so that all BOM components resolve authorization consistently. In releases 12.1.1 and 12.2.2 the package is shipped as VALID and classified as a PUB API, meaning it is intended for external invocation by other EBS modules and by customer extensions. Access is resolved against Oracle Applications security grants and user definitions, so behavior honors the same role, responsibility, and grant model applied elsewhere in the E-Business Suite.

The package participates directly in the BOM dependency chain. The ETRM documentation lists it as referenced by BOM_COPY_BILL, BOM_EXPLODER_PUB, BOM_IMPLODER_PUB, and the BOM_EXPLOSIONS_ALL_V view, in addition to a recursive self-reference. This confirms that security evaluation precedes the core bill operations, and that the secured view surfaces the same privilege decisions.

Key Procedures and Functions

ETRM documents four callable entry points:

  • CHECK_USER_PRIVILEGE — Evaluates whether the current or supplied user holds the privilege required for a requested BOM security action. It is the general-purpose gate used by callers needing a user-level rather than item-level decision.
  • CHECK_ITEM_PRIVILEGE — Determines whether the user is permitted to access a specified inventory item within a BOM context. This allows item-level restriction of structures that contain sensitive or restricted components.
  • GET_EGO_USER — Returns the EGO (Oracle Product Information Management / EGO user) identity associated with the security evaluation. This maps the FND user to the identity model used by item and structure security.
  • GET_FUNCTION_NAME_TO_CHECK — Supplies the function name against which a privilege check should be performed, allowing callers to obtain the correct security function for the operation in progress rather than hard-coding it.

Parameter lists are not reproduced here; consumers should query the package specification in the target environment, as signatures can vary between patch levels.

Tables Accessed

The documented data access is through the APPS synonym FND_GRANTS. BOM_SECURITY_PUB reads FND_GRANTS, the Oracle Applications foundation table that stores grants of functions, menus, and roles to users and responsibilities. By reading grants rather than maintaining its own security tables, the package inherits the standard EBS authorization model and reflects changes to user responsibilities without additional setup. The GET_EGO_USER routine implies related resolution of the EGO user identity, and item-level checks logically depend on item and structure metadata, but only FND_GRANTS is enumerated in the documented dependency list. No write operations to business tables are documented; the package is a query-and-evaluate utility.

Usage Notes

BOM_SECURITY_PUB is invoked indirectly during ordinary BOM operations: exploding a bill, imploding where-used information, copying a bill from one organization or item to another, or querying BOM_EXPLOSIONS_ALL_V. Custom concurrent programs, forms personalizations, and extension code that manipulate bills should call the package before performing structural changes so that authorization is enforced identically to seeded behavior. Because it is a published API, direct calls are supported, but callers should treat the routines as read-only validators and should not attempt to bypass them by querying FND_GRANTS directly. Organizations upgrading from 12.1.1 to 12.2.2 should validate dependent custom code against the specification in the upgraded environment, as package bodies may be regenerated during patching. Performance is generally low-cost, since each call performs a focused grant lookup rather than a full security tree walk.