Search Results found_exist_objects




Overview
Explore in AI Chat

Overview

MST_LAUNCH_PLAN_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Oracle Advanced Planning and Scheduling (APS) / Supply Chain Planning (MST) product family and provides the server-side engine that launches a planning run from the Planner Workbench. In release 12.1.1 and 12.2.2 the package is declared with AUTHID CURRENT_USER, meaning its unqualified object references are resolved against the invoker's schema rather than the package owner. The package is classified under ETRM as OTHER, and is not referenced by any other documented package, so it sits at the outer edge of the planning call stack: concurrent programs and forms call into it, but it does not form part of a shared internal API used by other PL/SQL units.

The header comment ($Header: MSTPLAPS.pls 115.5 2004/08/18) confirms the file has been stable since the 11.5 code line, which is consistent with the behaviour observed in 12.1.1 and 12.2.2.

Key Procedures and Functions

  • MST_LAUNCH_PLAN — The principal entry point. It submits and coordinates the planning launch for a given plan, accepting the standard concurrent-program OUT parameters (errbuf, retcode) plus arguments that select the plan, control file reuse, determine audit mode, indicate whether the planner should be launched, bound the plan start and cutoff dates, and optionally set net change mode. It returns the standard success/warning/error codes defined by the package constants.
  • REFRESH_SNAPSHOT — Refreshes a named database snapshot to the requested parallelism degree (defaulting to 0, i.e. serial). It provides the snapshot maintenance step that precedes a planning run.
  • FOUND_EXIST_OBJECTS — A Boolean function that reports whether the prerequisite source objects already exist, allowing the launch logic to decide between a first-time setup and a re-use path.
  • SETUP_SOURCE_OBJECTS — A Boolean function that performs the creation of the source objects needed by the planning process. This is the object matching the search term setup_source_objects; it is not a standalone concurrent program but an internal function invoked by the launch path.
  • WAIT_FOR_REQUEST — Polls a submitted concurrent request ID until completion or until a supplied timeout elapses, returning a status code to the caller. It serialises the dependent steps of a plan launch.

Two package constants, SYS_YES and SYS_NO, encode the internal Yes/No flags, while G_SUCCESS, G_WARNING and G_ERROR provide the conventional return-code values.

Tables Accessed

  • MST_PLANS — The driving table; holds the plan definition identified by arg_plan_id, including plan options and dates.
  • FND_PROFILE_OPTIONS / FND_PROFILE_OPTION_VALUES — Read to resolve site, application, responsibility and user profile settings that govern launch behaviour.
  • ALL_OBJECTS — Queried by FOUND_EXIST_OBJECTS to establish whether the required source objects are already present.
  • ALL_SNAPSHOTS — Queried by the snapshot maintenance logic to determine whether a named snapshot exists before refresh.
  • DBMS_LOCK — Used for serialisation so that concurrent launches of the same plan cannot interleave.
  • DBMS_SNAPSHOT — Invoked to refresh or create the snapshots the planning engine consumes.
  • DUAL — Used for single-row expression evaluation and status checks.

Usage Notes

The package is invoked from the Planner Workbench and from the concurrent program that launches a plan; MST_LAUNCH_PLAN is the routine exposed to that program, and its errbuf/retcode pair follows the standard EBS concurrent manager convention. Because it is declared AUTHID CURRENT_USER, it must be executed by a caller with the necessary privileges on the underlying objects, which in practice means invocation through the APPS schema or through a registered concurrent program rather than ad hoc execution in another schema. Custom code should treat SETUP_SOURCE_OBJECTS and FOUND_EXIST_OBJECTS as internal helpers of the launch sequence and should not call them independently, since their Boolean results depend on state prepared earlier in the launch. The WAIT_FOR_REQUEST timeout parameter should always be supplied so that a stalled child request cannot block the parent indefinitely.