Search Results asg_apply




Overview
Explore in AI Chat

Overview

The concurrent program ASG_APPLY belongs to the ASG - CRM Gateway for Mobile Devices product within Oracle E-Business Suite. Its user-facing name is Processes Uploaded Mobile Data, and it is described as a concurrent process for applying uploaded data. The program is the server-side counterpart to the mobile data capture and upload mechanism used by field service, sales, and other mobile-enabled CRM users. Mobile clients capture transactions and reference data while disconnected from the corporate network, store them locally, and later synchronize them to EBS through the ASG gateway. Once that upload reaches the application tier and lands in the gateway's staging area, ASG_APPLY performs the reconciliation and posting work that moves the data into its final destination within the CRM application tables.

The program is delivered as enabled in the standard product installation, so it is available for scheduling and submission immediately after the ASG module is licensed and configured. Its presence in the concurrent manager is essential to the mobile synchronization cycle: without a successful ASG_APPLY run, uploaded mobile records remain staged and are not visible to CRM users operating in the desktop application.

Execution Details

The documented execution metadata for ASG_APPLY is as follows. The execution method is PL/SQL Stored Procedure, and the executable is registered as ASG_APPLY. The execution file is asg_apply.process_upload, identifying the server-side package and entry point invoked by the concurrent manager. The argument method is Standard, meaning the program uses the conventional concurrent program argument passing mechanism rather than token-based or multi-select arguments. The executable's user name is ASG_APPLY, and the executable description matches the program description: concurrent process for applying uploaded data.

This configuration is consistent between EBS 12.1.1 and 12.2.2. The program requires no Oracle Forms interface for its core logic; it executes entirely in the database tier through the PL/SQL package, which allows it to be scheduled, resubmitted, and monitored through the standard concurrent manager facilities.

How to Run

Users with the appropriate ASG responsibility submit the program through the Standard Request Submission (SRS) window, Submit Requests, selecting Processes Uploaded Mobile Data from the list of available concurrent programs. In many implementations the program is not submitted manually at all; instead it is scheduled as a recurring concurrent request, typically at a low frequency or during periods when mobile synchronization traffic is expected, so that staged uploads are applied promptly.

Because the argument method is Standard, any parameters must be entered as concurrent program arguments in the SRS window rather than through a custom parameter form. Site configurations vary, and administrators should confirm the specific arguments in use in their environment, since the ETRM metadata documents the executable and execution details rather than a fixed parameter list. Organizations generally define a dedicated request group and responsibility so that only authorized mobile administrators can submit or reschedule the program.

Related Objects

ASG_APPLY operates on data delivered by the mobile gateway upload path. It is commonly associated with the ASG interface and staging tables into which mobile clients write uploaded records, and with the CRM base tables that receive the applied data. Related concurrent programs in the same product include the upload-side processes that receive mobile transmissions, as well as any purge or cleanup programs used to maintain the staging area. Because the applied data ultimately populates standard CRM entities, troubleshooting typically involves the ASG package body for asg_apply, the concurrent manager log and output files, and the interface table records that identify rejected rows. Administrators should review request logs first when records fail to appear in CRM, as the program reports its processing outcomes there.