Search Results launch_worker_cont

Overview

MSC_CL_PULL is an Oracle E-Business Suite PL/SQL package owned by the APPS schema, classified as an OTHER API within the ETRM documentation set. It resides in the Advanced Supply Chain Planning (ASCP) product family, where its name follows the MSC_CL_* convention reserved for "collection" or "pull" processing. The package serves as a control and orchestration layer for the data pull (collection) engine that moves source application data into the MSC staging tables consumed by planning. Rather than extracting a single business object, MSC_CL_PULL coordinates the parallel execution of the individual collection workers — item, bill of material, routing, demand, supply, WIP, and others — that are named as its dependent packages. It manages worker launching, process monitoring, task sequencing, continuation handling, and cleanup, effectively acting as the driver for the complete collections cycle.

The package is marked VALID and depends on FND_PROFILE, MSC_UTIL, and the SYS.STANDARD package, confirming that it reads profile option settings and uses shared utility routines supplied by the MSC schema.

Key Procedures and Functions

Nineteen documented procedures and functions are associated with MSC_CL_PULL:

• LAUNCH_WORKER / LAUNCH_WORKER_CONT — initiate the collection worker processes, including the continuation variant used when a worker must resume across execution boundaries.
• LAUNCH_MONITOR, LAUNCH_MONITOR_CONT, LAUNCH_MONITOR_DET_SCH, LAUNCH_MONITOR_CONT_DET_SCH — start and supervise the monitor that watches worker progress, with continuation and deterministic-schedule variants.
• DELETE_PROCESS — remove or clean up process records associated with a completed or aborted collection run.
• INITIALIZE / FINAL — perform setup and teardown for the package's processing cycle.
• EXECUTE_TASK — dispatch an individual task within the collection sequence.
• Q_PARTIAL_TASK — handle tasks that must be processed in partial increments.
• SALES_ORDER_REFRESH_TYPE — determine the refresh mode applied to sales order data.
• GET_ORG_STR and GET_DEPOT_ORG_STRINGS — build organization identifier strings, the latter specifically for depot organizations.
• SET_ST_STATUS — update the status flag of a staging or schedule table row.
• ANALYZE_ALL_ST_TABLE / ANALYZE_ST_TABLE — invoke cost-based optimizer statistics gathering on staging tables, individually or across all.
• GET_ENTITY_LRN — return the logical row identifier for a given entity, supporting delta-based refreshes.

Tables Accessed

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

• MSC_CL_REFRESH_S — the refresh schedule/setup table that governs when and how collection runs are triggered.
• MSC_COLL_PARAMETERS — collection parameters controlling scope and behavior of the pull.
• MSC_APPS_INSTANCES and MSC_INSTANCE_ORGS — identify the source application instance and the organizations within it that participate in collection.
• FND_ORACLE_USERID and FND_PRODUCT_INSTALLATIONS — resolve database credentials and verify installed products.
• ALL_TABLES — used by the analyze routines to locate staging tables.
• DBMS_LOCK, DBMS_PIPE, DBMS_UTILITY, DUAL, PLITBLM — Oracle-supplied utilities supporting locking, inter-process signaling, and PL/SQL table operations.

Referenced-by information names sixteen packages, predominantly the MSC_CL_* collection modules (BOM, demand, item, routing, supply, WIP, RPO, setup, other, GMP utility), plus GMP_CALENDAR_PKG and MSC_UTIL, confirming MSC_CL_PULL as the central orchestrator of the collection subsystem.

Usage Notes

MSC_CL_PULL is not typically invoked from an EBS form. It is executed through ASCP collection concurrent programs and internal engine calls that schedule the full or incremental data pull, including request-set members and the planner workbench's "Launch Collections" actions. Custom code should not call its procedures directly; instead, integrations should invoke the supported concurrent program entry points or use the documented MSC collection APIs. Because the package manages DBMS_LOCK and DBMS_PIPE resources, concurrent execution of overlapping collection requests must be avoided. All diagnostic attention should focus on MSC_COLL_PARAMETERS settings and MSC_CL_REFRESH_S scheduling when collection runs fail or hang.