Did you know that your ABAP programme can copy content to your operating system’s clipboard?
It’s very easy to mess up with object names in SAP. I recently found a way to minimize that problem: set rules to fix per-package prefixes for certain object types.
Even though many ABAP programmers tend to forget this, the less texts you hard code in your program the simpler it will be to translate it.
Here’s a simple but rather obscure way to manipulate selection screen texts while still being able to translate then. This way you can, for example, prefix them with icons.
Nowadays I rarely use CL_GUI_ALV_GRID because SALV is so much better. But when I am asked to make an editable ALV I still use it. Until very recently, I thought that, in order to use it, I needed a screen with a container. And because I’m using ABAP OO, I’d need a function group to host it and a function module to call it. Painful.
If you, who are reading this, believe that everything written in Abapinho is literally true, what I’m about to tell you will be a disappointment: when I said magical I didn’t mean that it was supernatural. It is just a nicer way of saying it is surprising and unexpected. I took this liberty just as you’d say “I could kill for a glass of water” knowing that you would never do it. Having made this clear, let’s continue.
SAP is full of hidden corners rarely visited. Abapinho is happy to shed some light on them.
The command %pc is equivalent to the menu option System/List/Save/Local file:
We have all used implicit enhancements to add code to the beginning or end of a standard function, form or method. But you may not know that it can also be used to add fields to data structures, whether they’re declared as TYPES or directly as DATA.
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:
<cocktail id="gt" nome="Gin Tonic"/>
<cocktail id="ws" nome="Whiskey Sour"/>
<cocktail id="cl" nome="Campari Laranja"/>
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.
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.