Search Results lock_ct_rule

Overview

APPS.AMS_CT_RULE_PUB is a public PL/SQL API package within the Oracle EBS Advanced Marketing (AMS) module, specifically belonging to the Campaign and Telemarketing / Contact Targeting (CT) rule framework. Its classification as a PUB package indicates that it is designed for external consumption by other application modules, forms, concurrent programs, and customer extensions, rather than being an internal private package. The package governs the lifecycle of content rule records — configuration rows that determine how outbound communications (such as emails, cover letters, and responses) are assembled and delivered when a contact targeting or campaign activity is executed.

Functionally, AMS_CT_RULE_PUB exposes the standard CRUD-style operations plus an explicit locking routine for content rule entities. Content rules in Oracle Marketing control attributes such as the sender, reply-to address, cover letter, table-of-contents flag, trigger code, and subject line that apply to a given object (for example a campaign, event, or telemarketing list). Because these rules are shared configuration objects, the package provides concurrency-safe creation, maintenance, and deletion so that multiple users or background processes cannot corrupt rule data.

Key Procedures and Functions

• CREATE_CT_RULE — Inserts a new content rule record. Callers supply the rule attributes defined in the ct_rule_rec_type record, including object_type, object_id, sender, reply_to, cover_letter_id, table_of_content_flag, trigger_code, and subject. The routine handles surrogate key generation (content_rule_id) and populates the standard WHO columns (created_by, creation_date, last_updated_by, last_updated_date, last_update_login) and object_version_number.
• UPDATE_CT_RULE — Modifies an existing content rule. It relies on object_version_number to enforce optimistic locking, rejecting updates when the persisted version does not match the value passed in by the caller, thereby preventing lost updates during concurrent maintenance.
• DELETE_CT_RULE — Removes a content rule record. Deletion is typically validated against dependent configuration before the row is physically removed from the underlying AMS content rule table.
• LOCK_CT_RULE — Acquires a lock on a specific content rule row so that a caller can serialize modifications across sessions. This is the routine most directly associated with the user search term lock_ct_rule. It is generally invoked prior to an update or delete to guarantee that the record is not being concurrently altered, and it corresponds to the conventional SELECT ... FOR UPDATE pattern encapsulated behind the public API surface.

All four procedures return status via the standard FND_API message and exception conventions, using attributes such as FND_API.G_MISS_NUM and FND_API.G_MISS_CHAR to distinguish unspecified values.

Tables Accessed

The ETRM metadata documents the record structure mirroring the AMS_CT_RULES content rule table (accessed through an APPS synonym). The package reads and writes the content rule columns enumerated in ct_rule_rec_type: content_rule_id, created_by, creation_date, last_updated_by, last_updated_date, last_update_login, object_version_number, object_type, object_id, sender, reply_to, cover_letter_id, table_of_content_flag, trigger_code, and subject. These columns define the rule's identity, its owning object, the delivery metadata for generated communications, and the audit/versioning fields required for multi-user integrity. The referenced-by-(0) count indicates no other shipped package depends directly on this API, emphasizing its role as a top-level extension point.

Usage Notes

AMS_CT_RULE_PUB is typically invoked from Oracle Forms-based marketing setup screens, from concurrent programs that seed or migrate content rule configuration, and from custom PL/SQL extensions that automate campaign communication setup. A common pattern is to call LOCK_CT_RULE, re-query the version, then call UPDATE_CT_RULE or DELETE_CT_RULE within the same transaction. The default fetch constant G_DEFAULT_NUM_REC_FETCH (30) governs bulk retrieval behavior. Developers extending this API should always honor the object_version_number contract and check the returned FND_API status before committing.