Search Results validate_rule_group

Overview

AMS_RULE_GROUP_PVT is a private PL/SQL package body in the Oracle Advanced Marketing (AMS) module of Oracle E-Business Suite, appearing in releases 12.1.1 and 12.2.2. It encapsulates the business logic required to create, maintain, and validate Rule Groups, which are the container objects that organize posting rules used by the Advanced Marketing rule engine. Rule Groups associate one or more rules with posting parameters, status filters, and content definitions that determine how marketing campaigns and offers are evaluated and applied.

As a PVT (private) API, the package is not exposed directly to end users. It is intended to be invoked by the public API layer and by other AMS components that must manipulate rule group data in a controlled, validated manner. The header comment block identifies the source file as amsvrgpb.pls and records the package name constant G_PKG_NAME as 'AMS_Rule_Group_PVT', with debug-level constants sourced from FND_MSG_PUB to support diagnostic logging.

Key Procedures and Functions

The package exposes seven documented procedures, all conforming to the Oracle Application Object Library PL/SQL API standard, with a savepoint established at the start of each transactional operation.

• CREATE_RULE_GROUP — Inserts a new rule group record, generating the primary key from the AMS_IBA_PS_RULEGRPS_B_s sequence and returning the new rule group identifier to the caller. It respects API versioning, message list initialization, commit control, and validation level parameters.
• UPDATE_RULE_GROUP — Modifies an existing rule group, applying object version checking to guard against lost updates.
• DELETE_RULE_GROUP — Removes a rule group and its dependent data.
• LOCK_RULE_GROUP — Acquires a row-level lock on a rule group to serialize concurrent modification.
• VALIDATE_RULE_GROUP — The procedure most relevant to the search term, performing the full validation ruleset before a rule group is persisted; it is the entry point that confirms structural and referential integrity of the supplied record.
• CHECK_RULE_GROUP_ITEMS — Examines the child items belonging to a rule group, verifying that associated rules and parameters are present and consistent.
• VALIDATE_RULE_GROUP_REC — Validates an in-memory rule group record structure, supporting the higher-level VALIDATE_RULE_GROUP and CREATE/UPDATE flows without touching the database.

Tables Accessed

The package operates against a set of AMS base and translation tables accessed through APPS synonyms:

• AMS_IBA_PS_RULEGRPS_B — The base rule group table, the primary insert/update/delete target.
• AMS_IBA_PS_RULEGRPS_B_S — The sequence used to generate RULEGROUP_ID values.
• AMS_IBA_PS_RULEGRPS_TL — The translation table holding language-specific rule group names and descriptions.
• AMS_IBA_PS_RULES — The rules that belong to a rule group; queried during item checks and validation.
• AMS_IBA_PS_POSTINGS_B — Posting definitions referenced by rule group configuration.
• AMS_IBA_PS_RL_ST_FLTRS and AMS_IBA_PS_RL_ST_PARAMS — Rule status filters and status parameters that refine when a rule group applies.
• DUAL — Used for sequence value retrieval.

Two other packages reference AMS_RULE_GROUP_PVT, confirming its role as a shared internal service layer within Advanced Marketing.

Usage Notes

AMS_RULE_GROUP_PVT is normally invoked indirectly. The AMS setup and rule administration forms call the corresponding public API, which in turn delegates to these private procedures. Concurrent programs that seed or migrate marketing rule configuration may also call the package through the public wrapper. Direct custom invocation is discouraged; where it is required, callers must supply an API version number, observe the standard x_return_status, x_msg_count, and x_msg_data out parameters, and check the return status against FND_API.G_RET_STS_SUCCESS before committing. The VALIDATE_RULE_GROUP procedure should be called before persisting changes so that item and record validation is applied consistently, and the LOCK_RULE_GROUP procedure should precede updates in multi-user environments to prevent concurrent modification.