How to identify that your Business Data Toolset (BDT) is in need of a refactoring

How to identify that your Business Data Toolset (BDT) is in need of a refactoring

SAPs BDT (Business Data Toolset) supplies the ability to enhance the master data in every Financial Services module with custom fields, tables and checks. During the course of an SAP FS implementation the first couple of custom enhancements will be added. Over time during maintenance or follow up projects, new BDT enhancements will be added. Due to the complexity of the BDT, lack of documentation and the lack of BDT knowledge of new developers, “software rot” sets in the custom BDT code base. The result are undocumented, hardly maintainable and error prone BDT applications that cause high maintenance costs. Time for a refactoring and realignment of BDT development strategies.

How do I identify that a refactoring is needed?

  1. There is an inflation of BDT development objects

Every BDT application is based on one function group, that contains all its subscreens and function modules. If there is more than one function group for one BDT application then this is a sign of BDT software rot. An inflation of global variables within the TOP include is also a safe indicator. Only the variables for the local function group memory should be declared once in the TOP include.

Furthermore take a look at the BDT event function modules: There should be only one function module per BDT application in the customizing.

  1. There is a proliferation of BDT customizing entries

While you are looking at the event function modules: Make sure that customer function modules are only assigned to customer BDT applications and not SAP applications. The easiest way to check this is by looking into table TBZ1F: select FNAME = Z* or Y* and then check for rows with APPLI not equal Z* or Y*.

Also search for inactive custom BDT applications. Those should be removed.

BDT screen layout objects (field groups, views, sections, screens, screen sequences) without any assignment should be removed. You can┬ácheck this with the “used where” functionality on the according maintenance screen.

  1. Too many developers and a high frequency of changes

When many developers with different levels of BDT experience frequently change BDT objects, then this is another sign of problems. You can identify those objects with the SAP Custom Code Management tool (part of the Solution Manager).

  1. Lack of modularization, no separation of concerns

Function modules that have a high frequency of changes develop an Add-On effect: To avoid impact developers just add their code at the end of the existing code without analysing the previous code. Existing code is not reorganised, no matter how obscure it may be, in fear of breaking things. The function module grows in line of codes without modularisation and becomes unreadable and unmaintainable. Different business requirements are contained in the same context. A separation of concern is not given. Both separation of concerns and limiting the lines of code in a modularisation unit are part of the official SAP programming guide lines.

  1. A lot of dead or commented code

A high frequency of changes comes with an inflation of commented or unused (dead) code. Both make the maintenance difficult and should be removed. SAPs version control documents code changes and makes commenting of old code and change comments like “begin of change 24/07/2015 User XYZ” redundant.

Unused variables and modularisation units impair code readability and should be removed. The Eclipse based IDE offers excellent support for this.

  1. Manipulation of BDT persistency control

Persistency is done by the table owning applications and not by the participating applications. That means customer BDT coding must not use COMMIT statements.

  1. Implemented functionality doesn’t match documented functionality in concepts/test cases

This doesn’t refer to BDT applications only but has much more importance in BDT applications, because changes in BDT affect the user dialogue and direct input. Therefore an up to date documentation is a must. If test cases are based on old requirements, every retest will fail.

What do you do if those aforementioned issues are found in your system? A refactoring is inevitable. Refactoring means the clean up of the code and the above mentioned BDT objects, which was already mentioned:

– Reduce the amount of global variables

– Remove dead or commented code

– Delete unused BDT layout objects

– Modularize meaningful

– Remove COMMITs and replace with in UPDATE TASK persistency

– Ongoing update of concepts, documentations and test cases, when BDT changes are implemented

– Code Ownership: Only a few experienced BDT developers maintain the BDT code or approve BDT changes by code review

– Increase BDT know how through additional developer training