EDUCAÇÃO E TECNOLOGIA

Running ABAP-workshops to help colleagues help themselves

At work we have two main SAP-related groups in IT, those who regularly work with the ABAP tools and those who have the required process knowledge who tend to module-specific customizing. There is of course some overlap and we also work closely together whenever it comes to fulfilling requirements our end users have. In addition, our colleagues from the process teams regularly turn to us for help when there’s some need for troubleshooting, be it via debugging or interpreting dumps.

Recently, the idea came up to help them help themselves by offering workshops about some tools they could use on their own once they know where to look and how to interpret “stuff” they’d then encounter. The main intention was to increase their “passive knowledge” to be able to get the gist of what they see – comparable to being able to somewhat understand a foreign language when reading it but not able to actually speak it.

Image%20by%20Gerd%20Altmann%20from%20Pixabay

Image by Gerd Altmann from Pixabay

This was something right up my alley as I like to help people and it was also something well worth spending some time on as it would almost certainly be time well-invested. Before we really set things in motion we first gauged my colleagues’ interest and were happy to see that about 30 of them signed-up quickly. In order to give everybody a chance to participate, I scheduled three 2-hour sessions at different days and times over the span of three weeks. The plan was to spend about 30 minutes each on these four topics: ABAP basics, Debugging, Dump analysis and transaction SAT. The following paragraphs explain what I included for each of them.

ABAP basics

I looked through the long list of available DEMO-programs in package SABAPDEMOS and decided to use DEMO_ALV_REPORTING throughout the workshop as it has easy to grasp logic and allowed me to show (almost) everything I wanted to show. I encouraged my colleagues to “play along” in one of our development or test systems to which they had access while I shared some easy to use tips:

You don’t really know what a statement does? Position the cursor on the term and hit F1 for the ABAP-help and get more information about it than you ever wanted.

You want to know the properties of a data dictionary object? Position the cursor on the name and double-click to trigger the forward-navigation. While demonstrating this for the SCARR table used in the DEMO-program, I also briefly explained data-elements and domains.

You simply want to poke around a bit to see what’s available? Go to transaction ABAPDOCU to access the keyword documentation and find example code.

Code

The Debugger

Next up was a brief look at the debugger for which I simply placed a  break-point in the DEMO-program and then explained how to navigate in a debugging session. I also showed them how to see the content of fields, structures and internal tables while stepping through the program and how helpful the call stack could be in order to learn how the program ended up where it was.

In addition, I mentioned the option to change field content while stepping through in debug-mode and that this is – for obivious reasons! – only allowed and possible to do in development and test environments.

Dump Analysis in ST22

In order to show how a dump happens, I had copied the DEMO-program’s code into my own test program and added a statement where a CONVERT_NO_NUMBER-error would for sure happen. When I executed the program, I explained that they have a good chance to quickly find the issue causing the dump when they get it themselves and then – instead of backing right out – click on the Debugger icon.

In ST22 I showed them which sections in a dump are the most promising to look for “clues” and what to look for depending on the dump triggered. For example with TIME_OUTs or MEMORY-issues it’s always good to check the content of SY-INDEX and/or SY-TABIX and to see in the memory-dump if any of the internal tables look suspiciously large as far as number of entries goes. I also explained that it’s often possible to identify key fields of impacted tables which can help identify which IDOC, order or master data was causing the underlying issue.

Transaction SAT – Performance analysis

SAT is one of my favorite transactions as it comes in handy not just for troubleshooting purposes but also to get a better handle on processes one isn’t yet familiar with. It’s also a transaction which can be somewhat overwhelming when it comes to the presented results. We again used the DEMO-program to create a new analysis and I then showed my colleaugues, which goodies can be easily gleaned from the results:

  • which tables are being accessed
  • which routines are being called and that the ABAP source is only a double-click away (something interesting in there where a break point might make sense for the next execution?)
  • are any user-exits called or Z-tables accessed during a standard transaction?

One of the neat things of SAT is that the results are kept for a couple of weeks and that it’s possible to access the results somebody else created (at least in our setup). Once run, it therefore can be looked at more than once if need be.

Learnings

Judging from the feedback received during and at the end of the sessions, these workshops were a win-win for everybody. I was for example happy to see that nobody had chosen to “never”  go into a dump in the short survey conducted after each workshop – even though several of my colleagues had indicated to never having done it before. Likewise for utilizing the debugger on their own.

Needless to say, I offered to help with any specific issues they might run into or to set up “digging deeper” sessions as needed.


If you did something similar, please share your experience in the comments!

Thanks for reading and cheers

Bärbel