BOPF Change Tracker

This article describes BOPF Change tracker. It is a tool which allows you to track any changes of any data in BOPF. We have similar functionality in BOPF Test UI but The Change tracker is much stronger and generic.

What problems this tool can solve? Imagine situation: some field of a node is changed in unexpected way, or some records of the node are created/changed/deleted incorrectly. What will you do to solve wrong behavior? You will probably go into the node structure, you’ll press “where-used” and will set breakpoints in a code where this node has been changed. Then you will run application again and will follow breakpoints looking for a place where the records are changed incorrectly. However, when this node has very big where-used list( like 100+ places), this approach becomes very complicated. Keep in mind that a name of the node attribute could be modified dynamically, and in this case it would be unavailable to find this code by where-used button… Change Tracker (CT) in it’s turn allows you to find code where this node is changed, interrupt the runtime via watch points and write info into the LOG.

How does it work? BOPF provides extension functionality for Framework components by Addons. Addon is the class. And it’s object can substitute original objects of service manager, transaction manager, internal access (this is an object you have in io_read/io_modify references, in determinations and actions) and another BOPF components.

The idea is quite simple – we implement interfaces of the main BOPF components in our Addon class. So, in runtime we replace original (created by BOPF) objects of service manager (SM) and internal access (IA) classes by our Addon objects.

Our class works like a Wrapper and stores references to original SM and IA classes on instance level:

During time of creating SM BOPF makes check “is there any Addon used for SM for current user?”. If Addon presents, then BOPF create original SM instance and send it like a changing parameter into static method adjust_serv_mgr( ) of Addon class. As you see, this is a factory for SM.

So, this code replace object of original SM by a new object of Addon class. In Addon constructor we remember references to original instances of SM and IA.

Why is it necessary to remember the references to original objects? The idea is to extend BOPF behavior, but don’t change it! We use original objects for execution of methods like modify( ), do_ation( ) etc. Let’s see code on the screenshot below beginning with method modify( ) in Addon class. First, we call modify( ) method by original SM instance and after that we call our method track_modifications( ), where we track data changes and write LOG:

In this way we don’t change BOPF concept, but we extend it with our functionality. It is needed 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 made from the tables /BOBF/FRW_ADNACT and /BOBF/FRW_ADDON. There are settings for Addon’s activation in the first table. And there are settings for Addon’s behavior in the second table( like name of Addon class that implements this Addon ). Establishment of those settings will be done automatically in CT Report.

CT tool contains:

1. Table ZBOPF_D_TRACK is for storing tracker settings
2. Table ZBOPF_D_T_LOG is for storing information about data changes
3. Class ZBOPF_CL_CHANGE_TRACKER_ADN is used as BOPF Addon class
4. Report ZBOPF_CHANGE_TRACKER_LOG is used for working with tracker

In CT Report user can:

1. 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
2. Activate/deactivate tracker for your user
3. View LOG

How to use change tracker?

1. Run report ZBOPF_CHANGE_TRACKER_LOG

2. Press “Settings”:

3. Add a record into the table ZBOPF_D_TRACK:

4. 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

5. Save settings and come back to the first screen. Press “Activate BOPF Change tracker”

6. Close CT report and run your business applications – information about changes will be saved into CT LOG

7. To display information about data changes in BOPF you should run CT report, fill selection parameters for LOG and execute it

8. 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.