Search Results update_escalation_contacts




Overview

The PL/SQL package body APPS.JTF_EC_CONTACTS_PVT provides the private-API implementation for maintaining escalation contacts associated with the Oracle E-Business Suite escalation management and task tracking framework. The suffix _PVT identifies it as a private package: it holds the actual business logic and is intended to be called by a corresponding public wrapper (typically JTF_EC_CONTACTS_PUB) or by other internal packages rather than directly by external consumers. The package encapsulates the create, update, and delete logic required to associate a contact party with an escalation, including the flags that designate whether a given contact is a requester or a recipient of escalation notifications.

Escalation contacts are a supporting construct within the JTF (Java Technology Foundation) task and contact model used by Oracle Service, CRM, and related modules. When an escalation is raised against a task or service request, the escalation framework must know which contacts should be notified and which contact originated the escalation. This package manages those associations.

Key Procedures and Functions

The package exposes three documented procedures:

  • CREATE_ESCALATION_CONTACTS — Inserts a new escalation-to-contact association. It accepts identifying context for the escalation (escalation identifier or escalation number) together with the contact identifier and contact type code, and the notification and requester indicator flags. It also supports the standard flexible-attribute columns (attribute1 through attribute15 plus the attribute category) via the DFF framework. It returns the newly created escalation contact identifier along with the standard API return status, message count, and message data outputs.
  • UPDATE_ESCALATION_CONTACTS — Modifies an existing escalation contact record. The procedure supports changes to the contact association and to the descriptive attribute columns, following the same API signalling convention (version, init message list, commit flag, and standard output parameters) used throughout the JTF private APIs.
  • DELETE_ESCALATION_CONTACTS — Removes an escalation contact association, logically deleting the relationship between the escalation and the contact while preserving referential consistency in the underlying tables.

All three procedures follow the Oracle Application Object Library API conventions, including the API version parameter, the initialization message list flag, and the commit flag that allows the caller to defer or force a database commit.

Tables Accessed

The package operates against two documented base tables, accessed through APPS synonyms:

  • JTF_TASK_CONTACTS — The primary table holding the association rows between tasks/escalations and contacts, including the contact type, notification flag, requester flag, and the descriptive flexfield attribute columns. This is the table the create, update, and delete procedures write to.
  • JTF_TASKS_B — The task base table. The package references this table (as evidenced by the l_task_id variable typed against JTF_TASKS_B.task_id) to validate or resolve the task/escalation context before writing contact associations.

Usage Notes

Because this is a private package, it is not intended for direct invocation by customer extensions. It is normally called from within the JTF escalation framework, most commonly by the public API layer and by Oracle Forms-based escalation and task maintenance screens. It may also be invoked by concurrent programs or workflow activities that create or modify escalation contacts in bulk.

Custom code that needs to maintain escalation contacts should call the public counterpart rather than this private package, both to respect the supported API boundary and to benefit from any validation that the public layer adds. When calling from custom PL/SQL, developers should pass FND_API.G_FALSE for the commit flag and manage the transaction boundary explicitly, and should inspect x_return_status and x_msg_data before proceeding, since the procedures do not raise exceptions on all error conditions.