Search Results delete_transaction_steps

Overview

APPS.HR_TRANSACTION_SWI is the server-side work interface (SWI) layer that underpins the Oracle E-Business Suite HR Management transaction framework. Its principal business function is to create, maintain, and persist HR self-service and administrative transactions — such as personal details changes, assignment updates, appraisal actions, and other Oracle Approvals Management routed requests — in a consistent, auditable manner. The package encapsulates the full transaction lifecycle, including initialization, status transitions, validation, cancellation, and deletion, and acts as the programmatic gateway through which Forms, OA Framework pages, and concurrent programs record and advance HR transactions.

Classified as an OTHER API under the ETRM 12.2.2 catalog, HR_TRANSACTION_SWI is owned by APPS and operates with AUTHID CURRENT_USER, meaning its unqualified references and privileges are resolved in the context of the calling schema. It is a heavily load-bearing object: it is referenced by 36 other packages, confirming that numerous HR modules and dependent APIs delegate transaction persistence to it rather than writing to the underlying tables directly.

Key Procedures and Functions

The package exposes 28 documented procedures and functions. The central routines include:

• create_transaction — the principal creator of an HR transaction record. It accepts a large set of optional attributes covering the transaction identity, privilege, product code, URL, status, section display name, function, transaction type, assignment, effective date, plan and reporting group, parent transaction, and transaction document, and supports an optional validation mode.
• create_transaction_step / update_transaction_step / delete_transaction_step — manage the individual steps that comprise a multi-step transaction.
• update_transaction and delete_transaction — modify or remove an existing transaction.
• set_transaction_context and set_person_context — establish the session and person context required before subsequent transaction operations, following the standard HR API context-setting convention.
• init_profiles — initializes package-level profile and global values (such as g_date_format).
• getdatevalue, getvarchar2value, and getnumbervalue — typed accessor functions that return formatted transaction attribute values in the appropriate data type.
• set_status and settransactionstatus — update the status of a transaction as it progresses through its lifecycle.
• process_api_call and process_api_internal — the API dispatch logic that interprets a transaction's configuration and invokes the appropriate business logic; these are central to how a transaction request translates into a concrete HR action.
• convertclobtoxmlelement — converts CLOB-based transaction documents into XML DOM elements for processing.
• isdeleteallowed, iseditallowed, and cancelaction — enforce business rules governing whether a transaction may be edited, deleted, or cancelled given its current state.

Tables Accessed

HR_TRANSACTION_SWI reads and writes a defined set of tables through APPS synonyms. Transaction state is persisted in HR_API_TRANSACTIONS and HR_API_TRANSACTION_STEPS, the primary storage for transactions and their constituent steps. Person and assignment data are drawn from PER_ALL_PEOPLE_F and PER_ALL_ASSIGNMENTS_F, while appraisal actions reference PER_APPRAISALS. Flexfield validation against FND_ID_FLEX_STRUCTURES, menu/function lookups against FND_FORM_FUNCTIONS, and message resolution against FND_NEW_MESSAGES support the API's setup and validation logic. Workflow integration is achieved through WF_ITEMS and WF_ITEM_ACTIVITY_STATUSES. Additional descriptive data is obtained from HR_ALL_ORGANIZATION_UNITS_TL, HR_ALL_POSITIONS_F_TL, PER_JOBS_TL, and HR_ORGANIZATION_INFORMATION, while XMLDOM supports XML document handling during conversion.

Usage Notes

HR_TRANSACTION_SWI is not intended for direct end-user invocation. It is called programmatically from HR self-service Forms, OA Framework pages, and concurrent programs that need to persist or advance an HR transaction. Callers typically begin by invoking set_transaction_context or set_person_context, then init_profiles, before creating or updating transactions. Because the package is referenced by 36 other packages, modifications to its behavior can cascade widely across HR functionality. Custom code extending HR transactions should invoke the documented entry points rather than manipulating HR_API_TRANSACTIONS and related tables directly, preserving the validation, workflow, and status-consistency guarantees the SWI layer provides.