- SAP Managed Tags:
This article describes the BOPF Synchronization Points functionality. Target audience is ABAP architects and developers, anyone who is strong in BOPF and wants to know something new.
In addition to the main transactional functionality (like buffering, record locks and saving data) BOPF has one more rarely used but helpful feature – saving the transactional state in a so called Synchronization Point (SP) to which you can rollback when necessary. This is some kind of sub-transaction or “Generic Undo”.
First, let`s understand when we need SP. Imagine that you have a transaction for a complex business scenario, and execution of this scenario can be logically separated into several Steps. As an example, let`s take situation when the 1st Step has already been done and some changes have already been saved in BOPF buffer.
After that, you need to proceed with the 2nd Step. This Step contains action calls, modifications and for sure brings many changes into the buffer. You know that the 2nd Step can be failed because of locking issues, data validity or similar reasons. There is a question: “What we need to do with the transaction if the 2nd Step has been failed?”
I hope you are agree that a good solution here is will be turn back to the transaction state ‘Before Step 2’, write an application LOG and save the transaction or proceed with another Step.
Fortunately, BOPF has functionality to do it. You just need to create a Sync Point after the Step 1 and to do rollback to it, if the Step 2 has failed.
Technically SP is a copy of all buffers which are used in a transaction. How to create SP?
Method create_sync_point is used for SP creation. In addition there are methods for SP deletion and for performing rollback to the saved transactional state.
Move ahead and talk about SP creation. When you call method create_sync_point, BOPF doesn`t copy any buffers but set an SP activation Flag.
After that, when you call method modify of the interface /bobf/if_tra_service_manager, BOPF will check this SP Flag, and, if SP is active, then buffers of service manager will be copied.
How they are copied? Method clone of the interface /bobf/if_tra_clone (this interface is implemented in the service manager class) does the buffer copying. Please keep in mind that SP Flag is checked via calling method modify, but NOT via calling method do_action. It is important because, if you create an SP, call an action and after that you want to do rollback to SP, then performing rollback will not be done, because service manager hasn`t been copied before action call. How we can solve this problem? We have to call method clone of the service manager manually after creation of SP.
Then you can call actions and be sure that the clone of service manager instance has been created. Keep in mind which BOs can be modified by action calls because it`s easy to miss something.
So we have created SP. Now we can call some actions, popup screens and do required modifications in BOPF buffer. After an execution of these changes we have to decide: do a rollback to the saved transactional state or just continue to work with a transaction. If rollback is required, then call method rollback_to_sync_point by transaction manager object. If rollback is NOT required then we should delete active SP by method release_sync_point.
About limitations. Sync Point cannot be created inside BOPF, i.e., directly in actions, determinations and other service manager`s functionalities. SP corresponds to transaction layer therefore it can be used only by transaction manager. Where we can use SP? In reports, in function modules, which work independently from BOPF, for example, in background processes. SP also can be used in popup screens when all changes must be reverted by clicking on button ‘Cancel’ that calls SP rollback. I do not recommend to do a transaction save when SP is active. It breaks a BOPF concept and leads to different issues.
If you want to handle any failed BOPF transaction save which has been rejected e.g. by validation, I advise you to call method cleanup of transaction manager object and write info into application LOG. Method cleanup is used for clearing transaction buffer and for making free locked records. SP doesn`t help with failed save operations.
Good to mention that for a stable work of SP in the system at least two SAP Notes must be implemented: 2233743 & 2287479.
Thanks for your attention.
Dmitry
In addition to the main transactional functionality (like buffering, record locks and saving data) BOPF has one more rarely used but helpful feature – saving the transactional state in a so called Synchronization Point (SP) to which you can rollback when necessary. This is some kind of sub-transaction or “Generic Undo”.
First, let`s understand when we need SP. Imagine that you have a transaction for a complex business scenario, and execution of this scenario can be logically separated into several Steps. As an example, let`s take situation when the 1st Step has already been done and some changes have already been saved in BOPF buffer.
After that, you need to proceed with the 2nd Step. This Step contains action calls, modifications and for sure brings many changes into the buffer. You know that the 2nd Step can be failed because of locking issues, data validity or similar reasons. There is a question: “What we need to do with the transaction if the 2nd Step has been failed?”
I hope you are agree that a good solution here is will be turn back to the transaction state ‘Before Step 2’, write an application LOG and save the transaction or proceed with another Step.
Fortunately, BOPF has functionality to do it. You just need to create a Sync Point after the Step 1 and to do rollback to it, if the Step 2 has failed.
Technically SP is a copy of all buffers which are used in a transaction. How to create SP?
Method create_sync_point is used for SP creation. In addition there are methods for SP deletion and for performing rollback to the saved transactional state.
Move ahead and talk about SP creation. When you call method create_sync_point, BOPF doesn`t copy any buffers but set an SP activation Flag.
After that, when you call method modify of the interface /bobf/if_tra_service_manager, BOPF will check this SP Flag, and, if SP is active, then buffers of service manager will be copied.
How they are copied? Method clone of the interface /bobf/if_tra_clone (this interface is implemented in the service manager class) does the buffer copying. Please keep in mind that SP Flag is checked via calling method modify, but NOT via calling method do_action. It is important because, if you create an SP, call an action and after that you want to do rollback to SP, then performing rollback will not be done, because service manager hasn`t been copied before action call. How we can solve this problem? We have to call method clone of the service manager manually after creation of SP.
Then you can call actions and be sure that the clone of service manager instance has been created. Keep in mind which BOs can be modified by action calls because it`s easy to miss something.
So we have created SP. Now we can call some actions, popup screens and do required modifications in BOPF buffer. After an execution of these changes we have to decide: do a rollback to the saved transactional state or just continue to work with a transaction. If rollback is required, then call method rollback_to_sync_point by transaction manager object. If rollback is NOT required then we should delete active SP by method release_sync_point.
About limitations. Sync Point cannot be created inside BOPF, i.e., directly in actions, determinations and other service manager`s functionalities. SP corresponds to transaction layer therefore it can be used only by transaction manager. Where we can use SP? In reports, in function modules, which work independently from BOPF, for example, in background processes. SP also can be used in popup screens when all changes must be reverted by clicking on button ‘Cancel’ that calls SP rollback. I do not recommend to do a transaction save when SP is active. It breaks a BOPF concept and leads to different issues.
If you want to handle any failed BOPF transaction save which has been rejected e.g. by validation, I advise you to call method cleanup of transaction manager object and write info into application LOG. Method cleanup is used for clearing transaction buffer and for making free locked records. SP doesn`t help with failed save operations.
Good to mention that for a stable work of SP in the system at least two SAP Notes must be implemented: 2233743 & 2287479.
Thanks for your attention.
Dmitry
6 Comments
| User | Count |
|---|---|
| 20 | |
| 8 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
