Search Results ams_import_list_pvt




Overview

APPS.AMS_IMPORT_LIST_PVT is a private (PVT-classified) PL/SQL package within the Oracle E-Business Suite Marketing (AMS) application schema. It provides the internal implementation layer that supports the import list feature of Oracle Marketing, allowing organizations to create and manage marketing import lists that group and stage external contact or account records prior to campaign execution. An import list in Oracle Marketing serves as a staging container: records from external sources are loaded into the import interface and consolidated into a named import list, which is subsequently used to seed a target group or campaign audience.

The package operates strictly as a supporting engine for the public API package AMS_IMPORT_LIST_PUB. As a private package, its procedures are not intended for direct invocation by external consumers; instead, the public package wraps and sequences its calls to enforce API-level validation and error handling. The documented dependency graph confirms this relationship: AMS_IMPORT_LIST_PVT references AMS_IMP_LIST_HEADERS_ALL and the FND_API error-handling facility, and is itself referenced by AMS_IMPORT_LIST_PUB and its corresponding private wrapper AMS_IMPORT_LIST_PVT_W.

Key Procedures and Functions

The ETRM documentation records nine procedures and functions in this package:

  • CREATE_IMPORT_LIST — Creates a new import list header record, establishing the list definition used to consolidate imported records.
  • UPDATE_IMPORT_LIST — Modifies the attributes of an existing import list, such as its name, description, or associated status.
  • DELETE_IMPORT_LIST — Removes an import list and its associated definitional data.
  • LOCK_IMPORT_LIST — Acquires a lock on the import list record to protect it from concurrent modification during processing.
  • VALIDATE_IMPORT_LIST — Validates the import list against business rules before commit or use, ensuring required attributes and consistent state.
  • VALIDATE_AMS_IMPORT_REC — Validates an individual import record within the list context, checking required fields and referential integrity.
  • CHECK_AMS_IMPORT_ITEMS — Examines the imported items belonging to a list, typically to verify that content exists and is eligible for further processing.
  • DUPLICATE_IMPORT_LIST — Creates a copy of an existing import list, useful for reusing list definitions across similar campaigns.
  • DO_RECURRING — Handles recurring import list behavior, supporting periodic refresh of list membership from the source interface.

Parameter signatures are not documented in the ETRM metadata and should be confirmed against the deployed package specification.

Tables Accessed

Through APPS synonyms, the package interacts with the following tables:

  • AMS_IMP_LIST_HEADERS_ALL — The primary base table holding import list header definitions; read and written during create, update, delete, and lock operations.
  • AMS_IMP_LIST_HEADERS_ALL_S — A secure-view or shadow object associated with the header table, used to enforce organization or security-based access.
  • AMS_IMP_DOCUMENTS — Stores document associations for import lists, referenced when validating list content.
  • AMS_USER_STATUSES_B — Supplies user-defined status values applied to list records.
  • AS_IMPORT_INTERFACE_S — The import interface table from which staged records are drawn into the list.
  • DUAL — Used for scalar evaluations and utility calls.

Usage Notes

AMS_IMPORT_LIST_PVT is invoked indirectly through the public API AMS_IMPORT_LIST_PUB and its wrapper AMS_IMPORT_LIST_PVT_W. In standard configurations, the Oracle Marketing application forms and the import list concurrent programs drive these calls; the concurrent processing path loads interface records, invokes validation, and creates or refreshes the list header. Custom code should call the public package rather than the private package, since the private layer bypasses the FND_API savepoint and message-stack conventions that the public layer enforces. Where direct access is unavoidable, developers must still route through FND_API for consistent error propagation. Because the package is classified private, its signatures may change between releases, including between 12.1.1 and 12.2.2, and code should not be bound to them.