Search Results ams_cnt_point_pvt_w




Overview
Explore in AI Chat

Overview

AMS_CNT_POINT_PVT_W is the private API package body for contact point processing within the Oracle E-Business Suite Marketing (AMS) module. Contact points represent the various communication channels and addresses associated with a customer or prospect, such as phone numbers, email addresses, fax numbers, and web addresses. The "_PVT_W" suffix indicates this is a wrapper implementation of the private (PVT) package API, employed by Oracle's Rosetta design pattern to provide validation, defaulting, and processing logic invoked internally by the public contact point APIs and their surrounding forms and concurrent programs.

The package operates within the APPS schema and is classified as an OTHER API object. It encapsulates the business rules governing the creation, modification, and validation of contact points, ensuring that data entered through the Oracle Marketing and Trading Community Architecture (TCA) interfaces conforms to expected formats, required attribute combinations, and referential constraints. Because it is a private package, it is not intended for direct invocation by customer extensions; it is called by the public contact point API layer.

Key Procedures and Functions

The package body exposes seven documented procedures and functions that collectively implement contact point lifecycle processing:

  • CREATE_CNT_POINT — Inserts a new contact point record, applying defaulting rules and deriving attributes before the row is persisted.
  • UPDATE_CNT_POINT — Modifies an existing contact point, revalidating changed attributes against the same business rules applied at creation.
  • VALIDATE_CNT_POINT — Performs validation of a single contact point entity, checking required fields and format constraints prior to DML.
  • VALIDATE_CNT_POINT_REC — Validates a contact point record structure, typically invoked as part of multi-record processing to ensure each entry in a collection is well formed.
  • CHECK_CNT_POINT_ITEMS — Examines the individual data items that comprise a contact point, verifying inter-dependent attribute conditions and item-level correctness.
  • ROSETTA_TABLE_COPY_IN_P3 — Copies PL/SQL table (index-by table) structures from the caller's format into the internal Rosetta format on input, supporting the API's table-based (bulk) interface.
  • ROSETTA_TABLE_COPY_OUT_P3 — Copies table structures from the internal Rosetta format back to the caller's expected format on output, returning results of bulk operations.

The Rosetta table copy routines indicate that this package participates in Oracle's standard API bulk-processing convention, allowing arrays of contact points to be validated and processed in a single call. The validation and processing routines depend on the FND_API utility package for standardized return status, message handling, and error management.

Tables Accessed

The documented dependency information shows the package body references the PLITBLM table (via an APPS synonym), which is the standard Oracle PL/SQL table management table used by the Rosetta infrastructure to hold and manipulate index-by table data during API processing. In addition, the package references several JTF collection types — JTF_DATE_TABLE, JTF_NUMBER_TABLE, JTF_VARCHAR2_TABLE_100, JTF_VARCHAR2_TABLE_200, and JTF_VARCHAR2_TABLE_300 — which are PL/SQL table datatypes used to pass contact point attribute arrays into and out of the API. The private package is also layered over the AMS_CNT_POINT_PVT package, from which it inherits core implementation logic, and it depends on FND_API for API framework services.

Usage Notes

AMS_CNT_POINT_PVT_W is not referenced by any other database object per the ETRM metadata, and as a private wrapper it is normally invoked indirectly rather than directly. In Oracle EBS 12.1.1 and 12.2.2 it is exercised when contact points are created or maintained through Oracle Marketing and TCA-related forms, when contact point data is imported or interfaced via concurrent programs, and when the public contact point APIs are called from custom code. Because it is classified as a private package and documented as unreferenced, developers should treat it as internal implementation and should call the corresponding public AMS contact point API instead of this wrapper whenever programmatic integration is required.