E aiii gente bonita, tudo bem com vocês?

Hoje vou falar um pouco sobre um experimento que tenho feito nos últimos meses com esse treco chamado VIM e esse treco chamado ABAP.

Se vocês não moram debaixo de uma pedra, sabe que a SAP liberou faz um tempinho algo chamado ADT, ou ABAP on Eclipse, teve até post sobre isso aqui no blog por um escritor gatérrimo:

ABAP no Eclipse

Uma das grandes vantagens do Eclipse é o fato dele ser extensível por plugins, algo que sempre subutilizei (se conhecer plugins legais, por favor me fale). Porém num dia de inspiração eu me perguntei:

Existe plugin de VIM?

A resposta é sim, e é diversão garantida para toda a família!

Aviso: Este post é sobre como utilizar com ABAP, não é um tutorial sobre Vim propriamente dito, para isso existem diversos materiais na internet, indicarei alguns que utilizei no fim do post.

O que é VIM?

Vim(Vi IMproved) é um clone do editor de texto Vi, um programa criado para editar textos em Unix, sendo que este é mais focado em edição de códigos e é feito para ser altamente configurável. Por ter que suportar o uso via terminal, seus comandos são, em geral, voltados para uso via texto, desde a navegação até a edição/gravação.

Uma busca rápida no Google sobre “Most popular text editor” vai lhe retornar alguns concorrentes, mas normalmente você encontrará VIM na lista e sempre um dos mais indicados.

Qual a vantagem?

Se você costuma utilizar atalhos de teclado, sabe que toda vez que tem que utilizar seu mouse, você perde um pouquiiiinho de produtividade. A idéia neste editor é sempre manter a mão no teclado, para editar, para se mover no código, tudo via comandos.

Já utilizamos alguns atalhos no nosso dia a dia, Ctrl F3, Ctrl F2, F3, etc etc, então não preciso argumentar muito para dizer que eles agilizam o seu desenvolvimento. A questão é que Vim vai além:

Os comandos do vim acabam sendo “simples” depois de um tempo. Vim é um editor modal, então existe um modo em que você insere o texto diretamente enquanto digita e um modo de navegação. No modo de navegação, chamado de modo normal, os comandos normalmente são <ação><movimento>, depois que você aprende as ações básicas e começa a usar os movimentos, consegue deduzir o que uma ação+movimento faz.

Por exemplo, d<movimento> deleta uma palavra na direção do movimento que você mandou, w navega para o início da próxima palavra, então dw deleta até o início da próxima palavra, então se y é copiar, yw copia até o início da próxima palavra. Combinando isso com macros e os outros atalhos, transforma Vim no editor de texto muito poderoso.

Abaixo você pode ver um pouco alguém programando usando este lindo editor de texto.

Ecomofaz?

Atualmente a única solução para programar fora do ambiente do seu querido SAP Gui é através do Eclipse+ADT, e dentro desse universo existem duas soluções para edição usando Vim: Vrapper e Eclim. Ambos têm objetivos diferentes, mas apenas um deles funciona com ABAP.

• Vrapper transforma o Eclipse num editor Vim.
• Eclim transforma o Eclipse num servidor e você consome ele no seu Vim.

Como ainda temos a necessidade de utilização do SAP Gui(Edição de telas, dependendo do teu servidor, não tem criação de data elements no ADT, etc), a melhor solução acaba sendo o Vrapper. De qualquer maneira, o Eclim não entende a hierarquia de projetos ABAP e nem tem suporte :P.

Para instalar, tem duas maneiras, uma é buscar no Eclipse Market place pelo plugin Vrapper e instalar, simples assim.

A outra maneira é ir em HELP>Install New Software. Na tela seguinte coloque as informações:

Abaixo da tela, vai aparecer várias coisas para instalar:

Na imagem acima, marquei dois plugins que utilizo, e também pra funcionar você precisar instalar o Vrapper.

Ao instalar, vai ganhar um botãozinho na tua barra do Eclipse que ativa e desativa:

E pronto! já pode sair editando teu programa com Vim! :)

Truquezinhos/Conflitos

Como o próprio Vim, o Vrapper tem um arquivo .vimrc onde você pode colocar todas as suas configurações, para usuários de Linux e Mac, existe um arquivo .vrapperrc e para usuários de windows, _vrapperrc, você encontra este arquivo na pasta principal do usuário.

Neste arquivo você pode configurar seus atalhos e opções de editor, assim como também pode adicionar macros.

Algumas configurações que recomendo de início:

O Vrapper nada mais é do que uma camada que captura comandos que o eclipse deixa de capturar, então caso tenha algum atalho direto no eclipse, ele sempre irá utilizar este atalho primeiro e caso realmente queira utilizar alguma funcionalidade nativa do Vim que está em conflito, ou você remapeia através do vrapperrc ou remove o atalho do Eclipse.

Um pequeno bug que eu me deparei foi que as sugestões do eclipse não funcionam completamente com este plugin, para isso deve habilitar o contentassistmode(no arquivo acima), porém o quickfix do eclipse não respeita a navegação padrão do Vim(Ctrl+N/P para a navegar entre as ocorrências). Porém isso funciona normalmente para o auto-complete(Ctrl+space)

Uma funcionalidade muito louca do Vrapper é a capacidade de mapear comandos do eclipse a atalhos do Vim, por exemplo, tenho as seguinte configurações no meu vrapperrc:

Posso então, digitar :a para ativar um programa ou quando o cursor estiver sobre uma variável, digitar gd para navegar para a definição(igual o duplo clique do abap).

Um tutorial de como encontrar os comandos acima pode ser visto aqui.

It's not easy

Caso decida entrar nessa brincadeira e nunca mexeu com Vim, gostaria de deixar um aviso de que a curva de aprendizado é devagar, não fique com medo de desligar o Vrapper para finalmente conseguir liberar aquela request. No começo não será tão produtivo quanto anteriormente e várias vezes vai ser frustrante.

A princípio, vários atalhos não serão intuitivos, como por exemplo, as setas terem sido trocadas por h(esquerda)j(baixo)k(cima)l(direita),o botão copiar é no y, etc etc mas se você largar o preconceito, vai acabar gostando!

Recomendo anotar dúvidas, eu quando fui estudando, todo dia decidia que iria me forçar a utilizar um comando novo: “Hoje vou utilizar :s e suas variações”, caso não saiba fazer algo no Vim ou achou algo que sente falta, anote e procure posteriormente.

Outra dica é que os comandos básicos são os mais importantes, quanto mais você praticar eles, mais rapidamente vão virar muscle memory e mais rapidamente irá programar.

Material para estudo:

Vrapper - Documentation - Introduction

Movimentos básicos do vim:

VIM Adventures - Learn VIM while playing a game

Acho que o tutorial abaixo segura muito na mão mas…

Interactive Vim tutorial

Mas o melhor que usei até agora é o vimtutor, precisa ter Vim instalado na máquina, ai basta digitar :vimtutor e correr pro abraço

E é isso ai povo, caso você utilize eclipse, recomendo gastar um tempo com Vim. Se não utiliza eclipse e já brincou com Vim em outras linguagens, que tal utilizar essa oportunidade para começar ;)?

Não deixe de conferir as referências abaixo, e se curtiu o post não deixe de participar comentando, compartilhando ou simplesmente segurando esse botão de aplausos para mostrar que é esse tipo de conteúdo que você deseja ter por aqui. Muito obrigado e até mais!

ABAP on Vim was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hoje vou falar sobre um assunto que é muito lindo, mas admito que é confuso, table meshes. Como é um assunto complicadinho, vou dividir em algumas partes(que ainda não sei quantas vão ser ;) )

O que são?

Já sentiu a necessidade de um inner join de tabelas internas? O mais próximo que temos disso é o comando PROVIDE, mas não chega lá.

Table Meshes são novos tipos de estruturas introduzidos no release 740 SP5 em que seus componentes(denominados nós) são tabelas ou refêrencias a tabelas, e os nós têm relações semelhantes a chaves estrangeiras entre eles.

A sintaxe

Primeiro, vamos declarar alguns tipos de tabela:

E então, a declaração do mesh:

O que fazemos de especial na declaração é nomear a ASSOCIAÇÃO entre as tabelas. Fazemos isso utilizando:

ASSOCIATION assoc_name TO itab ON key

Onde assoc_name é um nome qualquer (pelamordedeususeumnomedecente), itab é o nome de outra tabela dentro do mesh e key será a relação entre as duas tabelas.

No final, notas_fiscais acaba sendo uma estrutura, como pode ser visto no debugger:

Esta estrutura pode ser utilizada normalmente, com todos os comandos que você A-DO-RA, o MESH apenas acrescenta novas possibilidades.

Mesh Paths

Agora vem a parte legal, como utilizar as associações.

Utilizam-se esses comandos com uma sintaxe não tão ortodoxa:

mesh-node\assoc[ source [cond] ]

onde source é uma linha do nó raiz que está sendo utilizado.

Por exemplo:

Pois é… vamos lá.

O comando \assoc é utilizado para indicar que queremos encontrar a associação para o sub-nó, e qual item do sub-nó será encontrado depende do que será passado nos colchetes. Repare que nele eu passei o retorno de um read table, ou seja, a linha inteira da NFDOC.

Aqui, pra mim fica mais fácil fazer uma analogia com SELECT.

Apesar de termos vários itens na tabela NFITEM, o comando demonstrado retorna uma linha apenas, assim como num SELECT SINGLE.

E se quisermos todos os itens relacionados à essa associação?

Vamos incrementar o exemplo acima, queremos todos os itens relacionados ao primeiro documento em que o valor do item seja maior que 1000:

Utilizei então, a adição cond, que pode ser colocado no código para restringir mais ainda o que será retornado na associação. Veja também que o mesh funciona no loop e nesse caso trará todos os itens que satisfazerem a condição e forem relacionados ao primeiro item.

E por hoje fica assim povo! Considero a sintaxe de table meshes algo complexo e não intuitivo, então trarei aos poucos. A título de curiosidade, fuçando a documentação da SAP encontrei o programa DEMO_MESH_PACK, recomendo MUITO dar uma olhada e ver onde que o ABAP tem chegado, caso você não tenha acesso a um ambiente que tem esse programa, da uma olhadinha na loucura:

barLabs — Table Meshes — parte I was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

O RTFD de hoje vai ser curtinho, mostrando um pequeno erro que pode acontecer ao trocar um READ TABLE por um LOOP WHERE. Encontrei este erro um dia quando fuçava a documentação da SAP e achei interessante compartilhar.

A Motivação

De vez em quando somos obrigados a trocar um READ TABLE por um LOOP WHERE. Provavelmente você precisa fazer alguma validação mais complexa em cada registro ou uma das chaves tem que ser comparada de maneira que o READ não é compatível.

E ai você altera para LOOP WHERE e teu programa não entra mais no IF:

Causa e Teoria

O que acontece aqui é que o READ TABLE converte as variáveis para o tipo da coluna antes de comparar, nesse caso a conversão é de CHAR 04 para 03, e essa conversão no SAP é simples, ele trunca BAR8 para BAR e encontra na tabela.

E o LOOP WHERE? Bom, neste caso o SAP usa regras de comparação para determinar se encontra ou não o registro, e para o tipo C, a regra é:

Converta o menor campo para o tamanho do maior e adicione espaços para na direita

Logo, ‘BAR’ vira ‘BAR ‘ que é diferente de BAR8!

O exemplo acima foi retirado daqui(sue me bitch). Eu não me recordo de ter encontrado esse problema, mas é algo que já tive que fazer diversas vezes e portanto provavelmente ignorei este comportamento errante no calor do momento e fui atrás de outras alternativas.

E…

até a próxima :*

Read The Fucking Documentaiton 03 was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bom diaaaaa povo, vamos a mais um barLabs!

Se você for igual a mim, fica puto da vida toda vez que tem que declarar uma variável auxiliar pra conseguir chamar um método ou uma função. Pois bem, parece que alguém na SAP também deve ter ficado de saco cheio de ter que ficar criando um monte de sujeirinha.

Vamos ao programa exemplo, ele vai ser meio idiota, mas serve. O que faremos é utilizar uma classe de calcular soma e subtração de números inteiros:

Só que por algum motivo de força maior, o desenvolvedor decidiu utilizar 3 parâmetros de INPUT que são caracteres:

Se você copiar os dois códigos acima em um report, vai ver que não compila e gera os erros seguintes:

Bom, pra resolver isso é simples, basta criar o que? O QUE? UMA VARIÁVEL AUXILIAR

Começando na versão 7.40 SP 2, nós obtivemos acesso a uma série de comandos novos chamados de constructor expressions, este assunto por si só é extenso e não é a idéia deste barLabs. Tenha apenas em mente que essas expressões retornam valores.

Quatro das expressões novas são expressões de conversão: EXACT, CAST, REF e CONV.

• EXACT— Faz uma conversão em que perda de dados é verificada, causando uma exceção caso aconteça
• CAST — Como o comando CONV abaixo, mas para refêrencias e objetos
• REF — Retorna a referência da variável em que é utilizada
• CONV — Realiza a conversão da variável seguindo as regras de conversão da SAP

Como o título do post indica, vou focar apenas no último, já vai dar pra ter uma ideia de como utilizar os outros com isso.

O operador CONV tem a seguinte sintaxe:

… CONV type( [let_exp] dobj ) …

Onde dobj é a variável que queremos converter, type é para qual tipo e let_exp pode ser utilizado para criar variáveis auxiliares durante a conversão.

Para o tipo, podemos declarar tipos do dicionário de dados, locais, elementares ou então, já que o compilador sabe qual é o tipo do parâmetro que estamos enviando o valor(afinal, ele tem que saber para dar aquele erro de sintaxe), podemos utilizar um # para identificar que queremos que a variável seja simplesmente convertida para a variável de destino, sendo que esse último só funciona se o parâmetro for “tipado”(nada de TYPE ANY).

Refatorando o código acima, ficamos com:

A quantidade de variáveis inúteis no teu código pode diminuir consideravelmente com essa belezinha, sem contar no tempo de desenvolvimento e aquele entra e sai de método/função pra ficar copiando o tipo da variável!

É interessante ressaltar a diferença para o comando EXACT. A diferença deste é que, se estivéssemos fazendo uma conversão de CHAR3 para CHAR2, o valor poderia ser truncado(ABC viraria AB )e nesse caso o comando EXACT nos retorna a exceção CX_SY_CONVERSION_DATA_LOSS, enquanto que o comando CONV simplesmente truncaria o valor.

E é isso povo, espero que gostem dessas utilidades que estamos colocando, até o próximo barLabs ;)

barLabs — CONV was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nesta série de posts, mostraremos rapidamente comandos novos que podem melhorar a qualidade do código e facilitar o seu trabalho. Então chega de blablabla, e…

No meu dia a dia, trabalho principalmente com desenvolvimento de produtos SAP e tenho que me preocupar principalmente com as versões mais antigas, tendo de usar uma sintaxe defasada. Portanto decidi começar com uma das coisas que realmente me incomoda, que é trabalhar com texto.

Seja para formatar um texto num Alv Tree ou num relatório, tenho que ficar chamando diversas funções de conversão em variáveis diferentes, jogando em textos temporários e concatenando parcialmente(e nem sempre o concatenate sai exatamente como quero), um exemplo simples é exibir número e série de Nota Fiscal:

Ou então utilizando o write to:

De ambas maneiras, o desenvolvedor acaba gastando um tempo “desnecessário” neste trecho do código.

Bom, se você está num programando num ambiente AS ABAP 7.0 Ehp 2 ou superior, então de um sorriso :) poderá utilizar do string template.

Falando de maneira boba, o string template é um texto que você fecha entre dois “|”.

Mas Adriano, e qual a vantagem?

A vantagem meu filho, é que além de escrever o texto da maneira como queremos que saia, também já podemos tratar as variáveis diretamente no texto.

O código anterior, ficaria muito mais simples:

Pra quem já trabalhou com javascript, acaba notando que a sintaxe é semelhante:

O único cuidado ai é que(e muito difícil que acabe acontecendo) é que esse comando só funciona em programas unicode.

Masss e o que podemos fazer? Dentro desses colchetes mágicos, podemos realizar contas, utilizar métodos funcionais, algumas funções predefinidas e muito mais, deixando o código menor e mais legível.

Caso precise utilizar de mais de uma linha para o seu texto( como por exemplo ao montar um JSON ou HTML rapidamente ), foi criado também um novo concatenate(&&). Quebrando o código acima um pouco apenas para exemplo:

E é isso, espero que tenham gostado do primeiro barLabs! Em próximos posts vamos mostrar algumas conveniências que vem sendo feitas e que diminuem um tanto a quantidade de código que precisamos digitar :)

barLabs — String Templates was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quando comecei a estudar ABAP Objects fiquei curioso com o bloqueio do acesso a atributos e métodos privados. Pensava horas e horas em como alterar um atributo privado de fora da instância.

Neste post, apresentarei duas maneiras de se alterar um atributo privado de uma instância em outro ponto que não seja dentro dela.

Usando GET REFERENCE

A minha primeira tentativa foi utilizando Field-symbols:

Lembro que na versão que testei, o código acima gerava um dump, porém no meu ambiente atual(SAP NW 7.40 SP 5), obtive apenas um sy-subrc = 4. De qualquer maneira, a tentativa é frustrada :(.

Após um tempo, aprendendo sobre a diferença entre parâmetros pass-by-value e pass-by-reference, percebi que poderia utilizar o comando GET REFERENCE para burlar o encapsulamento.

Em resumo, a diferença entre os dos tipos de parâmetro é que o primeiro cria uma variável local e apenas passa o valor para o parâmetro na conclusão da rotina, enquanto que o segundo sempre altera a variável original.

Sabendo disso, podemos criar um método que retorna um ponteiro para o atributo do nosso objeto:

Para testar:

Copie a classe, rode o programa e teste. O que acontece faz sentido? Como que a SAP pode permite um backdoor desses?

A documentação

O problema no código acima está no comando GET REFERENCE OF, se olharmos na documentação, encontramos a seguinte afirmação:

The context in which a data reference is acquired using GET REFERENCE determines whether or not the referenced data object can be changed. If the data object in the context of GET REFERENCE can be changed, it can be changed at any position also through the reference.

O exemplo que a SAP acaba dando na documentação é exatamente o que acontece no código acima, ou seja, o que acaba importando é QUANDO utiliza-se o comando GET REFERENCE e não ONDE a variável é alterada.

E existe problema nisso?

Não, de fato não existe. O fato de criarmos um método que retorna a referência mostra que existe intenção de que se quebre o encapsulamento e no final de contas, não existe uma grande diferença entre criar o método ou alterar o atributo para público. Isso é uma escolha do desenvolvedor e ele está ciente de que está fazendo isso.

Dando um exemplo em outra linguagem(Python) do que quero dizer quando falo que existe a “intenção” de expor o atributo, não existe nada forte que proíba o desenvolvedor de acessar um atributo privado, na verdade é algo cultural: “Não altere variáveis iniciadas em _ ou __”, sendo que o segundo caso utiliza de name mangling para esconder a variável:

Utilizando conceitos de OOP

A segunda solução surge mais de um erro comum de conceito de orientação a objeto e que varia de linguagem para linguagem:

No código acima um objeto acessa o atributo privado num_of_kidneys de outro objeto e altera seu valor, aparentemente quebrando o encapsulamento, afinal de contas, quando colocamos o algo como privado, a intenção é que seja algo privado e pertinente apenas a esse objeto e nesse caso um objeto altera um atributo de outro!

Lendo a documentação sobre seção privada, encontramos o seguinte:

All components of the class defined in the section behind the PRIVATE SECTION statement can only be addressed in the class itself.

A distinção é pequena mas clara: atributos e métodos privados podem sempre serem acessados quando dentro da CLASSE, nada se refere a instância na documentação.

E afinal, qual a utilidade disso/por que foi feito assim?

Beeeeeeem, caso você decida pesquisar na internet como é em outras linguagens, vai ver que existem várias pessoas com a mesma dúvida(C#, JAVA, C++, etc ) e que isso não acontece apenas em ABAP . Porém existe uma “desculpa” teórica que embasa uma explicação técnica

Explicação técnica

É complicado/lento ficar verificando o acesso a atributos ou métodos por outros objetos, muito mais simples deixar isso para a verificação de sintaxe ao código ser compilado. A verificação a nível de instância só existe em casos em que não se sabe ao certo o objeto que teremos naquele ponto do código.

“Desculpa” teórica

O modificador de acesso privado serve para encapsularmos na nossa classe o que não é relevante para o mundo externo, não importa realmente o que estamos fazendo dentro do método pois o que importa é que, quem cuida das alterações e chamadas privadas seja a classe.

Aplicação

Encontraremos aplicações deste conceito mais em outras linguagens como JAVA ou C++. Nestas linguagens existem conceitos como o copy constructor, onde cria-se uma instância de uma classe baseada em outra instância, ou então pode-se definir igualdade entre objetos e comparar os atributos que quiser, independentemente se eles são privados ou não.

Mas como podemos utilizar isso no ABAP?

Existem dois Design Patterns que podem ser implementados com isso

1. Factory
2. Prototype

Não vou entrar em detalhes sobre o Factory, pois o Prototype é mais interessante já que se assemelha um pouco ao copy_constructor, ou seja, serve basicamente para gerar uma cópia de uma instância da sua classe.

Fazendo um prototype beeeem simples(e idiota) com o exemplo anterior, podemos preencher os atributos privados do clone como quisermos(fazendo um monstrinho :)):

Uma segunda aplicação que existe em ABAP é durante o desenvolvimento de seus testes unitários. Pode ser que você sinta a necessidade de verificar a igualdade entre dois objetos.

Para isso a SAP criou a interface IF_AUNIT_OBJECT, que tem o método EQUALS_TO. Durante a execução do seu Teste Unitário, ao utilizar CL_ABAP_UNIT_ASSERT=>ASSERT_EQUALS, o programa verifica se você utiliza essa interface e realiza a comparação dos objetos que foi programada por você, um exemplo pode ser visto aqui(Porém esse método de comparação é obsoleto e foi substituído por isso aqui).

Então existem sim maneiras de acessar atributos privados em ABAP, porém são feitos de tal maneira que ou o trabalho é demais e é melhor mudar o atributo para público ou então não estamos quebrando encapsulamento, e isso pode ser uma ferramenta poderosa no nosso dia a dia!

E se curtiu o post não deixe de participar comentando, compartilhando ou simplesmente segurando esse botão de aplausos para mostrar que é esse tipo de conteúdo que você deseja ter por aqui. Muito obrigado e até mais!

Read the Fucking Documentation 02 was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nesta série de posts, apresentarei aparentes bugs que na verdade são erros de conceito e que estão bem documentados dentro do lindo botão F1 no código abap :)

Lidei com o problema que vou mostrar quando tive de utilizar as funções WS_DELIVERY_UPDATE e WS_REVERSE_GOODS_ISSUE. Essas funções são respectivamente utilizadas para lançar e estornar MIGOs baseadas em delivery, ambas são relativamente simples e não tem muitos parâmetros.

Quando utilizo uma seguida da outra, ou seja, na mesma transação o usuário quer lançar e depois estornar uma migo, o SAP acusa que a delivery relacionada a esta entrega não existe, mas se entrarmos novamente na transação, o estorno ocorre normalmente. Caso queira uma explicação mais detalhada, pode-se ler neste post da SCN que abri na época.

Pra se entender o porque deste comportamento, é legal começarmos pelos códigos. Leia, veja os resultados e caso não tenha entendido o que aconteceu, recomendo que crie um pacotinho ZBAR8 no seu ambiente do coração e replique estes códigos.

Vamos lá, anote a receita. Para replicar este cenário você vai precisar de:

• 1 programa que será utilizado pelo usuário
• 1 programa que vai causar o bafafa todo
• 2 funções em grupos de funções diferentes

O primeiro programa é:

O Include top dos dois grupos de função e suas funções respectivamente

E finalmente, o programa que rodaremos nos nossos testes:

Agora, o que você espera que aconteça quando rodarmos o programa acima? Ninguém está alterando a variável t100-text no programa z_resposta_cor, a não ser ele mesmo no form load_program que é chamado dentro das funções, portanto a saída deveria ser Nenhuma cor, correto? Bom, vamos ver…

Executando com a primeira opção, obtemos:

Executando a segunda opção, obtemos:

E ai?

Está tudo na documentação

Para entender o que está acontecendo aqui, precisamos entender o conceito de Grupo de Programas(PG).

Quando iniciamos uma sessão interna no SAP, o grupo de programas principal é iniciado e cada programa que é chamado que não seja um grupo de função(FG) ou um class-pool(CP, classe global, declarada na SE24), é adicionado ao grupo de programas atual. Cada FG e CP que é chamado posteriormente, cria um grupo de programas adicional, mas não pode utilizar programas já adicionados a grupos anteriores.

Os programas dentro de um grupo compartilham algo chamado Interface Work Area, um conjunto de variáveis que podem ser acessadas de qualquer programa nesse grupo. As variáveis que compõe esta área são declaradas utilizando TABLES, NODES, ou DATA BEGIN/END OF COMMON PART . No exemplo, foquei na declaração TABLES que é mais comum do que Nodes e Common part.

No programa acima temos a declaração TABLES t100 que está sendo utilizado em ambos os grupos de função e em um programa. O primeiro grupo que é chamado cria um PG e ao inicializar o programa Z_RESPOSTA_COR, faz com que o programa seja adicionado no PG deste grupo de funções, a próxima função já não faz isso pois o programa já está adicionado em um PG.

Veja bem, isto não é um bug, é uma funcionalidade da SAP que acaba realizando alterações implícitas em variáveis em programas distintos, causando confusão em você, em mim e em todos que estão envolvidos.

Para Finalizar

Como eu me safei dessa? Bom, para resolver meu problema sem que o usuário perdesse em usabilidade eu teria que fazer o SAP criar uma nova sessão interna, logo tive que encapsular a chamada de uma das duas funções em uma minha e chamar esta em uma sessão diferente(CALL FUNC STARTING NEW TASK).

Teoricamente, a mesma coisa poderia ser feita em classes globais, só que a SAP espertinha decidiu que, as declarações TABLES, NODES e COMMON PART não podem ser utilizadas no contexto OO(Você sabe porque?).

RTFD — 01 was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Qualquer um que trabalha com SAP há algum tempo já teve que ler um workbook de ABAP ou um documento de diretrizes de programação com as mais diversas regras de nomenclaturas de transações, programas, variáveis locais, elementos de dados, como fazer selects … enfim, a lista não termina.

A ideia por trás desses padrões é simples: facilitar a manutenção no código e evitar erros. Acontece que a maior parte dos padrões ou regras feitos nos documentos para SAP não fazem sentido nenhum e apenas estão lá pois quem fez aquele manual leu em outro manual a mesma coisa e pensou “Como já existe em algum manual, o meu só será bom se tiver também!”. Então nós somos obrigados a viver constantemente com :

Para nomear o seu programa, utilizar Z+R/M+MODULO+SUBMODULO+SEQUENCIA NUMERICA

ou então,

Nomear com algo que faz sentido, pegue a primeira letra de cada parte da descrição da funcionalidade: zihbtpr — iventory held by third parties report

Padrões de desenvolvimento são sim importantes, pois se aplicados corretamente, agilizam a leitura do código. Por exemplo, o que você prefere ler, o seguinte código:

Ou:

Quando lemos um código, quem está fazendo o parse deles é o nosso cérebro, e quanto mais consistente for a sua sintaxe, mais rápido entenderemos o que está acontecendo e assim, passamos menos tempo tentando entender o que estamos lendo, e sim, mais tempo analisando o que aquele código faz fisicamente.

Em geral, penso que as documentações focam em coisas idiotas e não comentam sobre ter um padrão no código.

Ter uma indentação padronizada, por exemplo, é muito mais importante do que colocar “boas e más maneiras de se fazer select”. Um código indentado com consistência é MUITO mais fácil de ler.

Uma diretriz normalmente “forçada” é a Notação Húngara. Existem duas vertentes nessa notação, não sei como traduzir então vou me referir a seus nomes em inglês:

• System Hungarian — Nomear variáveis em cima de seus tipos: t_bkpf (t_ indicando que é uma tabela);
• Apps Hungarian — Nomear variáveis em cima do que elas são e como são utilizadas no código: bkpf_fae(fae indicando que é uma variável utilizada para um for all entries, nada mais que isso).

No mundo fora do SAP, System Hungarian é considerado uma má pratica: atrapalha o entendimento , a leitura do código e normalmente é redundante. Já Apps Hungarian pode ter benefícios se utilizada corretamente. Uma boa leitura da utilização é “Making Wrong Code Look Wrong” de Joel Spolsky.

Nomear estruturas da SE11 começando com o que elas são (T para tabelas, por exemplo) é redundância numa linguagem onde a IDE é tão fortemente integrada como no ABAP, mas nomear variáveis em cima do que elas são pode te ajudar a notar possíveis erros e agilizar sua codificação. Concordo apenas com a necessidade de nomear variáveis globais para facilitar sua identificação, fora isso, se o programa está modularizado , as rotinas serão enxutas o suficiente para você ver a declaração na mesma tela que teu código. Um ótimo exemplo de uma linguagem em que se utiliza um tipo de notação Húngara é Python:

Em Python somos obrigados a prefixar variáveis e métodos privados com _ e __ para que o próprio compilador consiga entender o que deve fazer com esses objetos. Outro ponto que eu considero bacana é que a indentação é obrigatória para que o compilador possa entender o que está dentro de uma rotina ou não, fazendo com que esses dois aspectos sejam universais entre os programadores dessa linguagem.

Uma diretriz meio “natural” no mundo SAP que já ouvi reclamações (inclusive minha) é o padrão de utilizar os nomes das tabelas e estruturas da SE11 na declaração de variáveis, é algo que é muito confuso no início, mas ao longo do tempo aprendemos do que se trata cada tabela e como existe uma integração muito forte no SAP com o dicionário de dados, é fácil saber do que se trata a variável que estamos lidando.

No final de contas, o que deve ser feito é utilizar a cabeça, essa sim é uma boa diretriz de programação. Não é preciso ser informado por um manual que é uma má pratica utilizar header line ou que ficar alterando variáveis globais dentro de suas classes é algo problemático, afinal de contas, todos nós somos adultos responsáveis aqui!

Leituras interessantes:

• Are you writing Dirty Filthy ABAP Code?
• Clean Code: A Handbook of Agile Software Craftsmanship - Livros importados na Amazon.com.br

Diretriz de Programação was originally published in Bar8 on Medium, where people are continuing the conversation by highlighting and responding to this story.