Results for “object_identifier”

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

Overview

PQH_SS_STEP_HISTORY is a transactional audit table in the HR schema belonging to the PQH (Public Sector HR) product family within Oracle E-Business Suite 12.1.1 and 12.2.2. It records the individual processing steps executed against a self-service transaction, capturing the sequence of workflow activities, API invocations, and object-state transitions that occur as a transaction moves through the Oracle Approvals Management and workflow engine. Each row represents a single step in the lifecycle of a self-service transaction, complementing the parent approval and transaction history records.

From a heuristic Data Vault modeling perspective, the mined FK structure classifies this table as standalone with satellite-like characteristics: it stores descriptive, time-stamped context around a business event (the transaction step) rather than acting as a pure hub or link. The presence of CREATED_BY, CREATION_DATE, LAST_UPDATE_DATE, and LAST_UPDATED_BY aligns with the audit-column conventions typical of Oracle EBS transactional satellites.

Key Information Stored

The table contains 54 columns in the documented 12.2.2 schema. The most consequential include:

• STEP_HISTORY_ID — surrogate primary key uniquely identifying each step record.
• APPROVAL_HISTORY_ID — links the step to the approval history record for the parent transaction.
• TRANSACTION_HISTORY_ID — foreign key to AR_TRANSACTION_HISTORY_ALL, tying the step to the underlying transaction history row.
• API_NAME / API_DISPLAY_NAME — the internal and user-facing names of the API executed at this step.
• PROCESSING_ORDER — sequence number establishing the ordering of steps within a transaction.
• OBJECT_TYPE / OBJECT_NAME / OBJECT_IDENTIFIER / OBJECT_STATE — describe the object affected and its resulting state after the step.
• ITEM_TYPE / ITEM_KEY — the workflow item type and key, identifying the specific workflow instance.
• ACTIVITY_ID — the workflow activity associated with the step.
• INFORMATION_CATEGORY through INFORMATION30 — a wide set of generic context slots used to carry step-specific parameters and diagnostic values.
• CREATED_BY / CREATION_DATE / LAST_UPDATE_DATE / LAST_UPDATED_BY / LAST_UPDATE_LOGIN — standard EBS audit columns.

The surrogate key is STEP_HISTORY_ID; business-key candidates are TRANSACTION_HISTORY_ID combined with PROCESSING_ORDER, which together identify a unique step position within a transaction.

Common Use Cases and Queries

Typical uses include troubleshooting failed self-service transactions, auditing the sequence of API calls during a workflow, and reporting on processing latency between steps.

• Retrieve all steps for a specific transaction in processing order:
  SELECT step_history_id, processing_order, api_name, object_state, creation_date FROM pqh_ss_step_history WHERE transaction_history_id = :txn_id ORDER BY processing_order;
• Identify steps that resulted in an error state by filtering OBJECT_STATE.
• Join to AR_TRANSACTION_HISTORY_ALL on TRANSACTION_HISTORY_ID to correlate steps with the transaction header.
• Measure elapsed time between consecutive steps using PROCESSING_ORDER and CREATION_DATE for performance analysis.

Related Objects

• AR_TRANSACTION_HISTORY_ALL — referenced by TRANSACTION_HISTORY_ID; the principal join target for transaction context.
• PQH_SS_APPROVAL_HISTORY — parent of APPROVAL_HISTORY_ID, holding approval-level detail.
• WF_ITEM_TYPES / WF_ACTIVITIES — resolve ITEM_TYPE and ACTIVITY_ID to workflow definitions.
• FND_LOG_MESSAGES — often correlated with API_NAME for detailed error diagnostics.
• PQH_SS_TRANSACTION_HISTORY — complementary history view at the transaction level.