BW transformation debugging a start routine
This is my first blog here. I always wanted to write something but never did so. Well, let’s get started trying to leave something which is hopefully useful.
It’s about debugging in SAP BW Transformation and increasing personal productivity while finding issues in ABAP expert, start or end routines. The following helps me to save a few minutes each day while developing or solving issues. It might help avoiding complains from your system monitoring team that the system log is running full because of entries like these in SM21. Do you sometimes forget to remove break-points before transporting something to production?
Personally, I’m annoyed of single step debugging in order to reach the start routine or a specific routine in a transformation in order to reach my ABAP code placed somewhere here:
The easiest solution is to place a conditional break-point in the right place which is not polluting the system log files. And that’s quite simple:
IF request = 'DTPR_SIMULATION'. BREAK-POINT. ENDIF.This has a simple effect: Each time a corresponding DTP is started in Processing Mode “Serially in the Dialog Process (for debugging)“, you will jump directly to the break-point. No endless single-step debugging, no useless log-entries. This is because in this simulated mode no real request id is generated. Only ‘DTPR_SIMULATION’ which is generic.
There are other less convenient methods I used in the past. Like directly setting a break-point in the generated source code or using “BREAK-POINT ID xyz” and SAAB. These are still useful within a transformation rule which is executed 50k times. But then I’d rather use a global variable and set/unset this one (while checking for DTPR_SIMULATION as well) if possible.
While writing this I started wondering why a break-point “before start-routine” was never implemented by SAP. The break-point “Before Transformation” is ending up somewhere in the middle of the jungle of generated ABAP code. There was once a kind of wish-list” in the SCN. I should have mentioned it there earlier. At least the one “After Transformation” is almost in the right place.
Beside jumping into the debugger, the break-point is useful for something else. Although this one is definitely a kind of abuse. If you are too lazy to create proper monitor entries or those monitor entries are not being watched anyway there’s a simple possibility to write something to the system log:
IF <source_fields>-/bic/zcalmonth < '201010'.
BREAK-POINT 'No historical data in DSO zxyz please!' " char40 only!
ENDIF.This is useful for getting reminded by others about the mess one is sometimes forced to create. Honestly, I would never use something like that 😉
A neat trick. But it leaves code that shouldn't really be in your routine as, semantically, it's nothing to do with what you're functionality.
You can set breakpoints in your routine, by looking at the generated code (depending on where you are, the route to this differs, but it's always available somewhere). Any breakpoint set here will 'break' properly.
Alternatively, and good programming practice, make the code that's actually in your routine very small - and have it simply instantiate an instance and call a method to do the actual work. This not only allows you to directly set a breakpoint - it also gives you all the advantages of version management (for example). Any breakpoint set in this code will also 'break' properly. Two examples below, the first for older systems, the second for 7.4 upwards.
or
There are other variants to use, perhaps if you're buffering data in the class, and so don't want to instantiate every time.
Hmm, debugging is part of my daily work when trying to understand what me or others did in the past. This improves productivity. But, yes, it shouldn't be there. It's as superfluouse as the possibility to have standard breakpoints when starting a DTP.
However, if the code that people need to understand is not directly in the transformation, my break-point suggestions brings less advantage and could become annoying.
This reminds about a completly differnt topic: Generic ABAPs in BW in order to be re-used. Or, a development policy of "no ABAP in BW except method calls". Worth at least a nice rant and lots of discussion.