Volta não volta aparece um cliente que pede a um funcional que pede a um programador que crie um parâmetro protegido contra escrita no ecrã de selecção de um programa. É um bocado cretino visto que a ideia dos parâmetros é serem parametrizáveis. Mas enfim, vê-se de tudo. Os clientes têm tanta imaginação que a SAP devia criar um módulo de cinema, SAP CI, especialmente para eles poderem realizar os tantos filmes que lhes vão na cabeça.
Qual é a tua cor preferida? 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. Se respondeste azul sobrevives e podes atravessar a ponte. De qualquer das formas, em ABAP costuma fazer-se o seguinte para descobrir a cor que o utilizador escolheu: IF p_azul = 'X'. lv_cor = 'AZUL'. ELSE IF p_verde = 'X'. lv_cor = 'VERDE'.
Quando se quer obter um único registo de uma tabela da base de dados é costume usar-se o SELECT SINGLE que, como toda a gente sabe, na sua forma mais básica reza assim:
SELECT SINGLE *
FROM KNA1
WHERE KUNNR = '1234567890'.
Vou ensinar-te uma fórmula mágica para gerar um RANGE em que praticamente é só juntar água. Imagina que queres fazer um RANGE a partir de uma seleção da base de dados para depois o utilizar num outro SELECT qualquer. Claro que o poderias fazer assim: 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.
Noutro artigo falámos de macros, uma funcionalidade relativamente obscura e pouco utilizada que tanto pode ser útil como criar uma grande salganhada. Mas estas não são as únicas macros do ABAP. Há outras, ainda mais obscuras e com ainda maior potencial de enfarelhamento de um sistema: as macros globais. Nem sei se revele isto de tão esquisito que é… Mas também não me parece bem escondê-lo… Seja, revelarei. É possível definir macros a nível global do sistema que podem ser utilizadas em qualquer programa ABAP.
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.
