Posted: Fri Oct 14, 2022 11:18 am Post subject: Error Handling for Bundled Updates
Runtime errors can occur during execution of bundled updates. How are they handled? In general, COMMIT WORK processing occurs in the following order:
1) All dialog-task FORM routines logged with PERFORM ON COMMIT are executed.
2) All high-priority (V1) update-task function modules are executed.
The end of V1-update processing marks the end of the . If you used COMMIT WORK AND WAIT to trigger commit processing, control returns to the dialog-task program.
3) All low-priority (V2) update-task function modules are triggered.
All background-task function modules are triggered.
Runtime errors can occur either in the system itself, or because your program issues an termination message (MESSAGE type ‘A’). Also, the ROLLBACK WORK statement automatically signals a runtime error. The system handles errors according to where they occur:
in a FORM routine (called with PERFORM ON COMMIT)
Updates already executed for the current update transaction are rolled back.
No other FORM routines will be started.
No further update-task or background-task functions will be started.
An error message appears on the screen.
in a V1 update-task function module (requested IN UPDATE TASK)
Updates already executed for V1 functions are rolled back.
All further update-task requests (V1 or V2) are thrown away.
All background-task requests are thrown away.
Updates already executed for FORM routines called with PERFORM ON COMMIT are not rolled back.
An error message appears on the screen, if your system is set up to send them
in a V2 update-task function module (requested IN UPDATE TASK)
Updates already executed for the current V2 function are rolled back.
All update-task requests (V2) still to be executed are discarded.
All background-task requests still to be executed are carried out.
No updates for previously executed V1 functions are rolled back.
No updates previously executed for FORM routines (called with ON COMMIT) are rolled back.
An error message appears on the screen, if your system is set up to send them
in a background-task function module (requested IN BACKGROUND TASK DESTINATION)
Background-task updates already executed for the current DESTINATION are not rolled back.
All further background-task requests for the same DESTINATION are thrown away.
Other previously executed updates are rolled back.
No error message appears on the screen.
If your program detects that an error in remote processing has occurred, it can decide whether to resubmit the requests at a later time.
For further information about RFC processing, refer to the Remote Communications documentation.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
All product names are trademarks of their respective companies. SAPNET.RU websites are in no way affiliated with SAP AG. SAP, SAP R/3, R/3 software, mySAP, ABAP, BAPI, xApps, SAP NetWeaver and any other are registered trademarks of SAP AG. Every effort is made to ensure content integrity. Use information on this site at your own risk.