Search Results dbms_xdb




Overview

XDB.DBMS_XDB is an Oracle-supplied PL/SQL package owned by the XDB schema that exposes the native Oracle XML DB repository and resource API to callers within the E-Business Suite database. In the context of Oracle EBS 12.1.1 and 12.2.2, the package provides the programmatic entry point through which applications create, address, delete, secure, and lock resources stored in the XML DB repository. The repository itself is a hierarchical, path-based store that presents folders and files through a virtual file system, and DBMS_XDB is the layer that allows PL/SQL code — including EBS product code and custom extensions — to manipulate that hierarchy without direct DDL against XDB internals. Typical functional uses include provisioning folders for outbound or inbound XML document exchange, publishing generated XML files into repository paths consumed by integrations, and applying ACL-based privilege checks to repository content. The package is classified under the ETRM API classification OTHER, indicating it is a supporting infrastructure API rather than a business-document API, and it holds a VALID status at the documented release level. Its dependency footprint confirms that it is a foundational object: it references PUBLIC, XMLTYPE, STANDARD, DBMS_XDBRESOURCE, and LOCKTOKENLISTTYPE, and is itself referenced by DBMS_XDBT, DBMS_XDBUTIL_INT, DBMS_XDBZ, DBMS_XDB_CONFIG, and DBMS_XDB_REPOS.

Key Procedures and Functions

The documented interface contains 79 procedures and functions. Grouped by capability, they are as follows.

  • Resource existence and creation: EXISTSRESOURCE, CREATERESOURCE, CREATEFOLDER, ADDRESOURCE, DELETERESOURCE, LINK, and RENAMERESOURCE — these test for, create, add, remove, link, and rename repository resources and folders along repository paths.
  • Locking: LOCKRESOURCE, REFRESHLOCK, LOCKDISCOVERY, GETLOCKTOKEN, UNLOCKRESOURCE, ADDTOLOCKTOKENLIST, DELETEFROMLOCKTOKENLIST, and GETLOCKTOKENLIST — these acquire, refresh, discover, and release locks on repository resources, and manage the token lists that identify the lock holders.
  • Access control: GETACLDOCUMENT, GETPRIVILEGES, CHANGEPRIVILEGES, and CHECKPRIVILEGES — these retrieve the ACL document bound to a resource, read the privileges granted, alter those privileges, and evaluate whether a given principal holds the required privilege.
  • Configuration: SETFTPPORT — adjusts the FTP listener port associated with the XML DB protocol configuration.

Parameter lists are intentionally omitted; only the documented purpose of each unit is described above. Callers should consult the Oracle XML DB documentation for the exact signatures corresponding to their database release.

Tables Accessed

ETRM records that the package operates against XMLTYPE, DBMS_ASSERT, DBMS_LOB, and DUAL as referenced through APPS synonyms. XMLTYPE is both a data type and the repository's underlying storage abstraction, and it is the object against which resource creation, retrieval, and ACL documents are expressed. DBMS_LOB supplies large-object manipulation primitives used when resource content is read or written in pieces. DBMS_ASSERT provides identifier and SQL-text validation used to defend against SQL injection when repository paths and names are assembled into dynamic statements. DUAL serves conventional single-row PL/SQL evaluation needs. The package also interacts with DBMS_XDBRESOURCE for lower-level resource operations, reflecting the layered nature of the XML DB repository stack.

Usage Notes

DBMS_XDB is invoked from PL/SQL — typically from custom concurrent programs, database triggers, integration wrappers, or OAF/Forms-backed server-side logic — rather than being surfaced directly as an end-user form. Because it manipulates the shared XML DB repository, callers should treat repository paths as a global namespace, avoid hard-coded path collisions, and scope ACL changes narrowly. Locking calls should be paired so that LOCKRESOURCE is always followed by UNLOCKRESOURCE in exception handlers to prevent orphaned locks. Privilege checks such as CHECKPRIVILEGES should precede writes to protected repository locations. Given its infrastructure role, DBMS_XDB should not be modified, and EBS patches may refresh dependent packages such as DBMS_XDB_REPOS and DBMS_XDB_CONFIG; custom code should therefore rely only on documented entry points and revalidate after patching. Execution privileges are granted through PUBLIC in the dependency metadata, but operational use in EBS is normally restricted via schema and role design rather than by the package grant alone.