Search Results completion_text

Overview

OKC_QUE_WF_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OKC – Contracts Core product family. It presents a filtered, presentation-ready projection of Oracle Workflow background processing requests that are associated with the Contracts Core alerting mechanism. Specifically, the view exposes rows from FND_CONCURRENT_REQUESTS for the concurrent program FNDWFBG (the Workflow Background Process) where the request argument ARGUMENT1 equals the literal value 'OKCALERT'. This ties the view directly to Contracts Core alert and notification processing executed through the Workflow background engine.

The view plays a narrow but useful integration and reporting role: it decouples consumers from the raw, code-heavy FND_CONCURRENT_REQUESTS table by decoding lookup values and resolving program and user identifiers into readable names. Because the view remains valid across EBS 12.1.1 and 12.2.2, administrators and developers can rely on identical behavior between those releases. It is commonly used in diagnostics, operational dashboards, and support queries that need to determine whether Contracts Core alerts have been submitted and what their current lifecycle state is.

Underlying Base Objects

The view is defined over four synonym-referenced base objects and one PL/SQL package, as documented in the ETRM metadata:

• FND_CONCURRENT_REQUESTS – the driving table (aliased R), supplying request identity, phase, status, arguments, submission date, responsibility application, requesting user, and completion text.
• FND_CONCURRENT_PROGRAMS – the base concurrent program definition (aliased PB), joined on PROGRAM_APPLICATION_ID and CONCURRENT_PROGRAM_ID.
• FND_CONCURRENT_PROGRAMS_TL – the translated program name table (aliased PT), joined to PB on application and program identifiers and restricted to the session language via USERENV('LANG').
• FND_USER – the application user table (aliased U), joined on USER_ID = REQUESTED_BY to resolve the submitting user name.
• OKC_UTIL – a Contracts Core PL/SQL package whose DECODE_LOOKUP function translates the CP_PHASE_CODE and CP_STATUS_CODE lookup codes into descriptive phase and status values.

Key Columns

• REQUEST_ID – The unique concurrent request identifier; the primary join key back to FND_CONCURRENT_REQUESTS.
• LISTENER – A derived display value that concatenates the request description with the concurrent program name, or falls back to the program name when no description exists.
• CONCURRENT_PROGRAM – The concurrent program name, which for this view is constrained to FNDWFBG.
• PHASE / PHASE_CODE – The decoded and raw phase of the request (for example Pending, Running, Completed).
• STATUS / STATUS_CODE – The decoded and raw status code, indicating normal termination, error, warning, or in-progress states.
• APPLICATION_ID – The responsibility application identifier associated with the request.
• SUBMISSION_DATE – The request date, exposed under this alias; this column is the primary target of submission-date searches and time-based reporting.
• USER_NAME – The application user who submitted the request.
• COMPLETION_TEXT – The completion message returned by the concurrent manager.

Common Use Cases and Queries

Because the view filters to the FNDWFBG program with ARGUMENT1 = 'OKCALERT' and excludes completed requests unless they ended in error, it is effectively an operational exception report for Contracts Core alert workflow processing. Typical queries order by SUBMISSION_DATE to review recent activity or isolate failures.

• List failing alert workflow requests submitted in the last week.
• Retrieve all alert requests submitted by a specific user, ordered by SUBMISSION_DATE.
• Correlate submission dates with error text to diagnose repeating failures.

Sample query:

SELECT request_id, concurrent_program, phase, status, submission_date, user_name, completion_text
FROM okc_que_wf_v
WHERE submission_date >= SYSDATE - 7
ORDER BY submission_date DESC;

For pending or in-flight requests, the phase and status columns should be inspected directly, since the view retains them for all non-completed rows and for completed rows only when the status code is 'E' (Error).