调用PA30事务后数据库回滚失效的技术咨询

Why We Use CALL TRANSACTION Instead of HR Function Modules #

When modifying infotype records, we rely on this code snippet:

CALL TRANSACTION 'PA30' USING gt_bdcdata OPTIONS FROM ls_ctu_params MESSAGES INTO et_mess

instead of standard modules like HR_INFOTYPE_OPERATION. The reason? Our system has legacy dynamic operations stored in table T588Z—these operations only trigger when executing the transaction directly, and won't run if we use the HR function modules. We need CALL TRANSACTION to ensure all business logic is properly executed.

The Rollback Challenge We're Facing #

After running PA30, we need to perform additional database operations. If those operations fail, we require a global rollback that undoes both the PA30 changes and the subsequent work. However, we've been unable to revert the database to its pre-PA30 state, even after trying these methods:

• Executing the ROLLBACK WORK statement
• Calling the BAPI_TRANSACTION_ROLLBACK function module
• Enabling the RACOMMIT flag in the ls_ctu_params structure

Why Rollback Isn't Working #

The core issue comes down to how commits interact with CALL TRANSACTION 'PA30':

1. Implicit Commit by Default: Unless configured otherwise, CALL TRANSACTION performs an implicit commit upon successful completion. This locks in PA30's changes before our subsequent operations even start.
2. Internal Commits in PA30: Even if we set RACOMMIT = 'X' to suppress the implicit commit from CALL TRANSACTION, PA30 itself may contain explicit COMMIT WORK statements in its code. These internal commits immediately persist the infotype changes, making them irreversible with a later rollback.

Potential Workarounds #

Since rolling back PA30 changes after they're committed isn't feasible, here are some strategies to mitigate the problem:

• Pre-Validation Checks: Run all necessary database checks and validations before invoking CALL TRANSACTION 'PA30'. Only execute the transaction if you're confident subsequent operations will succeed.
• Manual Reversal: Before running PA30, read the original state of the infotype record. If subsequent operations fail, use another CALL TRANSACTION 'PA30' or HR_INFOTYPE_OPERATION to restore the record to its original state.
• Update Task Wrapping: Wrap your subsequent database operations in an update task (CALL FUNCTION ... IN UPDATE TASK). If the update task fails, avoid triggering a final commit—but this only works if PA30 doesn't issue its own explicit commits (which it often does in practice).

内容的提问来源于stack exchange，提问作者Dorad