Search Results bis_alert_registration_s

Overview

APPS.BIS_PMF_ALERT_REG_PVT is the private PL/SQL API responsible for managing the Alert Registration Repository within Oracle E-Business Suite. It is the implementation body behind the public package BIS_PMF_ALERT_REG_PUB and forms part of the Oracle Performance Management Framework (PMF) / Balanced Scorecard alerting infrastructure. The package maintains the linkage between alert definitions, registration records, scheduler parameters, and the notifier recipients who are informed when an alert condition is satisfied.

The header comment identifies the file as BISVARTB.pls, with a creation date of 17-May-2000 and a revision history extending through Bug#4235732 (2005). The package classification is Private (PVT), meaning it is not intended for direct invocation by external code; all access is expected through the public wrapper. It is referenced by five other packages, confirming its role as a shared internal service layer. It is deployed identically on EBS 12.1.1 and 12.2.2, and runs under the APPS schema.

Key Procedures and Functions

The package exposes eighteen documented procedures and functions. The principal ones include:

• CREATE_PARAMETER_SET — Creates or updates a parameter set record for an alert registration, populating the parameter set REC type passed between the public and private layers.
• DELETE_PARAMETER_SET — Removes an existing parameter set and its dependent registration data.
• RETRIEVE_PARAMETER_SET — Returns the stored parameters for a given registration so the alert can be evaluated at runtime.
• RETRIEVE_NOTIFIERS_CODE — Returns the notification code(s) associated with an alert registration, allowing the caller to determine which notifier configuration applies. This is the procedure most commonly matched against the search term "retrieve_notifiers_code".
• MANAGE_ALERT_REGISTRATIONS — Central routine that orchestrates registration creation, update, and deletion for an alert.
• VALIDATE_PARAMETER_SET and PARAMETER_SET_EXIST — Perform existence and consistency checks before persistence.
• FORM_PARAM_SET_REC — Builds the parameter set record structure from individual attribute values.
• BUILDALERTREGISTRATIONURL and BUILDSCHEDULEREPORTURL — Generate the URLs embedded in alert notifications so recipients can navigate to the registration or scheduler report.
• ADD_USERS_TO_ROLE — Added under Bug#3909131 (27-Oct-2004) to add recipient users to the WF ad-hoc role used for alert notification.

Tables Accessed

The package accesses the following objects through APPS synonyms:

• BIS_ALERT_REGISTRATION_S — The core sequence/table holding alert registration records; read and written for create, delete, and retrieve operations.
• BIS_PMF_ALERT_PARAMETERS — Stores the parameter values attached to each registration.
• WF_ADHOC_ROLE_S — Provides the ad-hoc role backing notifier distribution; used by ADD_USERS_TO_ROLE.
• DUAL — Used for singleton selects and sequence lookups.
• PLITBLM — A PL/SQL table used for in-memory collection handling within the package.

Usage Notes

Because this is a private API, it should never be called directly from custom code. Invocation flows through BIS_PMF_ALERT_REG_PUB or through the PMF alert-registration forms, which call the public layer and delegate to this body. Concurrent programs that register or refresh performance alerts also reach it indirectly.

All procedures follow the ETRM API conventions: an p_api_version input, a p_commit flag defaulting to FND_API.G_FALSE, x_return_status and x_error_tbl outputs using BIS_UTILITIES_PUB.Error_Tbl_Type, and IN OUT NOCOPY record parameters. Callers must inspect x_return_status for FND_API.G_RET_STS_ERROR or G_RET_STS_UNEXP_ERROR and process the error table. The package must be executed with the APPS schema's standard runtime privileges.