Search Results delete_forum_message

Overview

The APPS.OTA_FORUM_MESSAGE_API package body provides the supported programmatic interface for creating, maintaining, and removing records in the Oracle EBS forum messaging repository. It belongs to the Oracle Training Administration (OTA) product family, which manages learner collaboration, discussion threads, and threaded message exchanges attached to forums. The package encapsulates the business rules that govern message records so that forms, concurrent programs, and custom extensions do not write directly to the underlying tables. Each write operation is routed through a corresponding business-event hook package — such as OTA_FORUM_MESSAGE_BK1 for the create path — allowing customers to attach validation or derived-attribute logic without modifying Oracle-owned code. The source header identifies the file as otfmsapi.pkb at version 120.4, a level consistent with the 12.1.1 and 12.2.2 code lines. The package is classified in ETRM as an API, confirming that its procedures are intended for external invocation and are subject to Oracle's public interface standards, including row-level locking, object version numbering, and validation mode support.

Key Procedures and Functions

ETRM documents three procedures on this package. Parameter lists are intentionally omitted here; only the documented purpose of each is described.

• CREATE_FORUM_MESSAGE — Inserts a new forum message row into the repository. The procedure accepts an effective date, the owning forum and forum thread, a business group, the message scope and body text, and optional parent-message and person/contact references that support threaded replies and authorship attribution. It returns the newly generated forum message identifier and object version number to the caller. A p_validate flag permits the caller to exercise all validation logic without committing the row. The documented body shows that the time portion of the effective date is truncated before processing and that a savepoint is issued so the transaction can be rolled back on failure.
• UPDATE_FORUM_MESSAGE — Modifies an existing forum message identified by its primary key and object version number. It applies the same date-truncation and validation conventions as the create path and refreshes the object version number to preserve optimistic locking.
• DELETE_FORUM_MESSAGE — Removes a forum message from the repository. This is the procedure most frequently targeted by searches on the forum message API, since it is the sanctioned mechanism for purging messages. Callers are expected to supply the message identifier and object version number so that the deletion is guarded against concurrent modification. Because forum messages may participate in a parent/child hierarchy, deletion should be evaluated against dependent reply rows before invocation.

Tables Accessed

The package operates on the OTA_FORUM_MESSAGES table, referenced through its APPS synonym. All three documented procedures read and write this single entity: CREATE_FORUM_MESSAGE inserts a row, UPDATE_FORUM_MESSAGE modifies columns such as message body and scope, and DELETE_FORUM_MESSAGE removes the row. The table stores the message identifier, forum and thread keys, business group, message scope and body, parent message reference, and the person or contact identifiers for both author and target. Effective dates and object version numbers maintained on the row support date-tracked querying and optimistic concurrency control.

Usage Notes

The package is invoked from Oracle Forms and OAF pages within the Training Administration module, from concurrent programs that seed or clean up forum content, and from custom PL/SQL that must respect the standard validation and business-event hooks. Custom code should call these procedures rather than issuing DML against OTA_FORUM_MESSAGES directly, because the API triggers the before-process hooks and enforces version checking. Callers should wrap invocations in a savepoint or exception handler and honor the returned object version number on update and delete. ETRM records that this package is referenced by one other package, indicating a limited but real dependency surface that should be reviewed before any upgrade or extension work.