Search Results jtf_physicalmap_grp




Overview
Explore in AI Chat

Overview

JTF_PHYSICALMAP_GRP is an Oracle EBS PL/SQL group (GRP) API package owned by the APPS schema, classified as a GRP-type API within the ETRM metadata for release 12.2.2. It manages the physical mapping configuration that underpins Oracle iStore and related e-commerce mini-site (msite) functionality. Physical maps associate deliverable entities — primarily physical attachments such as collateral, brochures, or product literature — with one or more mini-sites so that the correct content is presented to the correct storefront audience. The package operates under AUTHID CURRENT_USER and exposes versioned public APIs following the standard Oracle Application Object Library (FND_API) message-handling convention, using p_api_version, p_init_msg_list, p_commit, and the corresponding x_return_status, x_msg_count, and x_msg_data output parameters. The header identifies the source as JTFGPSLS.pls, version 115.5, with an API version constant of 1.0.

Key Procedures and Functions

The package documents nine externally callable subprograms, several of which are marked as private (not exposed as the primary public interface) but remain callable within the package specification:

  • SAVE_PHYSICALMAP — Persists a collection of physical mappings for a given physical attachment and mini-site, accepting a language-code table to define localized variants. This is the principal write API for the physical map entity.
  • DELETE_PHYSICALMAP — Removes physical map records, typically used to uncouple an attachment from a mini-site or to reconfigure the map.
  • DELETE_ATTACHMENT — Deletes a physical attachment entity and its associated processing artifacts.
  • DELETE_DELIVERABLE — Removes a deliverable record linked to the physical map structure.
  • DELETE_MSITE — Deletes a mini-site definition, triggering dependent cleanup of physical map associations.
  • DELETE_MSITE_LANGUAGE — Removes a language variant associated with a mini-site, narrowing the supported locale set.
  • DELETE_ATTACHMENT_MSITE — Removes the link between a specific attachment and mini-site, effectively unpublishing content from a storefront.
  • DELETE_DLV_ALL_ALL — Removes all deliverables across all contexts. This is the procedure most commonly searched by administrators performing bulk cleanup of deliverable records associated with a mini-site or attachment. Because it operates across all anchors, it should be executed only with deliberate intent and appropriate backups, as its scope is global rather than scoped to a single mini-site or attachment.

Tables Accessed

Based on the documented metadata and the package's public synonyms, the following tables are referenced:

  • JTF_DSP_LGL_PHYS_MAP — The primary physical map table, storing the association between physical attachments and mini-sites. Inserted, updated, and deleted through the save and delete APIs.
  • JTF_DSP_LGL_PHYS_MAP_S1 — A secondary index or sequence-backed structure supporting the physical map table; used for lookups and key generation during save/delete operations.
  • JTF_MSITE_LANGUAGES — Stores the languages enabled for each mini-site; read and modified by the language-related delete procedures and by save_physicalmap's language-code handling.
  • DUAL — Used for single-row queries and PL/SQL constant evaluation.
  • PLITBLM — A PL/SQL index-by table helper for bulk operations; supports the collection-based language and ID table processing used by the APIs.

Usage Notes

JTF_PHYSICALMAP_GRP is typically invoked from Oracle iStore administrative forms, from concurrent programs that mass-maintain mini-site content, and from custom integration code that programmatically configures physical maps. It is referenced by four other packages, indicating that higher-level APIs — likely session or content-management wrappers — delegate to these procedures. When calling any procedure, always supply p_api_version => 1.0 and supply p_commit => FND_API.g_true only when the caller is prepared to commit. For DELETE_DLV_ALL_ALL specifically, the global scope demands that callers wrap the invocation in their own transaction and validation logic; because no mini-site or attachment filter is documented, the procedure cannot be constrained to a subset of deliverables, so its use is confined to controlled cleanup or reset scenarios.