Search Results ams_list_src_field_pub

Overview

The APPS.AMS_LIST_SRC_FIELD_PUB package is a public Oracle Marketing (AMS) application programming interface within Oracle E-Business Suite 12.1.1 and 12.2.2. It provides the supported programmatic interface for maintaining list source field definitions — the metadata records that describe how individual columns from external or staging sources map into the fields used by Oracle Marketing list generation. Each list source field associates a source table and column with a target column name, a column meaning, positional boundaries, an enabled indicator, and a security group, allowing list creators to build source queries from well-defined, reusable field definitions.

The package is classified as a PUB interface, meaning it is intended for direct invocation by external callers such as custom code, Oracle Forms, or concurrent programs, rather than being an internal helper package. It encapsulates the validation and persistence logic required to create, change, remove, or serialize access to these field definitions so that callers do not write directly against the underlying AMS tables.

Key Procedures and Functions

• CREATE_LIST_SRC_FIELD — Inserts a new list source field definition. The caller supplies the field attributes defined by the list_src_field_rec_type record, which carries the list source type code and identifier, the field table name, field column name, source column name and meaning, enabled flag, start and end positions, and security group identifier. The procedure applies the standard WHO columns and object version number.
• UPDATE_LIST_SRC_FIELD — Modifies an existing list source field definition identified by its primary key. The same record structure is used, with unchanged attributes expected to be passed as FND_API.G_MISS_* sentinel values. The procedure manages the audit columns and increments the object version number for optimistic locking.
• DELETE_LIST_SRC_FIELD — Removes a list source field definition. This is the procedure returned by the user search term delete_list_src_field, and it is the API-level entry point for eliminating a field mapping that is no longer required. Deletion is subject to the referential and validation rules enforced by the package.
• LOCK_LIST_SRC_FIELD — Acquires a row-level lock on an existing list source field record so that a subsequent update or delete can proceed with controlled concurrency. It is typically called before UPDATE_LIST_SRC_FIELD or DELETE_LIST_SRC_FIELD to prevent conflicting modifications.

All four procedures follow the Oracle Application Object Library API conventions: they use the FND_API.G_MISS_* constants to distinguish supplied from omitted attributes and maintain standard audit and versioning columns.

Tables Accessed

The package operates against the AMS list source field table and its supporting lookup structures through APPS synonyms. The primary table stores the list source field rows keyed by list_source_field_id, and includes the source type code, table and column names, column meaning, positional boundaries, enabled flag, and security group. Related validation references include the list source type definition, which is identified in the record by de_list_source_type_code and list_source_type_id. The document metadata does not enumerate explicit synonym names; confirmation of the physical table name should be obtained from the AMS schema definition.

Usage Notes

AMS_LIST_SRC_FIELD_PUB is intended for use wherever list source field metadata must be maintained programmatically. Typical invocation points include Oracle Marketing setup forms that manage list sources, concurrent programs that synchronize or migrate field definitions, and custom PL/SQL routines that seed list source fields during implementation or data conversion. Callers should generally invoke LOCK_LIST_SRC_FIELD before an update or delete to ensure the row is available for modification, and should check the returned API status rather than relying on unhandled exceptions. Because the package is classified as PUB and references no other custom packages, it is safe to call directly from supported extension code; nevertheless, direct DML against the underlying table bypasses the validation and audit logic the API provides.