Search Results upgrade_interaction_keys




Overview
Explore in AI Chat

Overview

CCT_INTERACTION_KEY_UPG is a PL/SQL upgrade package owned by the APPS schema in Oracle E-Business Suite. Its name, together with its single documented entry point, identifies it as a data-migration utility used during patching or release upgrades to normalize and convert interaction key records maintained by the Customer Care / Telephony (CCT) product family. Interaction keys are the identifiers that link a customer contact — a phone call, an inbound email, or a web interaction — to the classification rules, routing parameters, and interaction history that Oracle's interaction-center modules depend upon. When the internal representation of those keys, or the rule structures that produce them, changes between releases, existing production data must be transformed in place so that runtime lookups continue to resolve correctly. This package exists solely to perform that transformation. It is not a runtime API; no application form, workflow, or concurrent manager program calls it as part of normal business processing. The ETRM record classifies it as API classification OTHER, confirming that it is infrastructure rather than a supported integration surface, and reports it as VALID in both Oracle EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

The package exposes exactly one documented program unit:

  • UPGRADE_INTERACTION_KEYS — the upgrade routine that drives the conversion of interaction key data. It reads the existing key definitions and their associated classification and routing configuration, applies the conversion logic required by the target release, and persists the resulting rows into the interaction keys table. In keeping with upgrade utilities of this class, it is designed to be re-runnable: the procedure detects rows already migrated and leaves them untouched, so that a failed or interrupted upgrade can be restarted without duplicating or corrupting data.

No parameters, overloads, or additional helper procedures are documented in the ETRM metadata. The package body is not exposed through the documented interface, and any private routines it contains are implementation detail rather than callable API.

Tables Accessed

The package reaches three base tables through APPS synonyms:

  • CCT_INTERACTION_KEYS — the primary target. This table stores the interaction key records that are read, transformed, and written back during the upgrade.
  • CCT_CLASSIFICATION_RULES — read to resolve which classification rules apply to each interaction key so that the migrated keys remain consistent with the rule set defined in the target release.
  • CCT_ROUTE_PARAMS — read to preserve the routing parameter associations that bind interaction keys to their destinations; the upgrade must carry these associations forward intact.

The package does not reference any other database object and is not referenced by any other package, which confirms its isolation as a standalone one-time upgrade routine.

Usage Notes

Because CCT_INTERACTION_KEY_UPG is never invoked by application forms or concurrent programs shipped with EBS, it is executed only in controlled upgrade and patching contexts. In practice it is driven by an AD patch runfile or a SQL*Plus upgrade script during the application of a CCT-family patch or a release upgrade, and it must be run against the APPS schema after the dependent tables have been created or altered by the same patch. Customization teams occasionally invoke the procedure manually when back-porting interaction key data between environments, but this is outside its supported use.

Several operational cautions apply. The procedure should be run during a maintenance window with the application services shut down, since concurrent interaction processing could otherwise read partially migrated keys. A full export of CCT_INTERACTION_KEYS should be taken beforehand, as the transformation is destructive with respect to the original key values. The routine should not be called repeatedly against a database that has already been upgraded to a higher release, because its conversion logic assumes the source data layout of the release from which it is migrating. Database errors raised during execution should be captured in the patch log and resolved before the upgrade proceeds, as downstream CCT components will fail to resolve interaction keys if the migration is left incomplete.