Search Results update_waitlisted

Overview

OTA_TDB_API_UPD2 is a private Oracle EBS package body in the APPS schema that supports the Oracle Learning Management (OTL) delegate booking infrastructure. Its role is to perform controlled updates against delegate booking records stored in the OTA_DELEGATE_BOOKINGS table, including the specialized handling required when a learner's registration must be moved between enrollment and waitlist states. The package is classified as OTHER in the ETRM metadata, meaning it is not a public, independently callable API in the sense of the formal OTA public API families; instead it functions as an internal update layer invoked by higher-level booking APIs and by the OTA_TDB_API family of packages. The header comment ($Header: ottdb02t.pkb 120.22.12010000.2) confirms it is a delivered, patched Oracle file, with the latest recorded revision dated 2009. It is referenced by seventeen other packages, reflecting its position as a shared dependency within the delegate booking subsystem.

Key Procedures and Functions

Three procedures are documented for this package.

• UPDATE_ENROLLMENT — Updates a delegate booking record in the context of an enrollment transaction. It applies changes to the booking row while validating the resulting state, including booking status transitions and place/attendee counts, so that enrollments remain consistent with event capacity rules.
• UPDATE_WAITLISTED — The procedure matching the user search term. It updates a delegate booking that is, or is becoming, waitlisted. This is the counterpart to UPDATE_ENROLLMENT for learners who cannot be confirmed into a full or restricted event, and it is responsible for writing the waitlisted booking status and related attributes to OTA_DELEGATE_BOOKINGS.
• CHK_MANDATORY_PREREQS — A validation routine that checks the mandatory prerequisites configured for an event or offering before a booking update is permitted. It acts as a guard condition for the update procedures above.

The package body also contains a private helper, Check_Status_Change, which compares the old cached record (ota_tdb_shd.g_old_rec) against the incoming values to detect booking status changes, number-of-places changes, and event changes, retrieving vacancies through ota_evt_bus2.get_vacancies and translating booking status type identifiers via ota_tdb_bus.booking_status_type. This confirms that the package performs row-level change detection prior to committing updates.

Tables Accessed

The documented tables referenced through APPS synonyms are:

• OTA_DELEGATE_BOOKINGS — the primary target of all update operations; holds the learner's booking row for an event.
• OTA_EVENTS — read to establish event context, including event status and capacity information used when reassigning bookings between events.
• OTA_BOOKING_STATUS_TYPES — read to resolve status identifiers into meaningful booking status codes such as confirmed, waitlisted, or cancelled.
• OTA_FORUMS_B — the base forum (class/session) table, consulted for the learning event container associated with the booking.
• OTA_FRM_NOTIF_SUBSCRIBERS — notification subscriber definitions, accessed when booking changes trigger forum-related notifications.
• OTA_FRM_OBJ_INCLUSIONS — defines which objects are included in a forum, used to validate that the booking's target object belongs to the forum.

Usage Notes

OTA_TDB_API_UPD2 is an internal package and should not be called directly from custom code in preference to supported public APIs. It is normally invoked indirectly through the OTA delegate booking API chain when an administrator or self-service learner changes a booking from a form in the Learning Management responsibility, or when a concurrent program processes enrollment, cancellation, or waitlist promotion. Because it is referenced by seventeen packages, modifications to its behavior propagate widely; customizations should therefore avoid patching this package body and instead wrap the calling public APIs. Debug tracing is controlled by HR_UTILITY.DEBUG_ENABLED, and the embedded HR_UTILITY.SET_LOCATION calls allow DBMS output tracing of entry into the status-change logic when debugging is enabled.