[:pt]Sabias que quando invocas uma função com a opção DESTINATION ‘NONE’ estás a iniciar uma nova LUW? Isto pode parecer apenas uma curiosidade, mas há um caso em que pode fazer toda a diferença: sabes aqueles módulos de função que ao serem chamados uma segunda vez têm um comportamento diferente da primeira vez? Isto acontece porque eles hão-de ter alterado alguma variável global ao grupo de funções. Ora se iniciares uma nova LUW quando chamares a função, o seu grupo de funções é automaticamente inicializado e assim garantes que o comportamento da função é o esperado.

[:pt]Para fazeres debug a um programa que faça parte de um job faz o seguinte:

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.

[:pt]O Flávio Pagoti, do blog ABAP101 publicou um livro em português sobre SAPUI5/OPENUI5. Aqui está o artigo do ABAP101 a anunciar o livro. Lá encontras um link para o comprar. Custa $9,99. A minha principal motivação quando decidi criar o Abapinho foi exactamente combater a gritante falta de conteúdos técnicos de qualidade escritos em português. Hoje as coisas estão um pouco melhores, em particular no mundo do ABAP onde há vários blogs de óptima qualidade.

What can be done when a night is not enough to complete the daily processes?

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.

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.

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.

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?

There are standard functions that trigger messages where they shouldn’t. And they shouldn’t because we want to use these functions in non-interactive programs and then, instead of returning the error, an error message is triggered and ruins the whole process.

However, being aware of this problem, SAP has provided a quite elegant (but not well documented) way of solving this problem.

SAP doesn’t know how to do things right the first time. The WebDynpros are a good example of this. It doesn’t even let you do a text search. It’s sad.

Fortunately Sérgio Fraga has found a way, though it’s rather laboured:

I’m 6 years old! (Thank you Caleb Prichard for the photo)

It is common to find an ALV data structure explicitly defined in the code. If this is done, the field catalog has to be manually constructed. If a predefined structure (from DDIC or declared as a TYPE) is used instead, the field catalog can be automatically built. This approach is always better and results in less code, even if the field catalog needs to be adjusted here and there. https://abapinho.com/en/2011/12/automatizar-catalogo-alv/

Many times we do READ TABLE itbl or LOOP AT itbl just to do a CHECK SY-SUBRC = 0. In these cases, the actual data read is not needed. For these cases always use TRANSPORTING NO FIELDS. This way is faster and avoids having to declare a target structure.

Imagine you have a program executing an infinite cycle or, at least, a cycle with 70x7 iterations. It is neverending, and you want to know what’s going on there.

In the past you had to go to SM50, select the process and choose from the menu “Administration | Program | Debug”.

But now there is a much easier way.