À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

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:

Na mitologia grega a forma de comunicação mais frequentemente utilizada pelos deuses para comunicar com os mortais era o estupro. Estupravam por dá cá aquela palha. O mais parecido que temos com estupro no ABAP é o comando SUBMIT, que é também a forma mais comum de comunicação entre dois programas.

O repositório do R/3 é uma coisa maravilhosa. Um vasto armazém de elementos de dados, estruturas, tabelas e muito mais, prontamente disponíveis a todos. Como programadores, é fácil e conveniente escolher estes objectos e puxa-los para os nossos programas à medida das necessidades sem que a preciosa linha de pensamento seja interrompida. Mas nem tudo é sol e flores. Se não tiveres cuidado com os cogumelos que apanhas podes dar por ti com um envenenado entre mãos.

Se em debug consultares a variável de sistema UNAME dentro de uma chamada RFC podes achar estranho encontrar um utilizador que não o teu. O que acontece é que o sistema adopta um utilizador específico a chamadas remotas e uma nova sessão é iniciada. Uma nova sessão implica um novo contexto de execução e, consequentemente, todos os nossos breakpoints , já estrategicamente colocados, não serão reconhecidos. Este problema pode dificultar um debug simples obrigando-nos a percorrer o código à procura DAQUELA chamada remota ÀQUELE sistema em particular. A SAP tem a solução.

Em SAP, quando um desenvolvimento está concluído, chega finalmente o momento de o enviar para outros sistemas onde pode ser devidamente testado e por fim executado pelos utilizadores. Mas antes disso, é crucial verificar se não existem lapsos, erros e afins que possam levar ao aparecimento de alguns comportamentos imprevisíveis por parte dos nossos programas. Existe uma ferramenta muito útil que permite filtrar alguns desses erros e lacunas. Chama-se ABAP Code Inspector.

Sabes a diferença entre um mistério e um enigma? Num enigma sabe-se que há uma solução mas esta não é conhecida; já num mistério, não se sabe se haverá solução. Concordas com isto? 5 * 3 / 10 = ( 5 * 3 ) / 10 = 5 * ( 3 / 10 ) = 1.5 Se não concordas, devias concordar porque é um facto matemático. Mas vamos lá fazer umas experiências.

Um amigo de um amigo de um amigo disse que um amigo dele conhecia um amigo que, num bar de alterne ali nas docas, lhe explicou como roubar os dados a uma SALV.