Às vezes encontras um IMPORT no código mas não fazes ideia onde está o EXPORT correspondente. Quando for necessário comunicar entre programas distintos, isto deverá ser feito através de um par de métodos de uma mesma classe. Assim, quando nos cruzarmos com um, conseguimos facilmente saber qual é o outro. Para implementar esta comunicação, evita utilizar EXPORT/IMPORT sempre que possível. Ao invés, usa um atributo estático da classe.
Estás a contemplar uma classe na SE24, uma tabela na SE11 ou um programa na SE80. Agora queres ver o pacote desse objecto bem como o seu conteúdo. Até há pouco tempo eu faria assim: primeiro via nas características do objecto qual é o seu pacote, depois abria uma sessão nova, ia à SE80 e escrevia lá o pacote. Agora aprendi uma forma muito mais simples.
Quando precisares de enviar uma mensagem dinâmica por parâmetro, garante que ainda assim usas o comando MESSAGE de forma a que o “where-used” não lhe perca o rasto. Ao fazeres MESSAGE E001 INTO V_DUMMY, os detalhes da mensagem ficam disponível nas variáveis de sistema SY-MSGNO, SY-MSGTY, etc. Além disso, os textos das mensagens nunca devem ficar explicitamente definidos no programa mas sim definidos através da transacção SE91. https://abapinho.com/2009/09/evitar-mensagens-dinamicas/
No outro dia apareceram uma série de coisas espatifadas na nossa máquina de testes. De repente ninguém podia trabalhar na máquina. Na STMS encontrámos uma série de ordens de transporte indevidamente transportadas para lá. O utilizador que aparece associado a cada uma dessas ordens é o dono dela. Mas será que a culpa é dele? Não terá sido outra pessoa a fazer o transporte? Como saber?
Olá. Tudo bem? A vida? Flui? Esta dica é tão simples que mais vale conversarmos um bocado antes de eu a dizer senão nem dá para aquecer. Está sol. Choveu de manhã mas agora escampou. Siga. Sempre que vejo alguém a usar a SE16 pergunto-me porque é que o continua a fazer quando a SE16N é tão melhor e já existe há tanto tempo. Mas a dica não é isto.
Todo o código que colocares em user-exits (BADIs, enhancements, SMOD, etc.) deverá ser encapsulado. É comum incluir num user-exit múltiplas partes independentes. Cada uma destas partes deverá ser encapsulada no seu próprio método. Mesmo que seja constituída por apenas uma linha de código; Isto deve ser aplicado tanto a implementações novas como a alterações a código existente; A necessidade de alteração de código existente deverá ser vista sempre como uma oportunidade para reorganizar em métodos código clássico existente, uma vez que este terá necessariamente de ser testado de novo;
Quando tentas apagar um pacote no qual já criaste objectos que entretanto apagaste e o pacote aparente estar vazio quando visto na SE80, quando o tentas apagar não dá porque diz que o pacote ainda contém objectos. Por alguma razão parva, a SE80 não mostra todo o tipo de objectos associados aos pacotes. Além disso, muitas vezes ao apagar um objecto a entrada desse objecto não é correctamente apagada. O SAP está cheio de falhas. Mas é o que temos, é ele que nos dá o pão, não vamos dizer muito mal dele. O Abapinho dá-te a solução.
Official ABAP Programming Guidelines (page 34): [Quando um bloco de processamento clássico for necessário], deves imediatamente delegar a execução para um método apropriado (ver a regra 6.37, Não implementes código dentro de Módulos de Função nem dentro de Subrotinas, e a regra 6.44, Não implementes código dentro de Módulos de Diálogo nem de Blocos de Evento).
Deverás implementar todos os novos desenvolvimentos usando ABAP Objects excepto quando isso se reveler impossível (RFC, IN UPDATE TASK, ecrãs, etc). Quando tiverem de ser alterados, deverás também tentar converter em OO os desenvolvimentos existentes, se isso se mostrar realista. Official ABAP Programming Guidelines (página 32) regra 3.1: Usa ABAP Objects sempre que possível para desenvolvimentos novos ou existentes. Blocos de processamento clássicos podem ser criados só em casos excepcionais.
Aqui está uma forma simples de programaticamente ter acesso aos textos de um programa qualquer. DATA: t_textos TYPE TABLE OF textpool. READ TEXTPOOL sy-repid INTO t_textos LANGUAGE sy-langu STATE 'A’. Agora tens os textos todos disponíveis na tabela interna T_TEXTOS. Como se isto não bastasse, podes também alterar os textos programaticamente. Com os seguintes comandos: INSERT TEXTPOOL sy-repid FROM t_textos LANGUAGE sy-langu. DELETE TEXTPOOL PROGRAM LANGUAGE 'E’. A SAP diz que estes dois últimos comandos são só para uso interno.
Provavelmente por razões históricas, os programadores ABAP não exploram as possibilidades do SQL. Muitos há que em vez de usarem INNER JOINs, ainda julgam que é mais rápido fazer vários SELECTs para tabelas internas e depois trabalhar os dados em ABAP. Mas a verdade é que, mesmo que se haja excepções, a regra é: quanto menos acessos à base de dados, melhor a performance. E faz sentido porque, afinal, porque foram escritas explicitamente para isso, as bases de dados relacionais são muito mais peritas em processar dados relacionais do que um programa ABAP. Mas claro que há coisas que, pela sua complexidade, não podem ser feitas com um simples INNER JOIN. Ainda assim, algumas dessas coisas podem ser feitas num único SELECT.
Aqui está uma funçãozinha fixe para obter alguns detalhes de um sistema remoto acessível por RFC: RFC_SYSTEM_INFO Não posso dar aqui nenhum exemplo porque estaria a revelar informação segreda importantíssima sobre o meu cliente que depois seria certamente utilizada pelos maus para fazerem espionagem industrial. Mas é fácil de testar na SE37. Obrigado kingofthebigmacs pela foto. O Abapinho saúda-vos.
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.
Há inúmeras funções standard para fazer cálculos com datas. São muitas, são demais, são redundantes e, em muitos casos, são obscuras ou impossíveis de compreender. Andava há que tempos para fazer um artigo aqui com uma lista das mais úteis. Mas agora já não é preciso.
