Results for “fnd_svc_comp_requests”

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

Overview

FND_SVC_COMP_REQUESTS is a table in the APPLSYS schema belonging to the FND — Application Object Library product within Oracle E-Business Suite 12.1.1 and 12.2.2. Its ETRM description is "Scheduled Service Component Events," which reflects its role as the repository of definitions describing when a given service component should be invoked or executed by the EBS service infrastructure. The table is a system-level object that stores scheduling metadata rather than transactional business data, and it is referenced by the concurrent and service-layer machinery that dispatches periodic or event-driven component activities.

The metadata classifies this object as VALID with a heuristic Data Vault classification of standalone. In Data Vault modeling terms, a standalone classification suggests the table may most naturally be modeled as either a standalone hub or a self-contained satellite, since the mined foreign-key structure reveals no dependency relationships to other objects. This is a modeling suggestion only; the physical table nonetheless stores both surrogate identity and descriptive scheduling attributes.

Key Information Stored

Each row represents a single scheduled component request. The 15 documented columns break into identity, scheduling, and audit groups.

• COMPONENT_REQUEST_ID — the primary key column (constraint FND_SVC_COMP_REQUESTS_P1). This is the surrogate identifier that uniquely distinguishes one scheduled request from another and is the value most commonly supplied when users search on "component_request_id".
• COMPONENT_ID — identifies the service component whose event is being scheduled.
• EVENT_NAME and EVENT_DATE — the name of the event to be raised and the date it is scheduled for.
• EVENT_FREQUENCY — defines the recurrence interval governing repeated execution of the component event.
• EVENT_PARAMS — parameter payload passed to the component when the event fires.
• REQUESTED_BY_USER and JOB_ID — capture the requesting user and the associated job, tying the request back to the submission context.
• ZD_EDITION_NAME — the editioning column; it participates with COMPONENT_REQUEST_ID in unique index FND_SVC_COMP_REQUESTS_U1, which is the documented business-key candidate.
• Standard WHO/audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — plus OBJECT_VERSION_NUMBER for optimistic locking.

The distinction between the surrogate primary key (COMPONENT_REQUEST_ID alone) and the composite unique index (COMPONENT_REQUEST_ID, ZD_EDITION_NAME) is important: the latter reflects the editioning model introduced in 12.2, where the same logical request can exist in multiple editions.

Common Use Cases and Queries

The table is typically queried during diagnosis of scheduled component activity — for example, to determine what events are pending for a component, what their recurrence is, and who requested them. A direct lookup by the searched term is straightforward:

• SELECT * FROM fnd_svc_comp_requests WHERE component_request_id = :id;
• SELECT component_id, event_name, event_date, event_frequency, job_id FROM fnd_svc_comp_requests WHERE component_id = :component_id ORDER BY event_date;
• Reporting on upcoming work uses EVENT_DATE filtering, optionally restricted to the current edition through ZD_EDITION_NAME.

Because the object sits in APPLSYS, queries should be run with appropriate privileges and generally treated as read-only for support and analysis purposes.

Related Objects

The mined relationship data records no foreign-key dependencies for this table, consistent with its standalone classification. Consequently, related objects are best identified through shared columns rather than enforced joins:

• Service component definition tables referenced by COMPONENT_ID.
• Concurrent job tables referenced by JOB_ID (for example FND_CONCURRENT_REQUESTS).
• User tables referenced by REQUESTED_BY_USER and CREATED_BY (FND_USER).
• Service-layer scheduling APIs and views that read EVENT_NAME, EVENT_DATE, and EVENT_FREQUENCY to dispatch component events.

No documented view or API is explicitly listed in the supplied metadata, so integrators should confirm dependencies against their specific EBS patch level before building custom joins.