Search Results lock_scoreresult

Overview

AMS_SCORERESULT_PUB is a public PL/SQL API within the Oracle EBS Advanced Marketing (AMS) module, delivered under the APPS schema with AUTHID CURRENT_USER. It provides the programmatic interface for managing rows in the marketing score result data model — the records that store the outcome produced when a scoring model built in Oracle Marketing is applied to a database segment or tree node. Each score result ties a scored entity (represented through tree_node) to a score identifier and captures the computed response value and confidence level produced by the scoring engine.

The package is classified as a PUB API, meaning its procedures form the supported, externally callable surface intended for use by Oracle application forms, concurrent programs, and customer extensions. The header comment shows the package was created in January 2001 and was revised in February 2001 to rename model_score_id to score_id and in January 2002 to remove the security group identifier, reflecting the multi-organization security simplification applied across AMS at that release. The $Header$ revision string (115.3) confirms the package has remained stable since that time and is carried forward essentially unchanged into EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

The documented API surface consists of four procedures, all concerned with the lifecycle of a single score result row:

• CREATE_SCORERESULT — Inserts a new score result record, populating the identifiers, score reference, tree node, and scoring output attributes passed by the caller.
• UPDATE_SCORERESULT — Modifies the mutable attributes of an existing score result, such as the response or confidence value, using the standard WHO columns and object_version_number for optimistic locking.
• DELETE_SCORERESULT — Removes a score result record. This is the procedure most commonly associated with the "delete_scoreresult" search term, and it is the supported mechanism for programmatically purging a score result without direct DML against the underlying table.
• LOCK_SCORERESULT — Acquires a row-level lock on the score result so that a caller can safely read and then update the record within a single transaction, avoiding lost updates in concurrent processing.

The metadata records five procedures or functions in total; the fifth is an internal helper that is not part of the documented public contract. The package also declares the record type scoreresult_rec_type, an automatically generated structure mirroring every column of the score result table, with each attribute initialized to the corresponding FND_API.G_MISS_* sentinel. Callers populate only the attributes they intend to change and leave the remainder at their G_MISS defaults, which is the standard pattern for attribute-level API processing in AMS.

Tables Accessed

• AMS_DM_SCORE_RESULTS — The primary transactional table holding score result rows. It is the insert, update, and delete target of the API and the source for the record type definition.
• AMS_DM_SCORE_RESULTS_S — The corresponding DDL sequence used to generate the score_result_id primary key on create.
• DUAL — Used for single-row computations, typically sequence selection or validation checks during API execution.

Usage Notes

AMS_SCORERESULT_PUB is invoked whenever application logic must maintain score results through a supported interface. Oracle Marketing scoring concurrent programs call it when a scoring run produces output for a segment; the score result maintenance forms in the marketing responsibility use the same API so that business rules and WHO auditing are applied consistently. The package is not referenced by any other documented database package, so external calls are limited to forms, concurrent programs, and customer-developed code.

The constant G_DEFAULT_NUM_REC_FETCH (30) indicates that related retrieval routines in the AMS scoring layer fetch results in batches of thirty records. Because the package executes with AUTHID CURRENT_USER, callers require direct grants on the API and on the AMS tables; access is normally obtained through the APPS schema or a custom schema with explicit privileges. The removal of the security group identifier in the 2002 revision means releases from 11i onward do not require a security group parameter, and any legacy customization referencing it must be adjusted accordingly.