João studies Computer Science at his College where he learns Java, polymorphism, encapsulation and a lot of other programming techniques and best practices. When he graduates, he decides to join a company to work in SAP. At the introduction training which his new company offers, the first thing he learns is how to make a program in ABAP. Here’s how they teach it:
“Go to transaction SE38, create program ZJOAO and then create includes ZJOAO_TOP, ZJOAO_FRM and ZJOAO_SEL. You declare all variables in _TOP, the selection screen you put in _SEL and all the FORMS must go into _FRM. Then write START-OF-SELECTION and under that put all the SELECTs and finally write END-OF-SELECTION and there you show the results in an ALV. It’s that simple. Welcome to ABAP.”
The view below shows how simple it is to create the conditions to inject ABAP commands into programs in a productive system.
I considered whether to publish this. But, as it already happened in the past, I believe it is better for this to be known because it is very important for system administrators to be aware of this so they can protect their systems against this threat.
I was sure I had already posted about this before but I can’t find it so here it goes (again?).
Some function modules save global data which must then be used by another function module belonging to the same function group. So, if you need to test them, they must run in sequence inside the same transaction.
Everybody knows you can use SE37 to test a function module. What few people know is that you can also use SE37 to test a sequence of function modules inside the same transaction. Those who don’t know this end up creating a small program to call those functions in sequence and that’s also ok. But here’s how you can avoid that.
Transaction SE37 lets you test function modules. Sometimes these function modules use tables. And sometimes you need to load these tables with a lot of data records. But the only way to do it is manually. Or maybe not…
The PARAMETERS and SELECT-OPTIONS already have some configuration options. But sometimes you need more control, more customising. Interestingly, although it’s not simple nor obvious, it can be done through a standard function module.
In a well protected system, normal users don’t have debug permissions. Very often, this makes it harder for ABAP programmers to help solve the users’ problems, not being able to debug directly in their session.
But there is a legit, albeit obscure, work-around for this problem.
Here we are again facing a dilemma: hide something because it is dangerous and someone can do bad things using this information or teach it because it would be condescending to presume the readers are not responsible enough to know it. Dictatorships usually go for the first: burning books, censorship, etc. Abapinho like to believe that its readers are responsible people and deserve the right to know.
Thus, here it is. No, it’s not a user manual on how to enrich uranium nor a formula for homemade nitroglycerin. But it’s something similar: a trick that allows you to change standard objects without the need for a key.
By default SE16N always shows the values in the external format, applying the conversion exit to all of them. Until recently, I used to go the ancient SE17 whenever I needed to see them in their internal format. But Rui Nunes told me how to do it in SE16N.
Here’s a not very orthodox wat to deal with a report’s selection screen.
Sometimes you may need to have a special parameter which you prefer to hide from normal users but still need access to. Example: a flag to activate a debug/trace mode. I’ll show you how you can do this by just typing the magic word, ABRACADABRA.
It goes like this:
DATA: unhide_parameters TYPE flag.
PARAMETERS: p_debug AS CHECKBOX.
AT SELECTION-SCREEN.
CASE sy-ucomm.
WHEN 'ABRACADABRA'.
unhide_parameters = abap_true.
WHEN 'NORMAL'.
CLEAR unhide_parameters.
ENDCASE.
AT SELECTION-SCREEN OUTPUT.
LOOP AT SCREEN.
IF screen-name = 'P_DEBUG' AND unhide_parameters IS INITIAL.
screen-active = 0.
MODIFY SCREEN.
ENDIF.
ENDLOOP.
Just type ABRACADABRA when you’re at the selection screen and your secret parameter will magically show. If needed, you can then type NORMAL to make it disappear again.
We’re all lazy. It’s just human. Programmers are human. We’re often lazy when it comes to the way we program something. And usually being lazy when making a program will result in someone else having more work when maintaining it.
Let he who is free of laziness throw the first rock.
When I say that I like to use UML class diagrams to document my code, people think I’m crazy.
Introduction
The UML has gained a bad reputation because people think that, first you make the classes diagram in UML and only then write the program. But that was in 1996, when you the good practices said the first thing to do was the whole technical spec, even if no one really did it.
Nowadays, fortunately, we are no longer ashamed to say that the very act of programming is already in itself a way of drawing.
I recently found a program which was generating an SQL statement by concatenating several variables with fixed SQL parts. But, either by not paying attention or simple ignorance, the person who did it, thought it would make sense to associate a text-symbol to each of these variables with. Something like this:
