Durante anos as tabelas internas eram declaradas assim:

DATA: itbl TYPE TABLE OF bkpf.

Às vezes não gosto dos nomes que a SAP deu às coisas. E então mudo-os.

Por exemplo, um dia estava muito zangado e achava que os clientes eram todos uns parasitas.

Então fiz o seguinte:

Quando aprendemos ABAP ensinam-nos uma série de regras sobre como dar nomes a variáveis. Ainda que nem todos acabem por dar nomes iguais, ainda assim partilham-se algumas ideias rígidas:

• As variáveis locais começam por L: L_BUKRS;

• As variáveis globais começam por G: G_MODE;

• As tabelas internas têm de ter lá um T_: LT_MARA;

• As estruturas têm de ter lá um S_: LS_MARA;

• As referências para objectos começam por R_: R_CUSTOMER;

• Os parâmetros input devem começar por I, os output por O, os changing por C e os returning por R.

• E a mais estúpida de todas, os field-symbols devem começar por FS_: <FS_MARA>.

No início do século XXI isto até fazia sentido (excepto a dos field-symbols que já na altura era tão estúpida como escrever a palavra “lápis” em todos os lápis que tivermos). Hoje quase já não. Passo a explicar.

O Nuno Morais desenvolveu uma ferramenta muito útil que auxilia na tradução em massa da maioria dos objectos SAP.

A ferramenta não faz tradução automática entre línguas. Antes, permite:

• Exportar um ficheiro Excel com textos

• Importar um ficheiro Excel com textos

• Copiar textos de uma língua para uma ou mais línguas de destino

• Criar uma ordem de transporte com as alterações

• Encontrar dependências de objectos a que faltem traduções

• Práctico interface de navegação para tradução manual

  
  Ler o resto do artigo

O Nuno Morais desenvolveu uma ferramenta muito útil que permite comparar objectos entre sistemas e que funciona muito melhor do que a transacção SREPO.

O Abapinho passa a ser o seu repositório oficial.

Código no GitHub.

Em breve, instruções. Até lá vai experimentando, é intuitivo. E se gostares ou tiveres sugestões deixa aqui um comentário.

Obrigado Nuno por teres desenvolvido isto e por o partilhares com o mundo no Abapinho.

DELETE CLEAR REFRESH FREE

São várias maneiras de limpar os dados de uma tabela interna. À partida parecem iguais. Mas não são.

Se ainda não usas classes de excepção fazes mal. Porque são muito boas para a saúde do código. Além de nutritivas, emagrecem-no e tornam-no mais resistente a doenças.

Mas há casos em que ainda é preciso lidar com as antigas excepções. Por exemplo quando se invoca um módulo de função.

Neste artigo apresento uma sugestão um bocado rebuscada mas que funciona muito bem para integrar as excepções antigas com classe de excepção de uma forma simples. A solução é rebuscada mas só tem de ser feita uma vez. Uma vez feita, a forma como se a usa não tem nada de rebuscado.

O que podemos fazer quando as noites não são suficientes para os processamentos diários?

A SAP não sabe fazer as coisas bem à primeira. As WebDynpros são um bom exemplo disso. Aquilo nem sequer permite pesquisar texto. É triste.

Felizmente o Sérgio Fraga descobriu uma forma, ainda que rebuscada:

Hoje vou ensinar-te a encadear excepções. É uma solução muito práctica para um problema complicado mas pouco óbvio.

Começo por descrever o problema.

Imagina que estás na aplicação BANANA. É uma aplicação bastante complexa. Tem, aliás, três módulos. São eles BANANA1, BANANA2 e BANANA3. Cada um tem a sua classe de excepção ZCX_BANANA1, ZCX_BANANA2 e ZCX_BANANA3. E como a aplicação até está bem desenhada, todas as classes de excepção herdam da mesma ZCX_BANANA. Agora imagina o seguinte cenário. Estás no módulo BANANA1 a fazer não sei o quê. E lá tens de chamar uma classe do módulo MORANGO Ora essa classe lança, claro, excepções, do tipo ZCX_MORANGO. Este é o contexto.

Tens várias hipóteses: