This article describes BOPF Change tracker. This tool allows you to track any changes of any data in BOPF. We have similar functionality in BOPF Test UI but Change tracker is much stronger and generic.
What problem it solves? Imagine a situation: some field of BOPF node was changed not as expected, or some records of the node were created/changed/deleted incorrectly. What would you do to solve the wrong behavior? You will probably go into the node structure, press “where-used” and set breakpoints in the code where this node can be changed. Then you will run the application again and follow breakpoints looking for a place where the records are changed incorrectly. However, when this node has a big where-used list (ex. 1 hundred places), this approach becomes very time-consuming. Keep in mind that the name of the node attribute could be modified dynamically, and in this case, it would be impossible to find this code by where-used button… Change Tracker (CT) in its turn allows you to find the code where this node is changed, interrupt the runtime via watchpoints and write info into the LOG.
How it works? BOPF provides extensive functionality for Framework components by Addons. The addon is the class. And its instance can substitute original instances of service manager, internal access (this object you see in io_read/io_modify references, in determinations and actions) and other BOPF components.
Idea behind: we implement interfaces of main BOPF components in Addon class. During the runtime Addon-register replace original (created by BOPF) instances of service manager (SM) and internal access (IA) classes by our Addon Class instances.
Our Addon class works like a Wrapper and stores references to original SM and IA classes on instance level:
When we ask factory to create SM, BOPF checks “is there any Addon used for SM for current user?”. If Addon is acitivated, then BOPF creates original SM instance and send it like a changing parameter into static method adjust_serv_mgr( ) of Addon class. On the pic below you see factory for SM.
This code replaces instance of original SM by a new instnace of Addon class. In Addon constructor we remember references to original instances of SM and IA.
It is necessary to remember references to original objects. Our goal is to extend BOPF behavior, but don’t change core processes. We use original objects to execute methods like modify( ), do_ation( ) etc. Let’s check code on the screenshot below starting with method modify( ) in Addon class. Firstly we call modify( ) method by original SM instance and after that we call our method track_modifications( ), which tracks data changes and write Change LOG:
With this approach we don’t change BOPF concept, but we extend it with our functionality. Good to mention that CT is implemented without enhancements and modifications of standard code, therefore installation is safe and not lead to any problems!
In general, for Addon usage, some settings should be done in tables /BOBF/FRW_ADNACT and /BOBF/FRW_ADDON. There’re settings for Addon’s activation in the first table. And there are settings for Addon’s behavior in the second table. These settings will be changed automatically in CT Report.
CT tool contains:
- Table ZBOPF_D_TRACK is for storing tracker settings
- Table ZBOPF_D_T_LOG is for storing information about data changes
- Class ZBOPF_CL_CHANGE_TRACKER_ADN is used as BOPF Addon class
- Report ZBOPF_CHANGE_TRACKER_LOG is used for working with tracker
In CT Report user can:
- Specify settings:
- what node will be tracked
- what field (node attribute) will be tracked
- choosing record key for special node instance
- watch points is enabled or not
- what kind of changes we should track – create/update/delete
- Activate/deactivate tracker for your user
- View LOG
How to use change tracker?
- Run report ZBOPF_CHANGE_TRACKER_LOG
- Press “Settings”:
- Add a record into the table ZBOPF_D_TRACK:
- Specify settings for tracking in added record:
UNAME User name( a person for whom this settings works) BO KEY Business Object key NODE KEY Node key RECORD KEY Record key( fill it if you want to track exactly this special node instance) FIELD NAME Node attribute name( fill it if you want to track exactly this field) TRACK CREATE Track create operations TRACK DELETE Track delete operations TRACK UPDATE Track update operations WATCHP ENABLE Using watch points
- Save settings and come back to the first screen. Press “Activate BOPF Change tracker”
- Close CT report and run your business applications – information about changes will be saved into CT LOG
- To display information about data changes in BOPF you should run CT report, fill selection parameters for LOG and execute it
- In CT LOG you can find: what has been changed, how, what is a new value etc.
Info from call-stack where method modify( ) has been called is also here:
About limitations: CT can`t work with BOPF Sync Points. It is not allowed to use Addons and Sync Points in one transaction. You should also deactivate CT if you don`t need it.
I hope this tool will save a lot of your working time during root-cause analysis, investigations and bug fixing. You can download it from Git repository:
There are 3 options for installation: via ACP tool version 1.8.3, SAPLINK or manually. All variants are described in readme files in Git. Let me know if you have any issues during installation or if you meet any other bugs. I`m also open to your suggestions.
Update: It is possible to find a code where any Node instances are changed without CT installation. The guide is uploaded into GitHub repository.
My thanks to Andrei Dukhounik for his help in implementation.