Search Results event_params

Overview

The FND_SVC_COMP_REQUESTS_H_V view is a reporting and integration interface owned by the APPS schema within the FND — Application Object Library product of Oracle E-Business Suite 12.1.1 and 12.2.2. The view presents a denormalized read layer over the service component request history data maintained by the Oracle EBS Service Components infrastructure, exposing both the identity of a service component and the historical record of requests raised against it. Because service component request processing occurs asynchronously in background processes, the history captured by this view provides the authoritative audit trail for component lifecycle activity, including status transitions and the events that triggered them.

The view is significant for administrators and developers who monitor component scheduling, diagnose failed requests, and build custom reporting on top of the service component framework without querying the underlying table directly. The naming convention follows standard EBS practice: the _V suffix denotes a view, while the _H segment of the base object indicates a history table.

Underlying Base Objects

The documented ETRM metadata identifies a single referenced base object for this view:

• FND_SVC_COMP_REQUESTS_H (synonym) — the service component request history table owned by APPS. The view is defined directly over this object through a simple projection with the alias CRH.

The view text is a straightforward SELECT from FND_SVC_COMP_REQUESTS_H CRH, listing all documented columns in sequence. There are no joins, filters, or aggregation applied in the view definition, meaning every row in the base history table is exposed and the view can be treated as an interface-stable alias. In EBS 12.2.2 the synonym resolution and Online Patching (ADOP) editioning model do not alter the behavior of the view; it remains a read-only wrapper suitable for use in reports, concurrent program queries, and diagnostic scripts.

Key Columns

The view projects the following columns from the history table:

• REQUEST_HISTORY_ID — Unique identifier for each historical request record; serves as the primary key for the view's rows.
• COMPONENT_ID, COMPONENT_NAME, COMPONENT_TYPE — Identify the service component and its classification.
• COMPONENT_STATUS — The status of the component itself at the time the request was recorded.
• CONTAINER_NAME, CONTAINER_TYPE — The container in which the component is registered, allowing grouping of related components.
• EVENT_NAME — The name of the event that prompted the recorded request; central to tracing cause and effect in component processing.
• EVENT_PARAMS — The parameter payload supplied with the event. This column is frequently the target of user searches because it holds the runtime arguments that drive component request handling.
• REQUEST_STATUS — The processing state of the request record, distinguishing completed, failed, or pending activity.
• COMPLETION_DATE — The timestamp at which the request reached completion; useful for duration and SLA analysis.
• REQUESTED_BY_USER, CREATED_BY — Audit columns identifying the requesting user and the record creator.
• OBJECT_VERSION_NUMBER — Optimistic locking/versioning column used by the framework for concurrency control.

Because the interface is a 1:1 projection, there are no derived or computed columns; the values correspond exactly to the base history table.

Common Use Cases and Queries

Typical usage centers on diagnosing service component behavior, auditing event execution, and reporting on request outcomes. A common starting point is locating records for a specific component or event, including an inspection of the event payload.

Example — retrieve recent history for a named component:

SELECT request_history_id, component_name, component_status,
       event_name, event_params, request_status, completion_date
FROM   apps.fnd_svc_comp_requests_h_v
WHERE  component_name = :p_component_name
ORDER  BY completion_date DESC;

Example — find requests by event and user for troubleshooting:

SELECT component_name, event_name, event_params,
       request_status, completion_date, requested_by_user
FROM   apps.fnd_svc_comp_requests_h_v
WHERE  event_name = :p_event_name
AND    requested_by_user = :p_user
AND    completion_date >= SYSDATE - 7;

Example — identify non-successful requests:

SELECT component_name, container_name, event_name,
       request_status, completion_date
FROM   apps.fnd_svc_comp_requests_h_v
WHERE  request_status <> 'COMPLETED';

Because the view performs no filtering, custom reports should always apply predicates on COMPLETION_DATE or COMPONENT_NAME to constrain the history scan. When deeper correlation with container or component registration data is required, join the view to the relevant service component tables on COMPONENT_ID or CONTAINER_NAME. In all cases, query the view under the APPS schema or an appropriately privileged account, since direct access to the underlying history table is not required and the view provides a stable interface across 12.1.1 and 12.2.2.