Nesse artigo serão abordadas boas práticas da linguagem ABAP, utilizada para o desenvolvimento de programas no ambiente SAP.
Introdução
A sigla ABAP significa Advanced Business Application Programming e foi criada pela empresa SAP nos anos 80.
Ela é considerada uma linguagem de quarta geração (de alto nível com objetivos específicos), e foi criada
para permitir o desenvolvimento de relatórios, visando complementar as funcionalidades existentes no ERP da SAP.
Com o tempo, o ABAP passou a ser utilizado principalmente para customizar as funcionalidades dos módulos da SAP e em
1999, foi lançada uma versão com Orientação à Objetos.
Características da Linguagem
Os programas ABAP ficam armazenados dentro da base de dados do ambiente SAP. Eles não são armazenados em arquivos
separados como em outras linguagens, tais como Java e C#.
Na base de dados do ambiente SAP, o código de ABAP existe em dois formulários: o código-fonte, que pode ser visto
e editado com as ferramentas de ABAP (Workbench), e o código gerado, uma representação binária semelhante a um bytecode
do Java.
Os programas ABAP são executados sob um sistema de runtime, que é parte do núcleo SAP. O sistema de runtime é responsável
por processar os comandos ABAP, controlar a lógica do fluxo das telas e responder pelos eventos (Exemplo: um clique de
usuário).
Um componente chave do sistema de runtime em ABAP é em relação ao banco de dados, que converte comandos SQL da base de dados
independente do ABAP (Open SQL), para os comandos correspondentes do DBMS subjacente (Native SQL). A interface com o banco
de dados contém funcionalidades extras, como por exemplo a proteção de dados freqüentemente alcançados na memória local do servidor
de aplicações.
O ambiente SAP possui três camadas diferentes: a camada de apresentação (GUI), a camada de aplicação (onde são executados
os programas) e a camada de dados (DBMS).
Segue figura contendo a arquitetura do ambiente SAP, que demonstra o funcionamento do ABAP:
Arquitetura ERP SAP - ABAP
Boas Práticas
Convenção de Nomes
Os nomes dos objetos Z no SAP devem ser autoexplicativos e coerentes com sua utilização.
Exemplo: Declarar a variável lv_indice ao invés de lv_i, declarar a workarea wa_parceiro ao invés de wa_p1, etc.
Modularização
O desenvolvimento do código deve ser modularizado, de forma a organizá-lo para facilitar a sua manutenção. Nesse contexto, podemos utilizar Orientação
a Objetos (Classes), módulos de função ou forms para agrupar funcionalidades em um programa ABAP.
Dessa forma, permitimos o reuso e garantimos uma boa manutenibilidade do código, em caso de atualizações, correções de bugs ou adição de novas features.
Separação de Responsabilidades
Deve-se assegurar que as classes, programas, módulos de função e demais recursos tenham responsabilidades claras e distintas, de acordo com o princípio SRP, presente
no modelo SOLID de Engenharia de Software (SRP: Single Responsibility Principle - Princípio da Responsabilidade Única). Dessa forma, é possível
garantir um desenvolvimento robusto e fácil de manter.
Documentação
O código-fonte ABAP deve ser documentado de forma clara e completa, sem excessos, para ajudar na manutenibilidade e permitir a compreensão
por outros desenvolvedores.
Visualização do Código (Pretty Printer)
Para melhorar o entendimento do código-fonte, é importante sempre mantê-lo com a identação adequada. O editor ABAP/4 tem um comando "Pretty Printer"
para identar linhas específicas de código e adicionar comentários de sub-rotina.
Visando facilitar a leitura e interpretação do código, é recomendável utilizar esse recurso sempre.
Para acessar o pretty printer no ABAP do SAP, você pode escolher a opção de menu Utilitários -> Configurações e depois selecionar a guia
“Editor ABAP” e em seguida “Pretty Printer” na subseção.
Configuração Pretty Printer
Seleção dos campos individualmente (Não utilizar SELECT *)
Em geral, deve ser utilizado um comando SELECT especificando uma lista de campos em vez de um SELECT * para reduzir
tráfego de rede e melhorar desempenho. Diversas tabelas do ambiente SAP contêm muitos campos e consultas realizadas
nelas podem ter ganhos de performance.
Por exemplo: A tabela DFKKOP do módulo CCS IS-U armazena os itens de documentos de contas-contrato e possui muitos campos,
uma consulta contendo uma lista restrita de campos pode apresentar melhorias significativas de performance em relação a uma consulta com SELECT *.
Utilização de FOR ALL ENTRIES ao invés de INNER JOIN
Visando melhorar a performance das consultas, é recomendável carregar os registros em uma tabela interna
e utilizar o comando FOR ALL ENTRIES, ao invés de utilizar INNER JOIN.
Antes de usar o comando FOR ALL ENTRIES, é obrigatório usar os comandos SORT e DELETE ADJACENT DUPLICATES
da referida tabela. Se FOR ALL ENTRIES for usado em uma tabela vazia, a consulta retornará todas as entradas
do banco de dados e resultará em problemas de desempenho.
Utilização de objetos LOCK
Para evitar inconsistências de dados, é necessário bloquear objetos de negócios antes de alterá-los.
Os objetos de negócios relacionados só devem ser alterados se a atualização de todas as entidades relacionadas tiverem
sido bem-sucedidas. Os comandos ENQUEUE (bloquear objeto) e DEQUEUE (desbloquear
objeto) devem ser utilizados quando a tabela em questão for atualizada.
Exemplo Código-fonte ABAP: LOCK de Tabela
Performance de Programas - ST05
Visando avaliar a performance dos programas, com a transação ST05 é possível realizar um trace de forma a identificar os pontos
de melhoria e possíveis gargalos no código-fonte ABAP, para permitir a sua refatoração. O SQL trace, por exemplo, mostra o tempo
gasto nas consultas SQL.
Transação ST05 - Performance SQL Trace Exemplo - Resultado SQL Trace
Code Inspector
A transação SCI - Code Inspector permite uma validação do código-fonte, ela indica bugs e pontos de melhoria no código-fonte ABAP.
Code Inspector Exemplo - Resultado Code Inspector - Warnings na convenção de nomes utilizada
Transações Úteis
Segue lista contendo transações úteis para o desenvolvimento ABAP:
