Search Results ams_listheader_pub




Overview
Explore in AI Chat

Overview

AMS_LISTHEADER_PUB is the public API package for Oracle Marketing (AMS) list header processing within Oracle E-Business Suite 12.1.1 and 12.2.2. The package body implements the business logic exposed by the corresponding AMS_LISTHEADER_PUB specification, serving as the supported entry point for creating, maintaining, validating, and copying marketing list header records held in the AMS schema. A list header represents the top-level definition of a marketing list — the grouping structure that determines how prospects, customers, or contacts are selected and subsequently used by campaign and telemarketing activities.

The package follows the standard Oracle Application Object Library (AOL) public API conventions. The PUB classification indicates that the procedures are designed for external invocation by forms, concurrent programs, other application modules, and customer extensions, whereas the actual insert, update, and validation logic is delegated to the private package AMS_LISTHEADER_PVT. The body is documented as VALID in the APPS schema and depends on FND_API and FND_MSG_PUB, confirming that it uses the standard FND_API error-handling and message-stack model, including the conventional p_init_msg_list, x_return_status, and x_msg_count/x_msg_data parameters.

Key Procedures and Functions

Six documented procedures/functions constitute the public interface:

  • CREATE_LISTHEADER — Creates a new marketing list header record. This is the primary insertion entry point, applying validation rules and defaulting logic before persisting the row through the private package.
  • UPDATE_LISTHEADER — Modifies an existing list header. Used when list attributes such as name, description, or selection criteria are changed after initial creation.
  • DELETE_LISTHEADER — Removes a list header. Deletion typically enforces referential and business restrictions, such as preventing removal of lists already consumed by campaigns.
  • LOCK_LISTHEADER — Obtains a pessimistic lock on the list header record, safeguarding against concurrent modification during an edit session.
  • VALIDATE_LISTHEADER — Performs business-rule validation against a list header without necessarily committing changes, allowing callers to surface errors before persistence.
  • COPY_LIST — Duplicates an existing list (including its header definition) to support the common marketing practice of reusing list structures for new campaigns or periods.

Parameter lists are not enumerated here; callers should reference the package specification for exact signatures and required arguments.

Tables Accessed

The ETRM metadata does not enumerate specific tables referenced by this body, though AMS list header operations act against the AMS list definition tables (such as AMS_LIST_HEADERS and related AMS_LIST_HEADERS_TL entries) via APPS synonyms. All DML is performed through the private package AMS_LISTHEADER_PVT, which encapsulates the direct table access, while AMS_LISTHEADER_PUB concentrates on API contract enforcement, message handling, and transactional control. Referential validation against parent marketing objects is handled in the private layer.

Usage Notes

AMS_LISTHEADER_PUB is referenced by three other database objects, indicating that it is consumed by higher-level marketing APIs or concurrent processing logic rather than being a leaf-level utility. Typical invocation scenarios include:

  • Oracle Marketing setup and list-definition forms, which call the API instead of performing direct DML on the AMS base tables.
  • Concurrent programs that bulk-create or copy list headers as part of campaign preparation or data migration.
  • Custom extensions and integrations that must respect the supported API surface rather than writing to AMS tables directly.

Because the package uses FND_API conventions, callers must always check x_return_status and drain the message stack via FND_MSG_PUB before proceeding, and should honour the commit/rollback semantics of the API (typically no internal commit) by controlling the transaction boundary at the calling layer.