Search Results csm_html5_pkg




Overview
Explore in AI Chat

Overview

ASG_APPLY is an Oracle E-Business Suite PL/SQL package owned by APPS and classified under the ETRM classification OTHER. In the EBS 12.1.1 and 12.2.2 releases it functions as the core apply-engine for the ASG (Application Synchronization / mobile user sync) subsystem. Its stated purpose in the source header is to "process upload data" and it additionally supplies a large collection of helper routines intended to apply changes efficiently. The package is compiled with AUTHID DEFINER, meaning it executes with the privileges of its owning schema (APPS) rather than the calling user.

The functional scope centres on reconciling client-side or mobile-collected data with the EBS database. It determines which publication items and inquiry records are dirty or deferred, processes upload and sequence streams in bulk, and performs the transactional bookkeeping that surrounds each apply cycle. The header history indicates the package was created in February 2002 and subsequently extended with sequence processing, deferred transaction support, concurrent-program context globals, and delivery notification.

Key Procedures and Functions

The package exposes 25 documented procedures and functions:

Global variables (g_conc_userid, g_conc_respid, g_conc_appid) store the concurrent program's user, responsibility, and application context, along with g_current_tranid and g_only_deferred_trans.

Tables Accessed

The package reads and writes a defined set of APPS synonyms:

Usage Notes

ASG_APPLY is typically invoked from ASG concurrent programs that perform the periodic apply of mobile user uploads and inquiry synchronisation; IS_CONC_PROGRAM_RUNNING prevents conflicting runs, and the *_APPLY procedures delimit each apply transaction. It is referenced by six other packages in the EBS schema and should not be treated as a public API for custom development, as it is internally consumed and its behaviour is tied to the ASG subsystem's own metadata. Administrators should consult ETRM and the ASG functional documentation before diagnosing failures, since most error conditions surface through the log routine and the return status of the get_* routines.