Search Results create_transaction_snapshot




Overview
Explore in AI Chat

Overview

HR_TRANSACTION_SNAPSHOT_SWI is a seed/workflow integration (SWI) PL/SQL package owned by the APPS schema within Oracle E-Business Suite. Its purpose is to provide a programmatic layer over the HR_TRANSACTION_SNAPSHOT entity, which stores serialized transaction payloads captured during Oracle Human Resources (HR) processing. The package encapsulates the create, update, and delete lifecycle operations for transaction snapshot records, allowing callers to persist a document payload (a CLOB) together with an identifying object name and object identifier, and to maintain the object version number associated with each row.

Because it is declared with AUTHID CURRENT_USER, the package executes with the privileges of the invoking session rather than the owner, which means the caller must hold the appropriate HR schema and table privileges directly. The package name suffix "SWI" indicates it belongs to the family of integration APIs surfaced for internal and external consumption, complementing the base HR_TRANSACTION_SNAPSHOT API layer. It is documented as an OTHER-classification API in ETRM 12.2.2 and does not reference or get referenced by other packages in the dependency documentation.

Key Procedures and Functions

The package exposes three documented procedures:

  • CREATE_TRANSACTION_SNAPSHOT — Inserts a new transaction snapshot row. It accepts the document payload, an in/out snapshot identifier, an in/out object version number, the object name, the object identifier, and an optional validation flag defaulting to hr_api.g_false_num. This is the procedure matched by the search term "create_transaction_snapshot."
  • UPDATE_TRANSACTION_SNAPSHOT — Modifies an existing snapshot identified by P_SNAPSHOT_ID. It accepts the document payload together with the snapshot ID and an in/out object version number, and supports the same validate flag for optional validation of the operation.
  • DELETE_TRANSACTION_SNAPSHOT — Removes a snapshot row identified by P_SNAPSHOT_ID and P_OBJECT_VERSION_NUMBER. No document payload is required for deletion.

All three procedures use IN OUT NOCOPY parameters for the snapshot identifier and version number where applicable, reflecting the standard EBS optimistic locking convention: the object version number is checked before the DML and incremented on success. No parameters have been invented beyond those present in the packaged specification header.

Tables Accessed

The package operates against the HR_TRANSACTION_SNAPSHOT table, referenced through APPS synonyms. The document CLOB passed into the create and update procedures is stored in this table, alongside identifying attributes such as object name and object identifier and the managed object version number. In practice the table functions as a durable store of transaction payloads that can be retrieved, replayed, or audited by downstream HR processes. Because the package relies on APPS synonyms, the underlying table resides in the HR schema and is accessible to APPS-based code through the synonym layer.

Usage Notes

HR_TRANSACTION_SNAPSHOT_SWI is typically invoked from server-side PL/SQL — either from within HR business logic, from concurrent program bodies, or from custom extensions that need to capture or maintain transaction snapshots. It is not a user-facing API and is not associated with a form or a standalone concurrent program in the documented metadata. Because it is AUTHID CURRENT_USER and holds no direct cross-schema grants, custom callers invoked by the APPS user can reference the package directly, whereas other schema owners must be granted EXECUTE and possess the necessary HR table privileges. The validation parameter defaults to hr_api.g_false_num, so callers that require full business-rule validation must explicitly pass hr_api.g_true_num. The absence of recorded package dependencies indicates the module is largely self-contained and relies on the underlying table and HR API globals rather than on other documented APIs.