Some days ago I was using an ST (Simple Transformation) and thought that, even though its job is to convert an input into an output, it is can be used to store XML data.
Let’s asy we have the following XML:
<cocktails>
<cocktail id="gt" nome="Gin Tonic"/>
<cocktail id="ws" nome="Whiskey Sour"/>
<cocktail id="cl" nome="Campari Laranja"/>
</cocktails>
It happens very often that, while programming, I smell something strange. It’s usually hard to identify it right away. It usually starts like a faint fragrance. But, as I become more aware of it, eventually it starts stinking and I understand where it comes from. Even then it is not immediately clear why that particular thing smells bad.
Since 1998, I hear some ABAPer colleagues saying that it’s not worth encapsulating a particular piece of code in a function or method because it will never be reused again. And then they go to SE38 and create yet another report full of includes.
The idea that you should encapsulate your code for it to be reused by you or by others is one of the biggest misunderstandings of the history of our planet.
In SAP’s world, ABAP code will forever stay wherever you leave it.
On one given day, Manuel did something badly because he was on a rush or didn’t know any better. One year later António is asked to make a small change to it. António spots Manuel’s mess but he doesn’t improve it because, for some reasons, in SAP, changing something which is working, even if it’s badly implemented, is a tabu. Instead, António will add his code to the existing one and forget about it.
This attitude, when adopted by everyone, contributes to an inevitable erosion of the system’s code which, some years later, becomes unmanageable. And still, that’s the rule.
The way I see it, this is wrong and goes against the customer’s best interests. Actually, even if the customer doesn’t want me to modify old code because it’s working… I still do it. Who is he to tell me how to program?
We learn in school that all code should have comments. Then, in real life, we find that not everyone was paying attention to what was said in school. As a consequence, most code is obscure and without proper comments.
I was always careful to comment every relevant step of my code, specially the parts which are obscure or not self-explanatory.
But since I recently read Uncle Bob’s Clean Code , my opinion on this changed. Today I believe that the less comments the better. And yet, I don’t see this as contradictory to what I used to think.
Even though you look at an SAP system as a whole, it is composed by several distinct and interconnected parts. There is a small standard program which checks if each part’s clock is correct and synchronised.
It probably won’t be of much use for your daily work. Still, it’s an interesting curiosity.
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. Thank you Ricardo Monteiro for the tip.
Some time ago you created a table and its maintenance screens as local objects.
When, later, you regret it and decide to transport the table, how will you be able to also transport the maintenance screens?
Transporting the maintenance screens function group together with the table is not enough.
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…
Here’s a trick to do it using a file.
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.
As we all know, system adminstrators are very bad, cold blooded and cruel people. To prove it you just need to read the Bastard Operator from Hell.
We, ABAP programmers, are hopeless victims in the hands of these evil creatures.
But not always do we have to be smashed under their hairy fingers.