Search Results fnd_cp_services_u2

Overview

The APPLSYS.FND_CP_SERVICES table is a seed data repository within the Oracle E-Business Suite Applications Object Library (APPLSYS) schema. It stores the definition of every service known to the Concurrent Processing and Application Service architecture — the metadata that the Internal Concurrent Manager (ICM) and Application Service Manager rely upon to start, monitor, suspend, restart, and migrate service processes across an EBS environment. Each row constitutes a service definition, identified by the surrogate primary key FND_CP_SERVICES_PK on SERVICE_ID, and indexed by two unique business keys: FND_CP_SERVICES_U1 (SERVICE_ID, ZD_EDITION_NAME) and FND_CP_SERVICES_U2 (SERVICE_HANDLE, ZD_EDITION_NAME). The physical schema is owned by APPLSYS and resides in the APPS_TS_SEED tablespace, with PCTFREE 10, reflecting its role as a low-volume, read-intensive reference table rather than a transactional one.

From a Data Vault modeling perspective, the mined ETRM classification labels this object standalone. That classification is best treated as a heuristic suggestion: FND_CP_SERVICES behaves as a hub-like reference entity, since SERVICE_HANDLE (the developer key) and SERVICE_ID (the sequence-generated surrogate) are natural and surrogate keys respectively, and there is no documented foreign-key dependency linking it to another table in the vault. Practitioners modeling EBS reference data may therefore treat it as an independent hub rather than a satellite or link.

The table is edition-aware. Both unique indexes include ZD_EDITION_NAME, and the object participates in the EBS Online Patching (adop) model introduced in 12.2.x, allowing multiple editions of service definitions to coexist while a patch cycle is in progress. This matters for the queried index name, since FND_CP_SERVICES_U1 is an edition-qualified unique index rather than a plain single-column index.

Key Information Stored

The 34 documented columns fall into several functional groups. The most significant are:

• SERVICE_ID — NUMBER(15), the unique identifier generated from a sequence, and the object's primary key.
• SERVICE_HANDLE — the developer key for the service; the alternate unique business key in FND_CP_SERVICES_U2.
• SERVICE_NAME — VARCHAR2(240), the display name shown in the system administration interface.
• CARTRIDGE_HANDLE and CARTRIDGE_APPLICATION_ID — identify the cartridge and application to which the service belongs.
• SERVER_TYPE — indicates the applications server type on which the service runs.
• SERVICE_CLASS and SERVICE_INSTANCE_CLASS — the implementation classes instantiated for the service and its instances.
• ALLOW_MULTIPLE_PROC_INSTANCE, ALLOW_MULTIPLE_PROC_NODE, ALLOW_MULTIPLE_PROC_SI — control whether multiple service processes may run per Apps instance, per node, or per service instance.
• ALLOW_START, ALLOW_RESTART, ALLOW_SUSPEND, ALLOW_VERIFY, ALLOW_CREATE, ALLOW_EDIT, ALLOW_RCG, ENABLED — permission and lifecycle flags governing what operations the ICM may perform.
• MIGRATE_ON_FAILURE — whether the process may be relocated to a secondary node on primary-node failure.
• PARAMETER_CHANGE_ACTION and DEBUG_CHANGE_ACTION — actions taken when parameters or debug settings change at a work-shift boundary.
• DEVELOPER_PARAMETERS — VARCHAR2(2000), the developer-defined parameter string associated with a work shift.
• ENV_FILE_NAME — the environment file associated with the service.
• LAST_UPDATE_DATE, CREATED_BY, LAST_UPDATED_BY, CREATION_DATE — the standard EBS WHO columns.

The surrogate key SERVICE_ID is distinct from the business keys SERVICE_HANDLE and the edition segment. The ZD_EDITION_NAME column, present in both unique indexes, is the edition discriminator applied by Online Patching.

Common Use Cases and Queries

Administrators and developers query this table to inventory service definitions, audit which services are enabled, and diagnose concurrent manager startup behavior. Typical patterns include:

• Enumerating all enabled services with their display names and handles.
• Identifying services permitted to restart automatically after abnormal termination.
• Reviewing which services support migration on failure for high-availability planning.
• Auditing service definitions belonging to a specific cartridge or application.

Representative SQL includes selecting SERVICE_ID, SERVICE_HANDLE, SERVICE_NAME, SERVER_TYPE, ENABLED from APPLSYS.FND_CP_SERVICES where ENABLED = 'Y', or filtering on ALLOW_RESTART = 'Y' to list restart-eligible services. When validating an edition-aware result set, queries should include ZD_EDITION_NAME to avoid returning duplicate rows across editions. Joining to FND_APPLICATION on CARTRIDGE_APPLICATION_ID yields the owning application name for reporting.

Related Objects

Although the mined Data Vault structure is standalone, the table is referenced logically by several EBS objects:

• FND_CP_SERVICE_PROCESSES — service process instances tied to a definition via SERVICE_HANDLE or SERVICE_ID.
• FND_CONCURRENT_QUEUES — concurrent managers whose services derive from these definitions.
• FND_NODES and FND_NODE_CONFIG — node-level service configuration referencing SERVER_TYPE.
• FND_APPLICATION — joined via CARTRIDGE_APPLICATION_ID.
• FND_CP_SERVICES_TL — translation table for SERVICE_NAME where applicable.
• FND_SVC_COMPONENTS and the Service Manager / ICM APIs — runtime consumers of these definitions.

Because no primary-key-to-foreign-key relationships were mined, joins to these objects are application-level rather than enforced by database constraints.