Every now and then you get a client who asks a programmer to create a write-protected parameter on the program selection screen. It’s a bit dumb given that the whole idea of parameters is that they are parameterisable. But there you go, it takes all sorts. Clients have so much imagination that SAP should create a cinema module, SAP CI, especially so they can screen all the films they carry around in their heads.
What is your favourite colour? SELECTION-SCREEN BEGIN OF BLOCK b1. PARAMETERS: p_azul BUTTONGROUP GROUP COR DEFAULT 'X', p_verde BUTTONGROUP GROUP COR, p_roxo BUTTONGROUP GROUP COR. SELECTION-SCREEN END OF BLOCK b1. If you said ‘blue’ you live and can cross the bridge. In any case, the following normally happens in ABAP to discover the colour the user chose: IF p_azul = 'X'. lv_cor = 'AZUL'. ELSE IF p_verde = 'X'. lv_cor = 'VERDE'.
When you need to derive a single record from a database table, you normally use SELECT SINGLE, which is like this in its most basic form, as everyone knows: SELECT SINGLE * FROM KNA1 WHERE KUNNR = '1234567890'. Of course, if you are interested in just a few fields, ideally you select them explicitly to avoid copying unnecessary data from one side to the other: DATA: lv_name1 TYPE name1. SELECT SINGLE name1 INTO lv_name1 FROM KNA1 WHERE KUNNR = '1234567890'.
I’m going to teach you a magic formula for creating a RANGE that is almost as easy as just adding water. Imagine that you want to create a RANGE from a database selection to then use it in another SELECT. Obviously you can do it like this: DATA: lt_kunnr TYPE STANDARD TABLE OF kunnr, lr_kunnr TYPE RANGE OF kunnr, wa_kunnr LIKE LINE OF lr_kunnr. FIELD-SYMBOLS: <kunnr> LIKE LINE OF lt_kunnr. SELECT kunnr INTO TABLE lt_kunnr FROM kna1.
In a previous article we talked about macros, a relatively obscure and little used feature that can be both useful as well as create a huge mess. But these aren’t the only ABAP macros. There are others that are even more obscure and with even greater potential to mix up a system: the global macros. I don’t know if I should tell you this, as it’s so strange… But, I don’t think it’s a good idea to hide it… Therefore, I’ll tell all.
O Java, uma linguagem de programação bem pensada, ajuda o programador a organizar o seu código obrigando-o a desenvolvê-lo de forma estruturada. A sua própria filosofia potencia o pensamento estruturado e promove coerência e arrumação.
Já o ABAP… promove o caos. Está cheio de caminhos perniciosos que levam direitinho a um inferno confuso e labiríntico. E geralmente são as coisas aparentemente mais convenientes que se revelam as mais perigosas.
Uma das conveniências piores é a parelha IMPORT e EXPORT.
Normalmente quando há um pedaço de código que pretendemos reutilizar várias vezes, transformamo-lo numa sub-rotina que pode depois ser invocada repetidamente. Embora a SAP não saiba estruturar o seu próprio código, ainda assim, o ABAP, coitadinho, permite-o. E até disponibiliza várias alternativas para modularizar o código. Eu conto quatro alternativas que listo aqui, da mais rígida para a mais flácida: METHOD, FUNCTION, FORM, DEFINE. Se os 3 primeiros são já familiar de todos, o último - DEFINE - quase ninguém usa. O DEFINE permite definir macros em ABAP. E o que são macros? São sub-rotinas aparentes.
Aparentes porquê?
Qual é, digam lá, a melhor coisinha que o ABAP tem? É, digo eu, poder fazer where used em cima de tudo o que mexe. E no entanto, esta maravilhosa funcionalidade só funciona maravilhosamente quando as coisas não são invocadas dinamicamente. Eu uso o where used amiúde para descobrir onde uma determinada mensagem está a ser usada. Ora não é nada incomum encontrar chamadas dinâmicas a mensagens, principalmente em casos onde as mensagens não são enviadas directamente para o utilizador mas sim, por exemplo, para o Application Log.
Por vezes ao fazer READ TABLE a uma tabela interna queremos apenas verificar se um determinado registo existe, e não nos preocupamos com os dados retornados. Algo tipo: READ TABLE lt_kna1 INTO wa_kna1 WITH KEY kunnr = l_kunnr. CHECK SY-SUBRC = 0. Ora já que a estrutura WA_KNA1 não vai ser necessária de qualquer forma, mais vale não a usar, usando antes a opção TRANSPORTING NO FIELDS: READ TABLE lt_kna1 TRANSPORTING NO FIELDS WITH KEY kunnr = l_kunnr.
