BW transformation debugging a start routine

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.