Search Results validate_parent_interaction

Overview

CS_INTERACTION_UTL is a utility package body in the Oracle E-Business Suite Customer Relationship Management (CRM) foundation schema, owned by APPS and classified under the ETRM API classification "OTHER". Its role is to provide reusable validation logic for Interaction records stored in the CS_INTERACTIONS table. These records represent interactions created by or about customers, agents, or contacts in modules such as TeleSales, iStore, and the interaction center frameworks. The package is a code-level utility rather than a business-facing API; it exists so that other packages and API implementations can centralize a common validation rule (verifying that a referenced parent interaction exists within the correct operating unit context) without duplicating SQL. The single documented procedure in this package is commonly sought by developers under the search term "validate_parent_interaction", reflecting its use as a guard clause in parent-child interaction hierarchies.

Key Procedures and Functions

The package body documents one public procedure:

• VALIDATE_PARENT_INTERACTION — Validates the existence of a parent interaction in the CS_INTERACTIONS table. It takes the calling API name and a parameter name (for error message construction), the parent interaction identifier, and an optional organization identifier, and returns a standard FND_API return status. The procedure issues a SELECT against CS_INTERACTIONS, using a NVL/DECODE construct to reconcile the passed ORG_ID with the ORG_ID stored on the interaction record, effectively performing an operating-unit-aware lookup. If no matching row is found, it sets the return status to the FND_API error code and delegates message construction to CS_CORE_UTIL.ADD_INVALID_ARGUMENT_MSG, ensuring a consistent, translatable error message that identifies the offending argument. The routine uses a NO_DATA_FOUND exception handler as its sole control flow path; because the query returns at most one row for a given INTERACTION_ID and ORG_ID combination, no TOO_MANY_ROWS handler is present.

The procedure returns no value other than the OUT return status; the underlying utility is not documented to insert, update, or delete data.

Tables Accessed

• CS_INTERACTIONS — Accessed via the APPS synonym. It is read (SELECT INTO) by the procedure to confirm that a row exists with the supplied INTERACTION_ID and a matching NVL(ORG_ID, -99) = DECODE(ORG_ID, NULL, -99, p_org_id) predicate. The predicate's sentinel value of -99 represents a null-safe comparison, allowing validation to succeed when both the stored ORG_ID and the parameter are null, or when they are identical. No data modification is performed.

Usage Notes

Because CS_INTERACTION_UTL is referenced by at least one other package according to the documented dependency metadata, it is normally invoked indirectly: a calling interaction API or a custom wrapper passes its own API name and parameter name into VALIDATE_PARENT_INTERACTION, then inspects the returned FND_API status before proceeding with its own DML. Invocation typically occurs during the validation phase of an API call, prior to inserting or updating an interaction that references a parent. The header line shows the source originated in mid-1999 and reflects a porting baseline, but the package remains relevant in EBS 12.1.1 and 12.2.2 for backward compatibility of the interaction model. Because the documented surface is limited to a single validation procedure, custom code should treat CS_INTERACTION_UTL as a lightweight guard utility rather than a substitute for the full Interaction API. Developers should also be aware that the org_id check relies on the -99 sentinel, so callers passing a valid ORG_ID must ensure it matches the operating unit of the parent interaction or the validation will correctly fail and return g_ret_sts_error with an invalid-argument message.