Search Results env_file_name

Overview

FND_CP_SERVICES_VL is a validated view owned by the APPS schema within the FND – Application Object Library product. The name and column set identify it as part of the Concurrent Processing service-registration layer: the view acts as the runtime registry that the Concurrent Manager reads to determine which services (internal managers, transaction managers, and related processing cartridges) are available, how each may be started or restarted, and under what constraints. Practical use of the view is primarily diagnostic and integration-oriented. Administrators and developers query it to reconcile the configured service catalogue against what the internal concurrent manager reports, and integrations read the service characteristics (start/restart permissions, debug behaviour, environment file references) to drive automated management or monitoring routines. Because it is a "VL" view, it returns the base-row attributes from FND_CP_SERVICES joined to the language-translated name and description in FND_CP_SERVICES_TL, filtered to the session language, so consumers see a single row per service in the language of the executing session.

Underlying Base Objects

The documented ETRM metadata references two base objects for this view: FND_CP_SERVICES (SYNONYM) and FND_CP_SERVICES_TL (SYNONYM), both resolving under APPS. The view definition confirms a two-table join, aliased B and T respectively, on B.SERVICE_ID = T.SERVICE_ID, with the additional translation predicate T.LANGUAGE = USERENV('LANG'). All non-translatable attributes, including ENV_FILE_NAME, SERVICE_HANDLE, SERVER_TYPE, and the ALLOW_* flags, originate from the base table; only SERVICE_NAME, DESCRIPTION, and SERVICE_PLURAL_NAME come from the translation table. The view additionally projects B.ROWID as ROW_ID, preserving a row identifier for the underlying base row.

Key Columns

• ENV_FILE_NAME — the environment file associated with the service, used to establish process environment before the service is launched.
• SERVICE_ID / SERVICE_NAME / SERVICE_PLURAL_NAME — the internal identifier and the translated display (singular and plural) labels.
• SERVICE_HANDLE / CARTRIDGE_HANDLE / SERVICE_CLASS / SERVICE_INSTANCE_CLASS — routing and implementation references that tie the service to its executable logic and cartridge.
• SERVER_TYPE — the processing role of the service.
• ALLOW_VERIFY, ALLOW_SUSPEND, ALLOW_START, ALLOW_RESTART, ALLOW_CREATE, ALLOW_EDIT, ALLOW_PARAMETER, ALLOW_RCG, ALLOW_MULTIPLE_PROC_NODE, ALLOW_MULTIPLE_PROC_INSTANCE, ALLOW_MULTIPLE_PROC_SI — governance flags controlling permitted administrative operations and multi-instance behaviour.
• MIGRATE_ON_FAILURE, PARAMETER_CHANGE_ACTION, DEBUG_CHANGE_ACTION, DEBUG_TYPE, DEFAULT_DEBUG_LEVEL — failover, parameter-restart, and debugging behaviour.
• ENABLED — whether the service is currently active.
• CARTRIDGE_APPLICATION_ID, OAM_DISPLAY_ORDER, DEVELOPER_PARAMETERS — product association, UI ordering, and developer-supplied parameters.
• Standard audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE, plus ROW_ID.

Common Use Cases and Queries

A frequent requirement is locating the environment file for a named service, which is the natural entry point when the search term is env_file_name:

• SELECT service_id, service_name, env_file_name FROM fnd_cp_services_vl WHERE service_name = :p_service_name; — confirms which environment file a service resolves to.
• SELECT service_name, server_type, enabled FROM fnd_cp_services_vl WHERE env_file_name IS NOT NULL ORDER BY service_name; — enumerates all services with an associated environment file, useful when auditing environment dependencies prior to a migration or clone.
• SELECT service_name, allow_start, allow_restart, allow_verify FROM fnd_cp_services_vl WHERE enabled = 'Y'; — reports which services the manager may legitimately start or restart.
• SELECT service_name, debug_type, default_debug_level FROM fnd_cp_services_vl WHERE debug_type IS NOT NULL; — identifies services configured for debug behaviour, typically during incident triage.

Because the underlying objects are documented as APPS synonyms, queries should be issued from a session with APPS synonym resolution (for example, an APPS or custom schema with the standard synonyms) and appropriate read privileges. All identifiers and attributes above are drawn from the documented view definition; behaviour not specified in the metadata should be confirmed against the actual database.