Results for “left_parenthesis”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CSC_CONDITION_FUNCTION_V is a reporting and integration view owned by the APPS schema within the CSC (Customer Care) product family of Oracle E-Business Suite, valid in releases 12.1.1 and 12.2.2. It presents the function-type condition lines that participate in the rules engine of Oracle TeleService / Customer Care, exposing each condition line together with the fully qualified name of the process (procedure or packaged procedure) against which the condition is evaluated. The view is a classic "presentation layer" object: it flattens and joins the nested condition-line structure to its process definition, so report authors, Oracle Discoverer workbooks, OAF pages, and custom PL/SQL can retrieve human-readable rule components without re-implementing the underlying joins. Its NAME column in particular resolves the DEFINE process by concatenating the package and procedure names, making it far more usable than raw foreign keys.

Underlying Base Objects

The view is defined exclusively over two other views, not over base tables:

• OKC_CONDITION_LINES_V (alias OCL) — supplies the condition-line detail: identifier, sort sequence, parentheses, the parent condition header, the AAE (Application Attribute / attribute) reference, the condition line type, and the PDF reference.
• OKC_PROCESS_DEFS_V (alias OPD) — supplies the process definition row, specifically the package and procedure name that constitute the executable function.

The join is OCL.PDF_ID = OPD.ID AND OCL.CNL_TYPE = 'FEX', so only condition lines of type FEX (function/expression) are returned, and each is matched to exactly one process definition. Note that OKC_PROCESS_DEFS_V is the underlying object most closely associated with the user's original search string, "okc_process_defs_v"; CSC_CONDITION_FUNCTION_V is effectively the CSC-facing, function-filtered projection of that structure. Because both parents are views, the lineage ultimately traces to the OKC (Oracle Knowledge/Contracts-condition) condition and process-definition tables.

Key Columns

• ID — identifier of the condition line (OCL.ID), the row's primary handle.
• SORTSEQ — ordering sequence controlling the evaluation order of condition lines within a rule.
• LEFT_PARENTHESIS / RIGHT_PARENTHESIS — grouping parentheses used to reconstruct the boolean expression text.
• PDF_ID — foreign key to the process definition (OKC_PROCESS_DEFS_V.ID).
• LOGICAL_OPERATOR — the AND/OR connector joining this line to adjacent lines.
• AAE_ID — reference to the application attribute / entity used by the condition.
• CNH_ID — parent condition header identifier, tying lines to a condition set.
• CNL_TYPE — condition line type; always 'FEX' in this view by definition of the filter.
• NAME — the resolved executable name, computed as DECODE(OPD.PACKAGE_NAME, NULL, OPD.PROCEDURE_NAME, OPD.PACKAGE_NAME||'.'||OPD.PROCEDURE_NAME). Standalone procedures yield the bare procedure name; packaged procedures yield PACKAGE.PROCEDURE.

Common Use Cases and Queries

Typical scenarios include documenting which functions a condition calls, auditing condition-line ordering and boolean logic, and feeding rule metadata into custom reports. A representative query lists all function conditions for a given condition header:

SELECT id, sortseq, left_parenthesis, logical_operator, right_parenthesis, name
FROM apps.csc_condition_function_v
WHERE cnh_id = :p_condition_header_id
ORDER BY sortseq;

To locate every condition that invokes a particular packaged procedure:

SELECT cnh_id, id, sortseq, name
FROM apps.csc_condition_function_v
WHERE name LIKE 'MY_PKG.%';

Because the view is read-only and built on validated OKC views, it is safe for direct querying from BI Publisher, Discoverer, and ad-hoc SQL in both 12.1.1 and 12.2.2; no DML should ever be directed at it. All queries must be issued from a session with APPS or an appropriately granted custom schema.