Search Results cp_phase_code




Overview
Explore in AI Chat

Overview

APPS.OKC_QUE_WF_V is a reporting view within the Oracle E-Business Suite Contracts (OKC) module that exposes the results of the Oracle Workflow Background Process (FNDWFBG) as it applies specifically to contracts alert processing. It presents a filtered, human-readable snapshot of concurrent requests submitted with the argument OKCALERT, allowing technical and functional users to monitor the health, phase, and status of the workflow engine that drives Contracts-related notifications and lifecycle events. Because the Contract Lifecycle Management (CLM) and OKC modules depend heavily on the Workflow Background Process to evaluate contract terms, deliverables, and alert conditions, this view serves as a diagnostic and administrative window into that infrastructure. It is stored under the APPS schema and is not a base table, so it carries no storage of its own; its output is derived at query time from the standard concurrent manager and user tables. The view is available in both 12.1.1 and 12.2.2, and the documented metadata in ETRM 12.2.2 confirms its owner, referenced objects, and text.

Underlying Base Objects

The view is defined over four synonym-referenced base tables and one package. FND_CONCURRENT_PROGRAMS (aliased PB) supplies the internal concurrent program definition; FND_CONCURRENT_PROGRAMS_TL (aliased PT) supplies the translated, user-facing program name and description, joined on the language environment variable USERENV('LANG'). FND_USER (aliased U) resolves REQUESTED_BY to a user name. FND_CONCURRENT_REQUESTS (aliased R) is the primary fact source, holding each submitted request row. Joins are established on PROGRAM_APPLICATION_ID/CONCURRENT_PROGRAM_ID. The OKC_UTIL package is invoked via its DECODE_LOOKUP function to translate coded phase and status values into display text. Critically, the WHERE clause restricts output to PB.CONCURRENT_PROGRAM_NAME = 'FNDWFBG' and R.ARGUMENT1 = 'OKCALERT', and further limits rows to those not yet complete, or complete but ending in error: ( R.PHASE_CODE <> 'C' OR ( R.PHASE_CODE = 'C' AND R.STATUS_CODE = 'E' ) ). This makes the view an exception-and-progress monitor for the Contracts alert workflow.

Key Columns

  • REQUEST_ID — the concurrent request identifier, the natural key for the submitted Workflow Background Process run.
  • LISTENER — a DECODE expression returning the translated program name, or the request description concatenated with the program name when a description exists.
  • CONCURRENT_PROGRAM — the internal concurrent program name, always FNDWFBG given the filter.
  • PHASE / PHASE_CODE — the phase presented both as decoded lookup text (via OKC_UTIL.DECODE_LOOKUP with lookup type 'CP_PHASE_CODE') and as the raw code. This is the column the user's search term cp_phase_code references.
  • STATUS / STATUS_CODE — the run status, decoded through lookup type 'CP_STATUS_CODE' alongside the raw value.
  • APPLICATION_ID — the responsibility application context of the request.
  • SUBMISSION_DATE — the request submission date.
  • USER_NAME — the EBS user who submitted the request.
  • COMPLETION_TEXT — the completion message from the concurrent manager, useful for diagnosing failures.

Common Use Cases and Queries

The primary use case is operational monitoring of the Contracts alert workflow, supporting administrators who need to confirm that the background process is running and to identify errored executions requiring intervention. A typical query selects the decoded phase and status alongside the submission and user details:

SELECT request_id, listener, phase, status, submission_date, user_name, completion_text FROM apps.okc_que_wf_v ORDER BY submission_date DESC;

Because PHASE_CODE and STATUS_CODE are exposed in raw form, users can additionally reassemble the standard concurrent manager code set — for example, filtering WHERE phase_code = 'R' to find requests still running, or WHERE phase_code = 'C' AND status_code = 'E' to isolate failures, which the view's own predicate already surfaces. The cp_phase_code lookup referenced in the definition is the FND lookup type providing the friendly labels, so joining or decoding against FND_LOOKUP_VALUES under that lookup type is a common complement. The view is read-only and should not be updated or used as a data source for workflow resubmission; resubmission is performed through the standard Submit Requests form or the FND_REQUEST API.