Search Results update_item

Overview

The APPS.IEM_ARCH_REQUESTS_PVT package is a private PL/SQL API belonging to the Oracle E-Business Suite iMarketing (IEM) module, specifically addressing the archiving of iMarketing request data. The package is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking schema rather than the defining schema, a design choice common to private APIs intended solely for internal callers. Its header carries the version marker iemarqvs.pls 115.0, dated 2003, indicating the package has been stable since the early releases of the 11i/12.x code line, and it continues to be shipped through 12.1.1 and 12.2.2.

The business function of this package is to manage the lifecycle of archive request records within the IEM_ARCH_REQUESTS table. iMarketing captures e-mail campaign activity, listener data, and related request artifacts; over time, this data must be archived to control database growth and to satisfy retention policies. The private API provides the write-side operations — record creation and record maintenance — that support the higher-level archiving process.

Key Procedures and Functions

• CREATE_ITEM — A private procedure that inserts a new record into the IEM_ARCH_REQUESTS table. It accepts the standard API control parameters (API version number, message-list initialization flag, and commit flag) along with the archive-request attributes: the request identifier, archiving criteria, e-mail account identifier, folder name, request value, archive folder identifier, archive count, and the usual audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN). It returns the standard x_return_status, x_msg_count, and x_msg_data OUT parameters. This procedure is the entry point for registering a new archiving request.
• UPDATE_ITEM — A private procedure that updates an existing archive request record. Its input parameters include the request identifier, archive folder identifier, archive count, archive size, status, and comment, plus the standard control and audit parameters. It returns the standard x_return_status, x_msg_count, and x_msg_data OUT parameters. The procedure is the mechanism by which the archiving process advances a request's state — for example, recording the number of items archived, the resulting size, the completion status, and any operator comment.

Tables Accessed

• IEM_ARCH_REQUESTS — The single documented table referenced by this package. It is accessed through the APPS synonym and is the sole persistent store manipulated by both procedures. CREATE_ITEM writes new rows to this table; UPDATE_ITEM modifies existing rows. The table serves as the master log of archive requests, capturing the request identifier, criteria, account and folder references, counts, sizes, status, comments, and audit columns.

Usage Notes

Because the package is classified as PVT (private), it is not intended as a supported public integration point. ETRM metadata records that it is referenced by one other package, confirming that its callers are internal iMarketing archiving components rather than external interfaces. Developers should not invoke CREATE_ITEM or UPDATE_ITEM directly from custom code; the appropriate integration surface is the public API or concurrent program that wraps this private package.

In a typical Oracle EBS 12.1.1 or 12.2.2 deployment, this package is invoked by the iMarketing archiving engine, most likely in the context of a concurrent program or a scheduled archiving process that periodically moves stale listener and request data to designated archive folders. The package maintains the state transitions of each archive request: CREATE_ITEM registers the request, and UPDATE_ITEM records progress (item counts, archive size, status, and comments) until the request completes. The p_commit parameter on both procedures allows the caller to control transaction boundaries, which is essential when multiple archive requests are processed within a single concurrent request. Custom code that reads IEM_ARCH_REQUESTS for reporting is permissible, but all writes should be routed through the supported public API to preserve data integrity and audit conventions.