Tag > estilo
Supported by
Supported by Inetum

Local $PACKAGES

images/thumbnail.jpg - Thumbnail
Any object created in SAP must belong to a package. Until recently, whenever I needed to create a program for a quick test I’d put it in the $TMP package. This way I was sure that it would never be transported to another system. But sometimes I have the need to create stuff in the development system which, even though it should never be transported, should stay there forever. For example, development tools like ZSAPLINK and abapGit. But if we put everything under package $TMP it will soon be a big mess.

INSERT wa INTO itbl REFERENCE INTO ref. Bug?

images/thumbnail.jpg - Thumbnail
Every day I use more reference variables in ABAP. First I used REF TO just for classes but, as I become more familiarized with its advantages, I start using them more and more for data structures, instead of field-symbols. But I recently found na unfortunate behavior of the following command: INSERT wa INTO itbl REFERENCE INTO ref. Let me give you some context before I complain about it.

We should be accountable for the crap we make

images/thumbnail.jpg - Thumbnail
If, when building a bridge, a civil engineer makes a mistake in one of the calculations, the bridge falls. But the bridge won’t fall alone. Most probably that engineer will also fall with it. He is accountable for what he did because he must sign his projects. ABAP programmers don’t have that kind of problems.

GROUP BY in LOOPs on internal tables

images/thumbnail.jpg - Thumbnail
We’ve all sorted internal tables to use AT NEW on a LOOP. But starting from 7.40, we can use GROUP BY on LOOPs. The ability to group by values based on expressions or even methods is great. The grouping is done on the first LOOP and can be processed afterwards. Try running the code below and I bet you’ll be as impressed as I was.

In ABAP's name, I baptize you

images/thumbnail.jpg - Thumbnail
When we learn ABAP, we are taught a series of rules on how to name variables. Not everyone uses the same rules but, still, some strict rules are shared between many people: Local variables must start with L: L_BUKRS; Global variables must start with G: G_MODE; Internal tables must have T_: LT_MARA; Structures must have S_: LS_MARA; Object references must have R_: R_CUSTOMER; input parameters must start with I, output with O, changing with C and returning with R. And the most stupid of all, field-symbols must start with FS_: <FS_MARA>. In the early XXI century those rules made some sense (except for the field-symbols on, which was, and still is, as stupid as writing ‘pencil’ in all our pencils). Today they don’t make much sense anymore. Let me explain.

CONCATENATE LINES OF itbl

images/thumbnail.jpg - Thumbnail
If you want to serialize a set of strings stored in an internal table there are two ways to do it. One is dull, the other one is full of style.

Modify one field in all lines of an internal table

images/thumbnail.jpg - Thumbnail
What I’m about to show you is not exactly new. It has even been used in Abapinho before. But since there is still a lot of people out there using LOOP to change a single field of an internal table, I thought it would be worth talking about it. Say you have an internal table with one million and two hundred thousand entries and want to change the field ICON so that it has ‘@FM@‘ in all lines.

DELETE vs CLEAR vs REFRESH vs FREE

images/thumbnail.jpg - Thumbnail
DELETE CLEAR REFRESH FREE These are different ways of deleting all data from an internal table. They look the same. But they aren’t.

CASE inside a SELECT (available soon)

images/thumbnail.jpg - Thumbnail
Get ready because you’ll soon be running into a lot of surprises. ABAP is learning new tricks. Look at this one: CONSTANTS: lc_menina TYPE STRING VALUE ‘GIRL', lc_menino TYPE STRING VALUE ‘BOY’, lc_senhor TYPE STRING VALUE ’GENTLEMAN’, lc_senhora TYPE STRING VALUE ‘LADY’. SELECT nome, CASE WHEN sexo_id = ‘M' AND idade < 18 THEN @lc_menino WHEN sexo_id = ‘F’ AND idade < 18 THEN @lc_menina WHEN sexo_id = ‘M' AND idade >=18 THEN @lc_senhor WHEN sexo_id = ‘F’ AND idade >=18 THEN @lc_senhora END AS titulo FROM zpessoa WHERE pessoa_id = @pessoa_id INTO CORRESPONDING FIELDS OF @lt_pessoas.

Consider converting WRITE reports into ALVs

images/thumbnail.jpg - Thumbnail
Reports still writing directly to the screen are very hard to maintain whenever changes to the layout are required. On such occasions, review the code and, if the effort involved is not too big, consider converting it to ALV. Always involve the functional people in this decision.

Converting an exception into an exception

images/thumbnail.jpg - Thumbnail
If you’re still not using exception classes, then you’re making a mistake. Cause they are very healthy for your code. They’re not only good nutrients for the system, they also make it lean and less vulnerable to diseases. There are cases where you still need to deal with the old exceptions. For example, when a function module is invoked. In this article I am presenting a suggestion that seems a little complex, but it works very well if you need to integrate the old exceptions with exception class in a simple way. And though it is sophisticated, you only need to do it once. Once it’s done, it’s easy to use.

Thou shalt modularize, modularize, modularize

images/thumbnail.jpg - Thumbnail
Historically ABAP programs tend to grow very loooong. All programming best practices teach us there is not a single advantage in this approach. If any routine, be it a program, a method, a function or anything else, becomes longer than 200-300 lines, question it and seriously consider refactoring it into several sub-routines. This has the added advantage of potentially increasing code reuse. But the greatest advantage is encapsulation, isolating variables in their local context, instead of having all of them together, resulting in safer and more readable code.

Thou shalt reuse, thou shalt not rewrite

images/thumbnail.jpg - Thumbnail
If the same piece of code is repeated at least once, question yourself why and try to avoid it by creating a reusable routine. If there is more than one SELECT for the same table in a program, make sure you can’t merge them into a single one. Sometimes a smart use of RANGEs to unify parameters can avoid the need for multiple SELECTs. If the same code is used in 2 different programs, don’t repeat the code.

Thou shalt avoid global variables

images/thumbnail.jpg - Thumbnail
The more global variables a program has, the most obscure it becomes. Please avoid them. This is a basic rule of good programming and should always be followed. Even if several variables have to be passed by parameter, it takes slightly more effort but yields a much more readable and safer code. Exceptions can be made for simple reports which run around a single internal table, which can be declared globally without compromising clarity.

How to ask if the line exists without seeming fashioned

images/thumbnail.jpg - Thumbnail
Long ago, you used the expression “groovy, man”. Later came “great, man”. Then there was “cool”. Today you say “awesome”. It’s important not to get confused and not make a fool of yourself. And how do you ask an internal table if a line exists exists?