Results for “csr_rules”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

AME_CONDITION_API is an internal Oracle Application Management Engine (AME) package body owned by the APPS schema. Its role is to encapsulate the create, update, and delete operations that define and maintain conditions within the AME rule engine. In the AME model, a condition is the atomic Boolean test — for example, "requisition total is greater than 1000" or "cost center equals X" — that is attached to a rule and evaluated against a transaction's attributes. Rules do not interpret transactions directly; they delegate that work to their constituent conditions.

The package therefore sits near the base of the AME dependency hierarchy. It manages the persistence of condition definitions and their associated literal values, verifying that the referenced attributes exist and that the supplied values are consistent with the attribute data type. Higher-level AME packages depend on this one; the metadata records that the package is referenced by two other packages, and it in turn relies on AME_ATTRIBUTES and AME_RULES to keep condition records structurally valid.

Key Procedures and Functions

• CREATE_AME_CONDITION — Creates a new condition record for a given attribute, establishing its condition type and the parameters against which values will later be evaluated.
• UPDATE_AME_CONDITION — Modifies an existing condition, for example changing the attribute, the condition type, or the binding parameters of an existing rule.
• DELETE_AME_CONDITION — Removes a condition from the AME repository, typically after its usages on rules have been removed.
• CREATE_AME_STRING_VALUE — Inserts a string-type value associated with a condition, used when the condition is defined against a character attribute rather than a number or date.
• DELETE_AME_STRING_VALUE — Removes a previously stored string value from the condition, keeping the condition's string value set in step with the condition definition.

The package body also contains the private helper function IS_STRING_CONDITION, which resolves a condition to its underlying attribute and determines whether that attribute is of string type. This function underlies the string-value procedures and the type validation performed on all condition writes.

Tables Accessed

• AME_ATTRIBUTES — Read to resolve attribute_id to attribute_type and to validate that the attribute is effective on the supplied effective date; this drives the IS_STRING_CONDITION logic.
• AME_CONDITIONS — The primary table written and read by all create, update, and delete operations; holds the condition definition itself.
• AME_CONDITION_USAGES — Read and validated to establish whether a condition is currently attached to a rule, so that deletions do not orphan rule definitions.
• AME_RULES and AME_RULE_USAGES — Consulted to maintain referential integrity between conditions and the rules that consume them.
• AME_STRING_VALUES — Stores and removes the string literal values handled by CREATE_AME_STRING_VALUE and DELETE_AME_STRING_VALUE.
• DBMS_UTILITY and PLITBLM — Utilised for error formatting and internal string/PL-SQL helper processing.

Usage Notes

AME_CONDITION_API is classified as Internal API Use Only. Oracle does not publish it for direct customer invocation, and it is called by the higher-level AME configuration APIs that back the Approvals Management setup forms and the AME Business Analyst responsibility. In a 12.1.1 or 12.2.2 environment, administrators rarely touch it directly; they define conditions through the AME setup UI, which routes the underlying DML to this package.

Custom code that needs to manipulate AME conditions programmatically — commonly during data migration or when replicating configuration between instances — must call the documented procedures and supply a valid effective date, because all reads are date-filtered against AME_ATTRIBUTES and AME_CONDITIONS start and end dates. Inserting rows into the AME tables directly bypasses attribute-type validation and the usage checks enforced here, and is not supported. The search term "csr_rules" appears only as an internal cursor name (csr_atr_type is the cursor shown in the excerpt; similar csr_ prefixed cursors recur throughout the body), which is why the name surfaces in source-level searches but has no stand-alone API meaning. Callers should treat all errors raised by this package as propagated application errors and roll back the encompassing transaction.