Passei a comentar com " em vez de *
Sempre usei * para comentar o código. Só usava " quando precisava de usar pseudo-comentários ou adicionar um pequeno comentário no final da linha.
Mas há pouco tempo aprendi que faz muito mais sentido usar “.
Sempre usei * para comentar o código. Só usava " quando precisava de usar pseudo-comentários ou adicionar um pequeno comentário no final da linha.
Mas há pouco tempo aprendi que faz muito mais sentido usar “.
Há alguns anos atrás mostrei como se podia converter uma MESSAGE normal numa excepção tipificada. Entretanto o ABAP evoluiu um bocadinho e agora, na versão 7.40, aquela solução complexa já não é necessária.
Não sei há quanto tempo é que isto está disponível mas só agora descobri que é muito fácil ver numa ALV o conteúdo de uma tabela interna durante debug.
Se tu que estás a ler isto achares que tudo o que está escrito no Abapinho é literalmente verdade, o que te vou dizer a seguir vai desiludir: quando disse mágico não quis dizer que era sobrenatural. É só uma forma mais abrilhantada de dizer que é surpreendente e inesperado. Tomei esta liberdade um bocado como quando dizes estou morto de sede e no entanto ainda estás vivo. Tendo clarificado isto, podemos continuar.
O SAP está replecto de recantos refundidos e rebuscados raramente reconhecidos que o Abapinho se regozija por revelar.
O comando %pc é equivalente à opção de menu Sistema/Lista/Gravar/File local:
O sistema do cliente onde trabalho actualmente foi finalmente actualizado para o 7.50 e, depois de tantos anos preso ao ABAP convencional, posso desfrutar as maravilhas introduzidas no 7.40.
São às dúzias essas maravilhas, e não vou começar aqui a fazer artigos sobre cada uma porque já existem artigos espalhados pela net sobre quase todas elas o Abapinho faz sempre o possível por ensinar algo novo ou, pelo menos, pouco conhecido.
Mas há uma singela funcionalidade que, não sendo nada de extraordinário, me agrada: já não é preciso fazer IS INITIAL no comando IF quando a condição é um método que retorna um booleano.
Em tempos falámos na SAAB e nas vantagens de a utilizar para melhor conseguir analisar e descobrir problemas no nosso código. Nesse artigo não expliquei uma coisa que é realmente importante: variantes de activação.
Já todos usámos enhancements implícitos para adicionar código ao início ou final de funções, forms ou métodos standard. Mas é menos conhecido o facto de que também podemos adicionar campos a estruturas de dados, estejam elas declaradas como TYPES ou ou directamente como DATA.
Na escola aprende-se que o código deve ter sempre comentários. Depois, na vida real, descobrimos que nem toda a gente prestou atenção na escola.
Sempre tive o cuidado de comentar os vários passos do meu código, especialmente as partes mais obscuras ou que não são auto-explicativas.
Mas depois de ler o livro Clean Code do Uncle Bob, a minha opinião mudou. Hoje acredito que quanto menos comentários melhor. E no entanto não acho que esta mudança seja contraditória.
Ainda que o SAP nos apareça como um todo, este é constituído por várias partes independentes interligadas. Há um pequeno programa standard que verifica se os relógios de cada uma destas partes estão correctos e sincronizados.
Provavelmente não será de grande utilidade no dia-a-dia. Mas não deixa de ser uma curiosidade engraçada.
O vídeo abaixo demonstra como é simples criar condições para facilmente injectar comandos ABAP em programas em produtivo. Ponderei sobre partilhar este vídeo pois o seu conteúdo pode ser usado para fins menos nobres. Mas, como já aconteceu no passado, acredito que é preferivel que isto seja divulgado pois é fundamental que os administradores de sistema estejam conscientes desta possibilidade e protejam os seus sistemas dela. Pois é algo verdadeiramente perigoso.
Criaste uma tabela e os seus ecrãs de manutenção como objectos locais.
Quando mais tarde te arrependeres e decidires transportar a tabela, como fazes para os transportar também os ecrãs de manutenção?
Transportar só o grupo de funções não chega, vai dar erro.
Podia jurar que já tinha feito um post sobre isto mas não consigo encontrá-lo por isso aqui vai.
Há funções que guardam dados globais que serão depois usados por outra função do mesmo grupo. Ora se quiseres testar as duas juntas é fundamental que corram sequencialmente dentro da mesma transacção.
Toda a gente sabe que a transacção SE37 permite testar uma função. O que pouca gente sabe é que a transacção SE37 permite testar uma sequência de funções dentro da mesma transacção. Quem não sabe isto normalmente acaba por criar um pequeno programa de testes para chamar as várias funções em sequência. Fica agora a saber como o pode evitar.
Os PARAMETERS e os SELECT-OPTIONS até têm algumas opções de configuração. Mas muitas vezes dava jeito conseguir configurá-los ainda mais. E curiosamente, ainda que não seja assim tão simples, é possível fazê-lo, através de uma função standard.
Num sistema bem protegido, os utilizadores não têm permissões para debug. Mas muitas vezes isso complica a vida dos ABAPers que, ao quererem resolver um problema desse utilizador, não podem fazer debug à sua sessão.
Mas há uma forma legítima, ainda que pouco óbvia, de contornar o problema.