Queres obter o texto de uma mensagem da qual só sabes o ID e o número e não sabes como? Aprende aqui: DATA texto TYPE string. MESSAGE ID '00' TYPE 'E' NUMBER '163' WITH '123' INTO texto. É só isto. Agora do lado de dentro da variável texto encontras o seguinte texto: “O mandante 123 não existe no sistema” Obrigado a Peteris B pela foto. O Abapinho saúda-vos.

Às vezes pergunto-me qual será, no mundo, a percentagem de código ABAP desnecessário. Um exemplo paradigmático de como se pode desperdiçar tempo a escrever código que não serve para nada e só prejudica é a tão frequente definição das descrições dos campos de uma ALV directamente em ABAP.

Durante doze anos Quando quis contar As linhas de uma itab Fazia o que todos fazem: DESCRIBE TABLE itab LINES linhas. Até que outro dia Vi uma coisa que, Parece mentira, Nunca antes vira: LINES( itab ). Dá no mesmo E sem ter de declarar O raio da variável. Assim, em vez de: DATA: linhas TYPE i. DESCRIBE TABLE itabl LINES linhas. IF linhas = 42. WRITE 'A tua tabela é a verdade'.

Nos módulos AT SELECTION-SCREEN de um REPORT é-te possível lançar mensagens de erro e voltar ao ecrã de selecção. Mas uma vez que passes do START-OF-SELECTION, se lançares uma mensagem de erro, o programa termina. A solução para dar um erro e, ainda assim, regressar ao ecrã de selecção, é travestir a mensagem: START-OF-SELECTION. IF condicao_desejada. MESSAGE S208(00) with 'Erro!' DISPLAY LIKE 'E'. EXIT. ENDIF. WRITE 'Olá, eu sou o resto do programa'.

Nunca te aconteceu esbarrares com uma coisa no ABAP que parece que é mas não é? A documentação diz que é, tudo indica que assim seja, e depois afinal não é. Provavelmente já precisaste de, ao definir um parâmetro no ecrã de selecção de um relatório, limitar as possibilidades do que o utilizador pode introduzir aos valores disponíveis no tipo de dados desse parâmetro, certo? Para isto existe o VALUE CHECK.

Classes. Sempre as houve entre as pessoas. Mas no ABAP ainda há poucos que as tenham em conta. Se ser classicista na sociedade pode resultar em pedantismo, no ABAP, a única luta de classes é a que alguns travam para que estas sejam mais usadas. Há dois tipos de classes: as globais e as locais. As globais são criadas na transacção SE24. As locais, que por sinal dou por mim a usar cada vez mais, são feitas declarativamente na SE38.

Aqui vos mostro uma forma criativa de preencher uma tabela interna com constantes que aprendi num programa standard. Imagina que querias criar uma tabela interna com os seguintes tipos de documento financeiro: AB AF CH DG DZ EX F3 F4. A forma mais convencional seria assim: DATA: t_blart TYPE STANDARD TABLE OF blart, wa_blart LIKE LINE OF t_blart. wa_blart = 'AB'. APPEND wa_blart TO t_blart. wa_blart = 'AF'. APPEND wa_blart TO t_blart.

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.

No princípio era o INTO. Aliás, no princípio nem sequer era o INTO.

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ê?