Search Results fnd_cp_services_pk

Overview

FND_CP_SERVICES is a table owned by the APPLSYS schema within the FND — Application Object Library product of Oracle E-Business Suite. Its documented description is simply "Service Information," identifying it as the repository that defines the services known to the Concurrent Processing (CP) framework and the broader FND service-management infrastructure. In Oracle EBS 12.1.1 and 12.2.2, this table governs how the application server tier registers, exposes, and constrains runtime services — the configurable units of work that administrators start, stop, suspend, verify, and parameterize through the Oracle Applications Manager (OAM) interface.

From a Data Vault modeling perspective, the heuristic classification supplied in the metadata is standalone. This suggests that, in a dimensional or Data Vault-style model, FND_CP_SERVICES is best treated as an independent hub-like entity rather than a link or satellite: its rows are not documented as dependent on foreign-key parents, and the table carries its own natural business keys. Each row represents one service definition, keyed by the surrogate SERVICE_ID and constrained by edition-aware unique indexes.

Key Information Stored

The documented schema contains 34 columns. The most consequential are:

• SERVICE_ID — the surrogate primary key, enforced by FND_CP_SERVICES_PK. It is the single-column identifier referenced throughout the CP metadata model.
• SERVICE_HANDLE and SERVICE_NAME — the business identifiers for the service. SERVICE_HANDLE is a business-key candidate, participating in the unique index FND_CP_SERVICES_U1 (along with ZD_EDITION_NAME), while SERVICE_ID and ZD_EDITION_NAME form FND_CP_SERVICES_U2.
• CARTRIDGE_HANDLE and CARTRIDGE_APPLICATION_ID — associate the service with its owning cartridge and application, linking the service to the FND product registration model.
• SERVICE_CLASS and SERVICE_INSTANCE_CLASS — the implementation classes instantiated when the service is created or executed.
• Permission and lifecycle flags — ALLOW_START, ALLOW_RESTART, ALLOW_SUSPEND, ALLOW_VERIFY, ALLOW_PARAMETER, ALLOW_CREATE, ALLOW_EDIT, and ALLOW_RCG — control which administrative operations are permitted.
• Concurrency and placement controls — ALLOW_MULTIPLE_PROC_INSTANCE, ALLOW_MULTIPLE_PROC_NODE, and ALLOW_MULTIPLE_PROC_SI — govern whether multiple processing instances, nodes, or service instances may run concurrently.
• Debug and recovery behavior — DEFAULT_DEBUG_LEVEL, DEBUG_TYPE, DEBUG_CHANGE_ACTION, PARAMETER_CHANGE_ACTION, and MIGRATE_ON_FAILURE — define diagnostic and failover semantics.
• ENABLED and OAM_DISPLAY_ORDER — control whether the service is active and how it is presented in the OAM console.
• ENV_FILE_NAME and DEVELOPER_PARAMETERS — point to environment configuration and developer-supplied parameters.
• Standard audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN.
• ZD_EDITION_NAME — the editioning column that participates in both unique indexes on 12.2.2, reflecting the online patching (Edition-Based Redefinition) architecture.

Common Use Cases and Queries

Administrators and developers query FND_CP_SERVICES to audit which services are enabled and how they are permitted to behave. A typical inventory query runs:

• SELECT service_id, service_name, service_handle, enabled FROM applsys.fnd_cp_services WHERE enabled = 'Y' ORDER BY oam_display_order;
• Identifying services that allow concurrent execution across nodes: SELECT service_name FROM applsys.fnd_cp_services WHERE allow_multiple_proc_node = 'Y';
• Auditing debug and parameter configuration before troubleshooting: SELECT service_name, default_debug_level, parameter_change_action FROM applsys.fnd_cp_services WHERE allow_parameter = 'Y';

Reporting scenarios include service inventory reconciliation after patching, verifying edition-scoped rows via ZD_EDITION_NAME in 12.2.2, and confirming which services permit restart or suspend before planning maintenance windows.

Related Objects

The metadata classifies FND_CP_SERVICES as standalone, meaning no foreign keys are documented as originating from or referencing it directly. In practice, the table is consumed by the CP service-management layer and referenced through its surrogate key SERVICE_ID by service-instance and parameter definitions maintained under the same cartridges identified by CARTRIDGE_HANDLE and CARTRIDGE_APPLICATION_ID. Administrators typically correlate it with FND_APPLICATION through CARTRIDGE_APPLICATION_ID, with the OAM service console views that render SERVICENAME and ENABLED, and with concurrent-processing diagnostic queries that join on SERVICE_ID. Because the documented relationship data is limited, integrators should confirm exact join paths against the target 12.1.1 or 12.2.2 instance before relying on them.