Search Results validate_dm_model_rec

Overview

APPS.AMS_DM_MODEL_PVT_W is the published wrapper package for the Oracle Advanced Marketing (AMS) Direct Marketing model private API, AMS_DM_MODEL_PVT. It exposes the model maintenance operations of the Direct Marketing module to external callers through the standard EBS "Pvt_W" wrapper pattern, in which thin public procedures delegate to a private implementation package that holds the core business logic. The package is defined with AUTHID CURRENT_USER, so all database object references resolve under the privileges of the invoking session rather than the package owner, a convention that allows the AMS schema objects to be accessed safely from both the application schema and custom code granted execute on the wrapper.

The object is classified as OTHER in the ETRM repository rather than as a formal public API, meaning it is primarily an internal plumbing layer used by the Direct Marketing user interface and its supporting infrastructure. The supplied source header ($Header: amswdmms.pls 115.7 2002/11/16) confirms the package has been stable since the 11i era and is carried forward unchanged into EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

The documented surface consists of eight procedures. Several serve as internal plumbing rather than business operations:

• ROSETTA_TABLE_COPY_IN_P3 — converts the flat, parallel JTF_NUMBER_TABLE, JTF_DATE_TABLE, and JTF_VARCHAR2_TABLE_* collections passed in from the caller into the strongly typed ams_dm_model_pvt.dm_model_tbl_type record table used internally by the private package.
• ROSETTA_TABLE_COPY_OUT_P3 — performs the inverse transformation, unpacking the internal dm_model_tbl_type back into the parallel JTF collections for return to the caller.
• CHECK_DM_MODEL_ITEMS — the routine targeted by the search term "check_dm_model_items". It validates the list of items (offers, products, or related model lines) associated with a direct marketing model, verifying that the item set supplied is consistent and complete before the model record is persisted.
• CREATE_DM_MODEL — creates a new direct marketing model record from the supplied model table data.
• UPDATE_DM_MODEL — applies changes to an existing model record, including its associated item lines.
• VALIDATE_DM_MODEL_REC — validates a single model record, checking required attributes and referential consistency.
• VALIDATE_DM_MODEL — performs whole-model validation, typically orchestrating record-level checks across the model and its items.
• COPY_MODEL — duplicates an existing model, including its item definitions, to support model versioning and template-style reuse.

Tables Accessed

The only table documented as referenced through APPS synonyms is PLITBLM. Within the Rosetta/JTF bulk-collection architecture, PLITBLM is the interface table that carries incoming or outgoing row data for the collection-based calls. The wrapper reads from and writes to this table as part of the copy-in/copy-out cycle, allowing the private package to consume set-based input. Persistent AMS direct marketing model data is written by the private package AMS_DM_MODEL_PVT into the AMS DM model tables; the wrapper itself does not expose those base tables directly.

Usage Notes

AMS_DM_MODEL_PVT_W is invoked indirectly. The Direct Marketing model setup forms and the concurrent programs that build and refresh models call the private package, which in turn is surfaced through this wrapper for external consumption. Because the wrapper is AUTHID CURRENT_USER and is not referenced by any other documented package, customizations should call it directly rather than relying on inter-package propagation: the caller must hold EXECUTE on the wrapper and appropriate privileges on PLITBLM and the underlying AMS objects. Typical customization scenarios include bulk creation of models, programmatic cloning of an existing model via COPY_MODEL, and pre-persistence validation of item lists through CHECK_DM_MODEL_ITEMS. Callers must supply data in the exact positional JTF collection order declared in the specification; a mismatch in the 55 positional arguments is the most common failure mode.