Search Results delete_physicalmap

Overview

The APPS.JTF_PHYSICALMAP_GRP_W package is a generated PL/SQL wrapper that exposes the business logic of the JTF_PHYSICALMAP_GRP package through a table-based, bulk-processing interface. It belongs to the JTF (Java Technology Foundation) schema family, which underpins shared CRM and self-service infrastructure in Oracle E-Business Suite. The "_W" suffix denotes the wrapper layer produced by Oracle's Rosetta code-generation framework, which adapts scalar and record-based PL/SQL APIs to the collection (table) types required by Java-based middle-tier and BC4J (Business Components for Java) clients.

The package is declared with AUTHID CURRENT_USER, meaning that privileges are evaluated against the invoking schema rather than the APPS owner. Its source header records the last substantive revision as version 115.6 (2004), indicating a stable, long-lived component carried forward into EBS 12.1.1 and 12.2.2. The business function centers on maintaining "physical map" definitions—configurations that associate language and site attributes with attachments for a multi-site, multi-language deployment—and on the corresponding delete operations.

Key Procedures and Functions

The package exposes twelve documented procedures, which divide into three functional groups.

• Rosetta table-copy utilities — ROSETTA_TABLE_COPY_IN_P0, ROSETTA_TABLE_COPY_OUT_P0, ROSETTA_TABLE_COPY_IN_P2, ROSETTA_TABLE_COPY_OUT_P2, ROSETTA_TABLE_COPY_IN_P3, ROSETTA_TABLE_COPY_OUT_P3, ROSETTA_TABLE_COPY_IN_P4, and ROSETTA_TABLE_COPY_OUT_P4. These mechanically marshal data between JDBC-style JTF_VARCHAR2_TABLE_100/JTF_NUMBER_TABLE collections and the strongly typed collection types defined in JTF_PHYSICALMAP_GRP (language codes, site/language pairs, legal physical map IDs, and msite IDs). They are generated plumbing, not business logic, and are rarely called directly.
• save_physicalmap — The creation/update entry point. Overloaded forms accept an attachment identifier, a site identifier, and language-code collections, persisting the physical map and its related attribute rows within a single API call. Standard EBS API parameters (p_api_version, p_init_msg_list, p_commit, and the x_return_status/x_msg_count/x_msg_data out parameters) govern transaction control and error reporting.
• delete_physicalmap — The procedure matching the user's search term. It accepts the standard API control parameters plus a collection of legal physical map identifiers (p_lgl_phys_map_id_tbl), enabling bulk deletion of physical map records in one invocation. DELETE_ATTACHMENT_MSITE provides the companion removal of attachment-to-site associations.

Tables Accessed

The only documented table reference is the APPS synonym PLITBLM. This is the JTF persistent storage for language/site attribute mappings associated with physical map definitions. The package reads and writes this table to materialize the collections passed in by callers and to remove rows during delete operations.

Usage Notes

Because the package is referenced by zero other packages, it is a leaf-level API invoked from outside the PL/SQL dependency chain—typically by Java/BC4J middle-tier code, OAF or Forms-based CRM configuration screens, or custom integration code performing bulk maintenance of physical map data. The delete_physicalmap procedure is the standard programmatic route for removing one or many physical map entries; callers should supply a populated JTF_NUMBER_TABLE of map IDs, pass p_commit according to their transaction strategy, and inspect x_return_status for FND_API.G_RET_STS_ERROR/UNEXPECTED_ERROR before committing. In 12.2.2 the same signatures and behavior apply, with no documented online-patching changes.