Search Results check_process_enabled




Overview
Explore in AI Chat

Overview

GMA_WFSTD_P is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the Process Manufacturing (GMA) module family, as indicated by the GMA prefix on both the package and the underlying tables. Its role is to serve as the workflow configuration and approval standard interface for process manufacturing workflow-enabled transactions. The package centralizes the logic required to resolve workflow roles, determine whether a given process or activity requires approval, verify whether a process is enabled, and assemble the control parameters needed to drive a workflow. It is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the calling schema rather than the defining schema, which is significant for a standards package invoked from many contexts.

The header banner (115.5, dated 2002/11/01) shows this package originated in the 11i era and has been carried forward essentially unchanged into 12.1.1 and 12.2.2, where the same specification remains the documented contract. The bundled comment explicitly states that the role lookup takes the workflow type, process type, and activity type as its inputs, confirming that GMA_WFSTD_P is the bridge between Process Manufacturing's process/activity definitions and the generic Oracle Workflow engine.

Key Procedures and Functions

The package exposes five documented program units:

  • GET_ROLE — a procedure returning the workflow role for a given combination of workflow item type, process name, and activity name, using a data string for additional context. This is the core role-resolution call used when a workflow must decide who performs or approves an activity.
  • CHECK_PROCESS_APPROVAL_REQ — a function that reports whether approval is required at the process level for a given workflow item type and process name.
  • CHECK_ACTIVITY_APPROVAL_REQ — a function that performs the equivalent check at the finer activity level, adding the activity name to the item type and process name.
  • CHECK_PROCESS_ENABLED — a function returning a BOOLEAN that indicates whether a named process is enabled for the supplied workflow item type.
  • WF_GET_CONTORL_PARAMS — a procedure that builds the data string and workflow string control parameters from an item type, process name, activity name, table name, and where clause. The misspelling of "CONTROL" in the program name is part of the shipped, delivered signature and must be reproduced exactly in any call.

Notably, the module's internal helper parameters frequently carry the p_process_name identifier, which is the term users search on when tracing how process names flow into approval and role resolution.

Tables Accessed

The package reads configuration from the Process Manufacturing workflow definition and activity collection tables, referenced through APPS synonyms: GMA_PROCDEF_WF and GMA_PROCCOL_WF_B for process definitions and process collection headers, GMA_PROCDATA_WF for process-level data, GMA_ACTDEF_WF, GMA_ACTCOL_WF_B, and GMA_ACTCOL_WF_TL for activity definitions, activity collections, and their translated descriptions, and GMA_ACTDATA_WF for activity-level data. Dynamic SQL assembly is supported through DBMS_SQL, consistent with the P_TABLE_NAME and P_WHERE_CLAUSE inputs of WF_GET_CONTORL_PARAMS. Together these tables supply the role assignments, approval flags, and enablement status that the package's functions return.

Usage Notes

GMA_WFSTD_P is normally invoked indirectly rather than by end users. Process Manufacturing workflow-enabled forms and concurrent programs call it during workflow launch and activity completion to resolve roles and to decide whether approval routing is required. Custom extensions that build workflow activities against the GMA item types may call the same procedures, but they should pass the exact item type, process name, and activity name values stored in the GMA definition tables, since all lookups are keyed on those values. Because the package is AUTHID CURRENT_USER and is referenced by sixteen other packages, changes to its specification would have wide impact; in 12.1.1 and 12.2.2 it should be treated as a stable, delivered interface and called rather than modified.