Search Results update_model

Overview

APPS.AMS_DMMODEL_PUB is a public PL/SQL API in the Oracle Marketing (AMS) module of Oracle E-Business Suite. Its purpose is to provide a controlled, programmatic interface for creating, maintaining, and removing data-mining models—referred to in the package as "DM models"—within the Oracle Marketing data-mining framework. The package is compiled with AUTHID CURRENT_USER, meaning that its database operations execute under the privileges of the calling session rather than the definer, which is consistent with the standard Oracle EBS public API convention that delegates authorization to the APPS schema synonyms.

The package centers on a record structure, model_rec_type, that represents the full set of attributes of a marketing data-mining model. The record includes identity and auditing columns (ROW_ID, MODEL_ID, LAST_UPDATE_DATE, CREATED_BY, OBJECT_VERSION_NUMBER), classification and status fields (MODEL_TYPE, USER_STATUS_ID, STATUS_CODE, STATUS_DATE), scheduling and expiration fields (SCHEDULED_DATE, SCHEDULED_TIMEZONE_ID, EXPIRATION_DATE, LAST_BUILD_DATE), ownership fields (OWNER_USER_ID), and tuning parameters that govern row selection such as MIN_RECORDS, MAX_RECORDS, row_selection_type, EVERY_NTH_ROW, and PCT_RANDOM. The presence of TARGET_FIELD, TARGET_TYPE, and TARGET_POSITIVE_VALUE reflects the model's predictive target configuration, while the ATTRIBUTE1 through ATTRIBUTE15 descriptive flexfield columns provide extensibility. The header history notes document several early schema revisions, including the replacement of top_down_flag by row_selection_type and the addition of custom_setup_id, country_id, and best_subtree.

Key Procedures and Functions

The ETRM metadata documents five public procedures and functions, though only four procedures are explicitly named:

• CREATE_MODEL — Inserts a new data-mining model definition into the underlying AMS tables using the attributes supplied in the model record. It is the entry point for establishing a model prior to any build or execution activity.
• UPDATE_MODEL — Modifies an existing model definition. This is the procedure most directly associated with the user search term "update_model." It is the supported mechanism for changing model attributes such as status, scheduling, target configuration, or row-selection rules without writing directly to the base tables.
• DELETE_MODEL — Removes a model definition and its associated setup data from the AMS schema.
• LOCK_MODEL — Obtains a logical lock on a model record, serializing concurrent maintenance operations so that two sessions cannot simultaneously modify the same model.

Because the ETRM excerpt does not enumerate parameter lists for these routines, callers should obtain exact signatures from the package specification in the database rather than assuming positional arguments.

Tables Accessed

The package operates against four objects exposed through APPS synonyms:

• AMS_DM_MODELS_ALL_B — The primary base table holding model definitions. CREATE_MODEL, UPDATE_MODEL, and DELETE_MODEL perform their DML here.
• AMS_DM_MODELS_ALL_B_S — The sequence used to generate surrogate primary keys, notably MODEL_ID.
• AMS_CUSTOM_SETUPS_B — The base table storing reusable custom setup definitions referenced by a model through the custom_setup_id attribute.
• DUAL — Used for singleton operations such as sequence value retrieval and validation lookups.

Usage Notes

AMS_DMModel_PUB is the sanctioned programmatic path for model maintenance in Oracle Marketing and is typically invoked from Oracle Forms-based setup and maintenance screens, from concurrent programs that schedule or refresh models, and from custom extensions that must not bypass the API layer. Direct DML against AMS_DM_MODELS_ALL_B is discouraged because the API applies locking, sequence assignment, and audit column maintenance consistently. Per the ETRM metadata, the package is referenced by zero other packages, so it functions as a standalone public surface. Developers who intend to modify a model should call UPDATE_MODEL after first obtaining the lock through LOCK_MODEL, and should populate the record type completely to avoid inadvertently clearing optional columns.