Design de Aplicações - Parte 1

Regra geral, o desenvolvimento em ABAP limita-se a pequenas alterações que não necessitam de grande trabalho de design, como seja

1. Correcções a código Z
2. Criação de relatórios
3. Alteração de exits, BADI’s
4. Tratamento de input’s e output’s como IDOC’s, RFC’s, Webservices
5. Alteração de output’s de impressão ou envio de email com Smartforms, SAPScripts, PDF Forms
6. Automatização de fluxos de processos e processos em background
7. Criação de parametrização Z

O desenvolvimento em si de aplicações complexas já não é tão frequente, o que por si só justifica o facto de que não é fácil encontrar programadores que construam um dicionário de dados com qualidade e um programa com design adequado.

Este documento pretende contribuir para a forma de pensar do leitor no momento de desenho aplicacional.

E antes sequer de começar é preciso analisar a necessidade da própria aplicação. É possível usar o standard com a activação de EXIT’s ou BADI’s? Existe já alguma aplicação desenvolvida que pode ser expandida? Se possível deve-se recorrer ao standard uma vez que se garante que o processo funciona em qualquer situação e reduz custos de manutenção. Se houver alguma aplicação desenvolvida e que pode ser adaptada sem grande esforço então será essa a opção a escolher. A manutenção de aplicações replicadas deve ser evitada.

Dicionário de dados

O desenho de tabelas em SAP deve seguir algumas regras de boas práticas de forma a:

• Reduzir a quantidade de objectos criados;
• Facilitar a leitura por outros membros da equipa;
• Respeitar a rastreabilidade de alterações;
• Obviamente, garantir a boa construção respeitando pelo menos a 3ª forma normal das bases de dados relacionais.

A primeira regra a usar é verificar a necessidade da tabela. Se os dados podem ser guardados em algum lugar, preferencialmente standard, então a nova tabela não deve ser criada. Por exemplo, dados dependentes do utilizador podem ser guardados como parâmetros nos dados mestre de utilizador. Dados de materiais podem ser guardados no sistema de classificação. Dados mestre de área de vendas podem ser guardados num append à tabela TVTA.

Criar uma tabela tem custos muito elevados de manutenção e deve ser evitado a todo o custo. Se não se puder evitar e for uma tabela de parametrização então deve ser colocada de forma a ser facilmente visível a qualquer novo consultor que necessite a efectuar, por exemplo, pode ser colocada na SPRO.

A segunda regra é respeitar as convenções de nomenclatura, inclusivamente a definida para o projecto. Segue de seguida uma lista de algumas regras adicionais que podem não estar presentes na global:

• Utilizar nomes de campos e elementos de dado standard sempre que possível (por exemplo WERKS e não CENTRO). Para além do nome ser mais óbvio para outros, esta prática permite ao programador interiorizar o modelo de dados da SAP. Esta regra pode ser quebrada para interfaces como BAPI’s e RFC’s mas mesmo assim existe a convenção para os BAPI’s onde aparece um nome mais completo e em inglês. Por exemplo, o nº de fornecedor é LIFNR (Lieferant Nummer em alemão) nas tabelas standard e VENDOR (em inglês) para os BAPI’s.
• Se não existe um nome standard para o campo da tabela criar um elemento de dados Z e o respectivo domínio Z, preencher com detalhe as denominações do campo e sempre que possível restringir os valores. Não criar todos os objectos é preguiça e reduz desnecessariamente a qualidade de informação do campo.
• Criar e associar sempre que necessário ajudas de pesquisa para os campos novos.

A terceira regra diz respeito à rastreabilidade. Todas as tabelas devem ter de alguma forma associada a informação de:

• Utilizador que criou registo;
• Utilizador que modificou registo;
• Data de criação de registo;
• Data de modificação de registo;
• Hora de criação de registo;
• Hora de modificação de registo.

Também é boa prática em alguns casos que as tabelas de parametrização tenham um intervalo de validade:

• Data de fim de validade, deve ser campo chave;
• Data de início de validade.

A quarta regra refere-se ao respeito da 3ª forma normal. Geralmente um conjunto de novas tabelas aplicacionais pretende guardar um documento, e na maioria dos casos um documento é composto por:

• Cabeçalho;
• Item;
• Algumas vezes, Subitem.

Cada um destes conjuntos de informação deve ser colocado numa tabela em separado. Pode ainda ocorrer mais divisão de informação consoante a natureza da mesma. Por exemplo, pode haver duas tabelas ao nível do item para tipos de item distintos.

Segue um exemplo de organização de tabelas como é efectuado no SAP Standard para guardar os Documentos de Compra:

O Cabeçalho tem dados como o fornecedor e a data, o Item a informação do material e quantidade solicitada, as Divisões de Remessa a quantidade do item solicitada por data de entrega desejada e finalmente as confirmações têm a quantidades e datas previstas de entrega que o fornecedor confirmou.