É frequente em SAP cruzarmo-nos com um conceito desconhecido. Às vezes esqueço-me de que há ferramentas disponíveis muito fáceis de consultar. E o glossário SAP é um exemplo disso. Pode ser acedido de várias formas: No próprio SAP: através da transacção STERM; Online: num site da SAP: https://help.sap.com/saphelp_glossary/en/; No nosso computador: usando o programa ABAP GLOS_DOWNLOAD_HTML para fazer download de todo o seu conteúdo.

Il faut cultiver notre jardin - Voltaire

No SAP fala-se muito de experiência. Fulano tem muita experiência, sicrano tem pouca experiência. Tenta-se com isso medir a capacidade que alguém tem de usar o seu passado para lidar com o seu futuro. Mas nem sempre ter experimentado uma coisa é sinónimo de ganhar experiência com ela. O exemplo paradigmático ao alcance de todos é o amor: quantos desgraçados, por muitas experiências desgraçadas que tenham tido, se continuam a desgraçar-se no amor! O SAP não é o amor. Ainda assim não nos faltarão exemplos de consultores que no CV descrevem muitas experiências e na prática se revelam uns grandes inexperientes.

A Inteligência terá certamente muito peso nessa capacidade de sublimar as experiências, de as conservar, de fazer delas Compota de Experiência. Mas, pelo menos no que toca ao mirabolante mundo do SAP, quem tem também muito a dizer é a senhora Memória. Ou melhor dizendo, a falta dela.

O mundo do SAP é horizontal e vasto. Para onde quer que se olhe é a perder de vista. E embora seja um mundo bastante populado e onde se viaja muito, não houve até hoje, que eu saiba, cartógrafos de jeito. Os mapas que dele se fizeram são parcos, pobres, distorcidos e normalmente ainda o julgam plano quando toda a gente já sabe há muito tempo que ele é curvo.

Há que cartografar o nosso mapa.

A pesquisa de objectos em ABAP e por todo o SAP é normalmente feita de duas formas: listando objectos de um tipo através de search helps ou procurando objectos em que um determinado objecto é usado, através da opção where used. Só que às vezes o que buscamos não se trata de um objecto mas sim de uma frase qualquer ou mesmo um comentário que sabemos existir no código mas não fazemos ideia de onde.

É sabido que quando é necessário fazer uma pequena alteração a uma função standard para a qual não há nenhum tipo de user-exit, o mais normal é fazer uma cópia dela para uma função Z e lá proceder à alteração necessária. No entanto, quando esta alteração pode ser feita no início ou no final do programa, há uma forma mais elegante de conseguir o mesmo resultado: a técnica das Matrioskas. Criar uma função Z com os mesmos parâmetros que lá dentro invoca a função standard e que, além disso, antes ou depois de a invocar, tem o código para implementar a alteração necessária.

Uma boa parte dos reports, interfaces ou jobs, têm de produzir algum tipo de relatório. É normal ver isso feito recorrendo ao comando WRITE. Ora nos dias que correm, usar o comando WRITE para isto é como recorrer a um par de pedras para acender uma fogueira. Afinal, porque não usar o Application Log que é muito mais simples e prático e standard e é só vantagens?

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.

Quando se faz desenvolvimentos em ABAP, pesquisar na SAP Community ou nas notas e na documentação da SAP é uma actividade recorrente. Como tal, quanto mais fácil for fazê-lo, melhor. Ideal seria que fazê-lo fosse tão fácil como pesquisar no Google. Ora uns senhores chamados JNYSolutions tornaram isso possível criando plugins de pesquisa para o Firefox e o Internet Explorer que adicionam a SDN, as notas e a documentação da SAP como motores de busca.

Eis uma função para verificar se uma pasta existe e se nela temos permissões de escrita. PARAMETERS: p_dir TYPE btctext80 DEFAULT '/usr/sap/trans'. CALL FUNCTION 'PFL_CHECK_DIRECTORY' EXPORTING directory = p_dir write_check = 'X' * FILNAME = ' ' EXCEPTIONS pfl_dir_not_exist = 1 pfl_permission_denied = 2 pfl_cant_build_dataset_name = 3 pfl_file_not_exist = 4 others = 5. CASE sy-subrc. WHEN 0. WRITE /: 'Directory:', p_dir, ' exists'. WHEN 1. WRITE /: 'Directory does not exist:', p_dir.

As constantes não o são. Toda a gente sabe. Quando se define uma constante, é certo como a morte que mais cedo ou mais tarde alguém vem e muda-a. Quando isto acontece, quem usa os valores directamente no código ABAP está feito ao bife; Quem define constantes no código só tem de alterar o valor num sítio mas vê-se ainda assim obrigado a editar o programa e a transportá-lo, coisa que, dependendo do grau de burocracia do ambiente em que se está, se pode revelar complicada. Este artigo apresenta uma solução simples mas sofisticada para gerir de forma centralizada todas as constantes de um sistema SAP através do uso de uma tabela de utilizador central onde se manterá todos os valores constantes e de uma classe com alguns métodos estáticos que serão usados para os obter.

Uma forma prática de aprender a usar um módulo de funções ou verificar se este nos é útil é através da funcionalidade de teste da transacção SE37. Escolhe-se o módulo de função, faz-se F8 (Executar) e tem-se uma forma interactiva de testar uma função. Isto é óbvio. O que não será óbvio para toda a gente é que este teste não faz COMMIT à transacção e, por isso, qualquer alteração que a função possa fazer à base de dados - como gerar um documento por exemplo - não é gravada.

É intrigante o porquê de, nos dias que correm, a transacção SE16 continuar a ser tão utilizada, quando já existe há tantos anos uma muito melhor, a SE16N. A transacção SE16N tem mais: sainete: tem um interface mais dinâmico e sofisticado; simpatia: mostra em simultâneo a descrição funcional e o nome técnico dos campos; sabedoria: mostra em simultâneo o valor interno e externo dos campos com rotinas de conversão;

No princípio era o INCLUDE.

Depois vieram os CMODs,
  Seguiram-se logo as BADIs,
    Agora são os Enhancements.

        E no entanto, o caos continua.

Crítica Na maior parte dos projectos SAP em que já trabalhei, a metodologia de utilização de todas estas modificações é a tudo-ao-molho-e-fé-em-SAP e é normal encontrar num único include - como o MV45AFZZ - extensões de código tão grandes que, se o SAP fosse a princesa Rapunzel, dava para lhe fazer umas tranças até cá abaixo para o príncipe subir à sua torre. Este código normalmente implementa várias funcionalidades diferentes e independentes que, ao longo do tempo, se vão emaranhando quase irreversivelmente umas nas outras (tipo trança mesmo). Como consequência, qualquer alteração ao código existente requer cuidados redobrados e é sempre vista como um risco para o funcionamento de tudo o que lá está.

Venho aqui propor uma solução simples e eficaz para este problema.

Neste artigo tento explicar o que são change pointers e revelar como são úteis e fáceis de usar.

O que é um change pointer Um change pointer é um mecanismo de registo de alteração de dados baseado em change documents desenvolvido pela SAP especialmente para ALE. Permite saber, de forma simples e eficiente, quais os registos alterados em uma ou nas várias tabelas por ele monitorizadas. Os change pointers são utilizados maioritariamente como gatilhos para a criação de IDOCs. Mas não devem ser vistos apenas como tal e espero que este artigo traga alguma luz a este mecanismo tão útil mas tão descurado no SAP.