When preparing for an SAP S/4HANA migration, you’ll want to check usage data to see how much of your custom code is being used.

Once you’ve collected usage data, you’ll want to do two things: first, look at the detailed view of recent history via Transaction SCMON. Then, look at the long-term history aggregated in Transaction SUSG.

Evaluating Transaction SCMON Results

In Transaction SCMON, click the Display Data icon at the top of the screen. Up will come a screen full of selection options, as shown in the figure below. The clever thing is that the from and to dates will default to the earliest and latest dates of the collected data.

Here, fill out the following areas:

• Calling Request Entry Points: In Type, your options are to enter “U” for a URL that calls some code or “T” for a transaction code.
• Called Objects: In Type, enter the TADIR type of the object being called—for example, “CLAS” for a class.
• Called Procedures: In Type, enter “FORM” or “METH” or “FUNC”, depending on what exactly the program (or class) is calling.

If you don’t fill in anything except the dates and click Execute, then you’ll see a gigantic list, which is most likely far too detailed to give you any meaningful information.

Because you’re just interested in custom code, enter “Z*” in the Name selection option in the Called Objects box, then run the program. As you can see below, the results are very detailed indeed.

For just seeing what Z programs, functions, and classes are called, this is a bit too detailed. It could be potentially useful for seeing what FORM routines or methods are actually called, however. If a subroutine of some sort is called a lot, then it’s worth asking if it should have a unit test added to ensure its robustness going forward.

If a subroutine is never called ever, then maintaining it at upgrade time is a waste. I’ve seen many programs with subroutines called by a user command that was removed from the main screen of the application 10 years ago and so can never possibly be called again. In such cases, delete (not just comment out) the code. Chances are the very next week someone will raise a change request to have that 10-year-old functionality back again, but if they do, you still have the code in the version management system.

Evaluating Transaction SUSG Results

Now it’s time to look at all that aggregated data collected by Transaction SUSG to see what Z code is being used. However, it isn’t that easy. Per SAP, “You cannot display the aggregated usage data (neither in SUSG nor in SCMON or /SDF/SCMON). A remote enabled API is provided to read the aggregated usage data which you can use to implement your own display or extractor.”

 In other words, the standard SAP system will store the usage data for you, but if you want to actually look at it, write something yourself. All right, then, that shouldn’t be the end of the universe. Programmers, after all, like writing programs. If SAP doesn’t feel like giving them a program to look at the aggregated data, then the programmers can just write one themselves.

The aggregated data is stored in assorted database tables (SUSG_DATA and all its friends) using the same sort of star schema data model that SAP BW uses (i.e., the core tables just contains numbers, and other tables are used to convert each of those numbers into the real data). There is a function group called SAPLSUSG_API, which has function modules that presumably read the data back, but of course none of those modules are documented. Luckily, looking at the data is as simple as looking at Transaction SE16 for CDS view SUSG_V_DATA, and of course you can use that as the data source for a custom ABAP List Viewer report.

When you use Transaction SE16 on SUSG_V_DATA just asking for the number of entries, the result takes about five minutes to come back—for one day’s worth of usage on a system where you are the only user and ran a grand total of two transactions.

To know what custom Z programs, classes, and functions were called during the last year, if you have had Transaction SUSG running for that period, then probably the simplest thing to do is execute Transaction SE16 on table SUSG_PROG with the PROGNAME field set to “Z*”, as shown here:

It is close to 100% likely that with a year’s worth of data, even though it’s aggregated, running Transaction SE16 on that table will time out if it’s run in the foreground (even though there’s an index on field PROGNAME). So you can execute this in the background, then look at the resulting spool request and download that to Excel, or write a small ABAP List Viewer report to email you the result in a spreadsheet and run that in the background. The latter might be overkill, though.

Whichever method you choose, the end result will look like the figure below—just about a billion times longer.

The last two columns are the important ones: the object type and the name. You want to end up with several spreadsheets containing big lists. The first one would be a Transaction SE16 dump from table TADIR with all your Z programs and classes, the next a similar list from table TFDIR listing all your Z function modules, and lastly the list from Transaction SUSG saying which of those objects are actually used.

With a bit of Microsoft Excel wizardry, you can compare those lists to see what Z items have actually been used in the last year. Naturally, since all the data comes from ABAP tables, then the same thing can be achieved using a program. (The author of the E-Bite this post comes from, Paul Hardy, has written such a program. The code can be found on this site: https://github.com/hardyp/S4HANA-ABAP-Code-Conversion.)

The end result is that you have a big list of the 60% to 75% of your custom code objects that are never called. The question is next what to do with such dead code walking. If you use SAP Solution Manager, there’s a recommended process for retiring such code.

One approach is to keep the unused code for the time being (just to be on the safe side) but change the package assignment of such code to ZZZ_OBSOLETE_OBJECTS (keeping a note of what the original package assignment was). If you’re lucky enough that your organization uses packages properly, it may be vital to keep the original package assignment somewhere other than some sort of spreadsheet external to SAP, so you might need to create some sort of shadow package hierarchy to move the dead objects to, but that would be a lot of work for no real benefit.

Conclusion

The custom code you’ve added to your existing SAP ERP system must be checked and, in some cases, updated before moving it to an SAP S/4HANA system. In this blog post, we took a look at the monitoring process and identifying code that must be changed or could be removed prior to your migration.

Editor’s note: This content was originally posted on the SAP PRESS Blog and has been adapted from a section of the book Migrating Custom Code to SAP S/4HANA by Paul Hardy. Used with permission of SAP PRESS. All rights reserved.