Manual de Padronização Desenvolvimento Abap_v1.1

PADRÕES DE DESENVOLVIMENTO

ABAP

Este material é de propriedade intelectual da Procwork.

Manual de Padronização Desenvolvimento Abap.doc Página 1 de 44

ÍNDICE

1. INTRODUÇÃO.....................................................................................................................................................4

2. IDENTIFICAÇÃO DO OBJETO........................................................................................................................5

2.1. HEADER..........................................................................................................................................................52.2. ALTERAÇÕES DE CÓDIGO........................................................................................................................6

3. COMENTÁRIOS..................................................................................................................................................7

3.1. PONTOS CHAVES........................................................................................................................................73.2. SITUAÇÕES....................................................................................................................................................73.3. FORMA............................................................................................................................................................83.3.1. DECLARAÇÃO DE COMENTÁRIOS EM TABELAS TRANSPARENTES ..................................................................83.3.2. DECLARAÇÃO DE COMENTÁRIOS EM CONSTANTES ........................................................................................83.3.3. DECLARAÇÃO DE COMENTÁRIOS EM TIPOS .....................................................................................................93.3.4. DECLARAÇÃO DE COMENTÁRIOS EM TABELAS INTERNAS ..............................................................................93.3.5. DECLARAÇÃO DE COMENTÁRIOS EM ESTRUTURAS .........................................................................................93.3.6. DECLARAÇÃO DE COMENTÁRIOS EM FIELD-SYMBOL ....................................................................................103.3.7. DECLARAÇÃO DE COMENTÁRIOS EM VARIÁVEIS ...........................................................................................103.3.8. DECLARAÇÃO DE COMENTÁRIOS EM RANGES ...............................................................................................103.3.9. DECLARAÇÃO DE COMENTÁRIOS EM CONTROLS ..........................................................................................103.3.10. DECLARAÇÃO DE COMENTÁRIOS EM MACROS .........................................................................................113.3.11. DECLARAÇÃO DE COMENTÁRIOS DEFINIÇÕES DE CLASSES ....................................................................113.3.12. DECLARAÇÃO DE COMENTÁRIOS IMPLEMENTAÇÕES DE CLASSES ..........................................................113.3.13. DECLARAÇÃO DE COMENTÁRIOS EM PARAMETERS E SELECT-OPTIONS ................................................123.3.14. DECLARAÇÃO DE COMENTÁRIOS EM EVENTOS ........................................................................................123.3.15. DECLARAÇÃO DE COMENTÁRIOS EM SEQÜÊNCIAS DE COMANDOS .........................................................123.3.16. DECLARAÇÃO DE COMENTÁRIOS EM FORMS ............................................................................................13

4. ORGANIZAÇÃO DOS CÓDIGOS FONTES................................................................................................14

4.1. HIERARQUIA DE DECLARAÇÕES..........................................................................................................144.2. IDENTAÇÃO, ALINHAMENTO E ESPAÇAMENTO...............................................................................15

5. NOMENCLATURA............................................................................................................................................17

5.1. VARIÁVEIS....................................................................................................................................................175.1.1. DECLARAÇÃO DE CONSTANTES .....................................................................................................................175.1.2. DECLARAÇÃO DE TIPOS ..................................................................................................................................185.1.3. DECLARAÇÃO DE PARAMETERS E SELECTION-OPTIONS ..............................................................................185.1.4. DECLARAÇÃO DE VARIÁVEIS ..........................................................................................................................185.1.5. DECLARAÇÃO DE RANGES ..............................................................................................................................195.1.6. DECLARAÇÃO DE TABELAS INTERNAS ...........................................................................................................195.1.7. DECLARAÇÃO DE ESTRUTURAS .....................................................................................................................195.1.8. DECLARAÇÃO DE FIELD-SYMBOL ...................................................................................................................205.1.9. DECLARAÇÃO DE TELAS DE MODULE POOL .................................................................................................205.2. IDENTIFICAÇÃO DA APLICAÇÃO...........................................................................................................215.3. OBJETOS DE PROGRAMA.......................................................................................................................215.3.1. PROGRAMA / FORMULÁRIOS.................................................................................................................225.3.2. MODELO..........................................................................................................................................................225.3.3. CLASSE.........................................................................................................................................................235.3.4. VARIANTE.....................................................................................................................................................235.3.5. CAMPO GLOBAL.........................................................................................................................................235.3.6. EVENTO........................................................................................................................................................245.3.7. SUB-PROGRAMA (FORMS)........................................................................................................................245.3.8. MACRO..........................................................................................................................................................255.3.9. TELA...............................................................................................................................................................255.3.10. STATUS GUI............................................................................................................................................25


5.3.11. TÍTULO GUI..............................................................................................................................................255.3.12. INCLUDE...................................................................................................................................................265.3.13. TRANSAÇÃO...........................................................................................................................................265.3.14. MÓDULO DE DIÁLOGO.........................................................................................................................275.4. OBJETOS DO DICIONÁRIO......................................................................................................................285.5. OBJETOS DE GRUPO DE FUNÇÃO.......................................................................................................295.6. OUTROS OBJETOS....................................................................................................................................305.6.1. CLASSE DE DESENVOLVIMENTO OU PACOTE.................................................................................305.6.2. REQUEST......................................................................................................................................................315.6.3. BANCO DE DADOS LÓGICO....................................................................................................................315.6.4. ID PARÂMETRO SET/GET........................................................................................................................315.6.5. MENU DE ÁREA..........................................................................................................................................325.6.6. CLASSE DE MENSAGEM..........................................................................................................................325.6.7. NÚMERO DE MENSAGEM........................................................................................................................325.6.8. AUTHORITY-CHECK..................................................................................................................................325.6.9. MEMORY-ID..................................................................................................................................................335.6.10. BATCH INPUT (PASTAS).........................................................................................................................335.7. BUSINESS ENGINEERING........................................................................................................................345.7.1. MODELO DE DADOS..................................................................................................................................345.7.2. TIPO DE ENTIDADE....................................................................................................................................345.7.3. CATEGORIA DE OBJETO BUSINESS....................................................................................................35

6. LAY-OUT............................................................................................................................................................35

6.1. LAY-OUT DE TELA......................................................................................................................................356.2. LAY-OUT DE SAIDA (RELATÓRIO).............................................................................................................35

7. NORMAS DE PROGRAMAÇÃO....................................................................................................................36

7.1. TABELAS INTERNAS..................................................................................................................................367.2. PARÂMETROS DE SELEÇÃO..................................................................................................................377.3. DECLARAÇÃO DE VARIÁVEIS................................................................................................................377.4. DECLARAÇÃO DE EVENTOS..................................................................................................................377.5. DECLARAÇÃO DE SUBROTINAS (FORMS).........................................................................................387.6. CÁLCULOS...................................................................................................................................................387.7. COMANDO MOVE-CORRESPONDING..................................................................................................387.8. COMANDO DESCRIBE..............................................................................................................................387.9. COMANDO CASE........................................................................................................................................387.10. COMANDO LOOP........................................................................................................................................397.11. COMANDO WHILE......................................................................................................................................397.12. COMANDO SORT........................................................................................................................................407.13. COMANDO SELECT...................................................................................................................................407.14. COMANDO INTO TABLE............................................................................................................................417.15. COMANDO FREE........................................................................................................................................417.16. ÍNDICE...........................................................................................................................................................417.17. CÓDIGO MORTO.........................................................................................................................................417.18. COMANDO READ TABLE..........................................................................................................................427.19. VERIFICAÇÃO EXTENDIDA DE SINTAXE.............................................................................................427.20. ANÁLISE DO TEMPO DE EXECUÇÃO...................................................................................................427.21. CRIAÇÃO DE LITERAIS.............................................................................................................................427.22. PROGRAMAÇÃO PARA O MODULO DE HR (HUMAN RESOURCES)............................................437.23. NOTAS OSS..................................................................................................................................................44


1. INTRODUÇÃO

Esse documento tem como objetivo definir padrões de metodologia e nomenclatura a serem utilizados nos desenvolvimentos de objetos ABAP no sentido de obter um produto final com qualidade.

A aplicação das diretrizes contidas nesse documento é de responsabilidade de cada consultor.

Serão fornecidos esclarecimentos, e modelos de documentos formais necessários ao acompanhamento e documentação das atividades a serem seguidas pela equipe.

Importante !

Nunca comece a desenvolver ou alterar um objeto sem antes ter em mãos as seguintes informações:

A Especificação Técnica; A Classe de Desenvolvimento (Pacote nas versões mais novas do SAP); A “Request”; A “Task”.


2. IDENTIFICAÇÃO DO OBJETO

A identificação de um objeto ABAP sempre envolverá um “Header” padrão conteúdo informações como, nome do programa, transação, modulo SAP utilizado, quem criou o objeto, entre outros dados. Tal “Header” deve estar presente, ou seja, sempre que o objeto ABAP o permitir e na forma como será apresentado nesse tópico. Em termos gerais, pode-se considerá-los como parte integrante de todo código gerado, independendo do tipo do mesmo.

2.1. HEADER

Deverá estar localizado nas primeiras linhas do código fonte. Para padronizar os desenvolvimentos o template deve ser seguido à risca, inclusive na ordem em que as informações são exibidas e nos ‘*’ e ‘-‘ que aparecem nas linhas. Vide o exemplo abaixo de um “Header”:

*-----------------------------------------------------------------------* Programa : ZPSDR_001* Cliente :* Módulo :* Transação:* Descrição: Programa de conversão de dados para* o cadastro de materiais* Autor: Fulano da Silva Data: dd.mm.aaaa*-----------------------------------------------------------------------* Histórico de Alterações:*-----------------------------------------------------------------------* Data |Change # |Autor |Alteração*-----------------------------------------------------------------------* dd.mm.aaaa |DEVK009012 |Fulano da Silva |Desenvolvimento Inicial* dd.mm.aaaa |DEVK009034 |Sicrano da Silva |Descrição da Alteração*-----------------------------------------------------------------------

Observações:

A linha de comentário é tracejada e não termina com asterisco (*), essa regra deve valer para todos os códigos gerados sob a Metodologia da Procwork;

Não existe um número de linhas pré-definido para os itens Cliente, Módulo, Transação, Descrição, procure apenas ser objetivo;

Nas sentenças, tentar usar o máximo da linha disponível para o comentário, simulando os espaçamentos necessários e seguindo as regras de hifenização e acentuação.

Quando o programa alterado é um INCLUDE de outro programa, deve ser inserido no cabeçalho do programa principal a linha referente à alteração do include, constando os dados da alteração como data, request e autor.


2.2. ALTERAÇÕES DE CÓDIGO

Sempre que seja necessário alterar um código que já está pronto, devem ser incluídas TAGs no código, informando a data e o autor da alteração, determinando qual parte do código foi alterada ou incluída.

O padrão a ser utilizado deverá ser o seguinte:

“ >>> dd.mm.aaaa – Fulano da Silva...“ <<< dd.mm.aaaa – Fulano da Silva

Observações: A linha de comentário deve seguir sempre o mesmo padrão, iniciando por aspas (“)

seguido de espaço e três sinais de maior (ou menor). Logo após espaço a data, novo espaço, hífen, outro espaço e nome do autor.


3. COMENTÁRIOS

A padronização no que se refere aos comentários adicionados ao código ABAP deve ser implementada de forma objetiva. Nesse tópico, será apresentado os pontos, situações e a forma que o consultor deve basear-se no momento de criar seus comentários.

O objetivo dos comentários é esclarecer a lógica de programação utilizada em uma dada solução, com isto, caso seja necessário realizar manutenção no programa, outros consultores conseguiram interpretar com maior facilidade as regras de negócio existente.

O consultor deverá efetuar os seus comentários utilizando-se do seu bom senso. Como sugestão use o ‘Princípio da Expectativa’, onde a elaboração de certos comentários deverá basear-se na expectativa que o próprio executor gostaria de encontrar, se o mesmo estivesse na posição de ‘entender’ o código que está sendo gerado.

3.1. PONTOS CHAVES

Entenda-se por comentário, toda e qualquer string que não faça parte da linguagem ABAP, mas que caracterize ou identifique elementos da mesma, bem como toda descrição referente aos “Forms” e as soluções encontradas e empregadas na construção da lógica de programação.

Sendo assim, consideram-se como pontos chaves a serem comentados e monitorados pelo Controle da Qualidade:

Seções do Código: toda seção de declaração deverá apresentar a sua correspondente identificação, o mesmo estendendo-se para as ‘Telas de Seleção’;

Data Dictionary Objects: todos os objetos independendo entre os ‘standard’ do sistema R/3 ou os que forem gerados de acordo com as necessidades apontadas pela especificação técnica;

Data: todas as declarações deverão estar devidamente comentadas ou identificadas conforme o ‘data dictionary’, estendendo-se as declarações envolvendo ‘Constants’ e ‘Parameters’;

Types: todas as declarações deverão estar comentadas, principalmente no que tange aos campos utilizados;

BDC_Table: identificação dos campos e ações executadas pelos elementos pertencentes a uma tela.

3.2. SITUAÇÕES

Esse tópico é estritamente ligado ao chamado ‘bom senso’ do consultor, pois ele arbitrará em seu código quais os trechos que necessitam estar comentado. É comum cada solução apresentar particularidades por esta razão cada objeto criado poderá apresentar um grau maior ou menor de detalhamento através dos comentários adicionados ao código ABAP.

Lembrar que um objeto devidamente comentado reduz o tempo e aumenta a qualidade da documentação a ser apresentada a Área Técnica e/ou cliente.


3.3. FORMA

Nesse tópico será apresentado exemplo de comentários que os consultores devem utilizar em seus respectivos desenvolvimentos.

Observação: Caso precise eliminar temporariamente a ação de uma linha, o uso do (*) é livre, mas se ao término do objeto, concluir-se que a mesma não é mais necessária ao processamento, a mesma deverá ser eliminada para não caracterizar uma ‘poluição visual’ e um aumento desnecessário de linhas que não precisaram ser consideradas no entendimento da lógica do objeto.

3.3.1. Declaração de comentários em Tabelas Transparentes

Declaração de tabelas do dicionário de dados que serão utilizadas em um programa. Antes da declaração das tabelas transparentes é necessário identificar a área com um cabeçalho padrão, e após as declarações de tais tabelas é necessário incluir um comentário de meia linha contendo breve descrição da tabela, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Tabelas do Dicionário de Dados*-----------------------------------------------------------------------TABLES: tabela. “ Breve descrição da tabela

3.3.2. Declaração de comentários em Constantes

Todo a literal fixa em um programa deve ser representada por meio de uma constante (com exceção de comparação com o SY-SUBRC e cálculos numéricos simples do tipo a = a + 1). Antes da declaração das constantes é necessário identificar a área com um cabeçalho padrão, e após as declarações de tais constantes é necessário incluir um comentário de meia linha contendo breve descrição da mesma, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Definição de Constantes*-----------------------------------------------------------------------CONSTANTS: cc_texto type c value ‘X’. Descrição da constante.


3.3.3. Declaração de comentários em Tipos

É recomendável (por questões de organização de código) que toda declaração de tabela interna utilize um TYPE. Antes da declaração dos tipos é necessário identificar a área com um cabeçalho padrão, e após as declarações é necessário criar um comentário inicial (utilizar *) para indicar a finalidade do tipo e cada campo deste tipo deve possuir um comentário de meia linha contendo breve descrição do campo, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Definição de Tipos*-----------------------------------------------------------------------TYPES:

*** Descrição da finalidade do tipo BEGIN OF ys_mara, matnr type mara-matnr, “ Descrição do campo END OF ys_mara.

3.3.4. Declaração de comentários em Tabelas Internas

Deve ser utilizado um cabeçalho padrão para identificar a área de criação de tabelas interna e após a declaração das mesmas incluir um comentário (utilizar *) contendo breve descrição destes objetos, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Definição de Tabelas Internas*-----------------------------------------------------------------------DATA:

*** Descrição da utilização da tabela internagt_mara type standard table of ys_mara.

3.3.5. Declaração de comentários em Estruturas

Deve ser utilizado um cabeçalho padrão para identificar a área de criação de estruturas e após a declaração das mesmas incluir um comentário (utilizar *) contendo breve descrição destes objetos, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Definição de Estruturas*-----------------------------------------------------------------------DATA:

*** Descrição da utilização da estruturags_mara type ys_mara.


3.3.6. Declaração de comentários em Field-Symbol

Deve ser utilizado um cabeçalho padrão para identificar a área de criação de field-symbol e após a declaração das mesmas incluir um comentário (utilizar *) contendo breve descrição destes objetos, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Definição de Field-Symbols*-----------------------------------------------------------------------FIELD-SYMBOLS:

*** Descrição da utilização do field-symbol<fs_mara> type ys_mara.

3.3.7. Declaração de comentários em Variáveis

Deve ser utilizado um cabeçalho padrão para identificar a área de criação de variáveis e após a declaração das mesmas incluir um comentário de meia linha contendo breve descrição destes objetos, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Definição de Variáveis*-----------------------------------------------------------------------DATA: gn_var1 type n. “ Descrição da variável global

3.3.8. Declaração de comentários em Ranges

Deve ser utilizado um cabeçalho padrão para identificar a área de criação de ranges e após a declaração dos mesmas incluir um comentário de meia linha contendo breve descrição destes objetos, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Definição de Ranges*-----------------------------------------------------------------------DATA: gr_matnr type range of mara-matnr, “ Descrição do range gs_matnr like line of gr_matnr, “ Linha do range

3.3.9. Declaração de comentários em Controls

Deve ser utilizado um cabeçalho padrão para identificar a área de criação de controls (tablecontrol) e após a declaração dos mesmos incluir um comentário de meia linha contendo breve descrição destes objetos, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Definição de Controls*-----------------------------------------------------------------------CONTROLS: tb_email type tableview using screen 9000. “ Descrição breve


3.3.10. Declaração de comentários em Macros

Deve ser utilizado um cabeçalho padrão para identificar a área de criação de macros e após a declaração dos mesmos incluir um comentário contendo breve descrição destes objetos, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Definição de Macros*-----------------------------------------------------------------------*** Macro para realizar a tarefa XXXXXDEFINE macro_nome. ...

3.3.11. Declaração de comentários Definições de Classes

Deve ser utilizado um cabeçalho padrão para identificar a área de definições de classes e após a declaração das mesmas incluir um comentário contendo breve descrição destes objetos, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Class Definition*-----------------------------------------------------------------------*** Classe para realizar o processo XXXXXCLASS xxxx DEFINITION. ...ENDCLASS.

3.3.12. Declaração de comentários Implementações de Classes

Deve ser utilizado um cabeçalho padrão para identificar a área de implementações de classes e após a declaração das mesmas incluir um comentário contendo breve descrição destes objetos, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Class Implementation*-----------------------------------------------------------------------*** Classe para realizar o processo XXXXXCLASS xxxx IMPLEMENTATION. ...ENDCLASS.


3.3.13. Declaração de comentários em Parameters e Select-options

Deve ser utilizado um cabeçalho padrão para identificar a área de criação de objetos de seleção e após a declaração dos mesmos incluir um comentário de meia linha contendo breve descrição destes objetos, vide o exemplo abaixo:

*-----------------------------------------------------------------------* Definição da Tela de Seleções*-----------------------------------------------------------------------PARAMETERS: pc_param type c. “ Descrição do parâmetroSELECT-OPTIONS: so_name for mara-matnr. “ Descrição do campo

3.3.14. Declaração de comentários em Eventos

Deve ser utilizado um cabeçalho padrão para identificar a área de criação dos eventos que um programa venha a possuir (start-of-selection, end-of-selection, por exemplo), vide o exemplo abaixo:

*-----------------------------------------------------------------------* Evento: Start-of-Selection*-----------------------------------------------------------------------START-OF-SELECTION. ... (codificação)

3.3.15. Declaração de comentários em seqüências de comandos

Todas as seqüências de comandos devem ser comentadas por aspas (“) no início da linha precedendo o texto de comentário. Além disso, deve existir uma linha em branco antecedendo o comentário. Vide o exemplo abaixo:

<linha em branco>“ Lê as linhas do arquivo de ICMSREAD DATASET pc_file INTO gs_record.


3.3.16. Declaração de comentários em forms

Todo form a ser criado pelo consultor deve possuir um cabeçalho padrão conforme o exemplo abaixo:*-----------------------------------------------------------------------* Form: zf_calcula_icms* Descrição: Cálculo do ICMS para os produtos* Entradas: pu_produto “ Código do produto* Saídas: N/A*-----------------------------------------------------------------------

Observação: tanto os parâmetros de entrada como os de saída devem ser declarados contendo o texto fixo pY_ seguido de uma string que identifique o parâmetro. Sendo Y o identificador do tipo de parâmetro utilizado.

U UsingC ChangingT Tables


4. ORGANIZAÇÃO DOS CÓDIGOS FONTES

Esse tópico e seus itens estão relacionados com a estruturação a ser seguida pelo consultor na codificação dos objetos ABAP. Basicamente serão abordados os seguintes assuntos:

Hierarquia de declarações; Identação, alinhamento e espaçamento.

4.1. HIERARQUIA DE DECLARAÇÕES

Na estrutura de todo objeto ABAP que admita linhas de codificação, será observada a hierarquia de declarações como segue logo mais abaixo. Observar que a aplicação da hierarquia está vinculada a existência da declaração dentro do objeto, caso a declaração não se aplique ao objeto a mesma não deve estar referenciada na estrutura. A hierarquia a ser seguida apresenta-se com a seguinte seqüência:

Tabelas; Constantes; Tipos; Tabelas Internas; Field-Symbol; Data; Controls; Macros; Class Definition; Class Implementation; Tela de Seleção; Eventos; Procedures (forms).

No caso de procedures (Forms) e class implementation a hierarquia de declarações que se faça necessária deve seguir como acima ilustrado.


4.2. IDENTAÇÃO, ALINHAMENTO E ESPAÇAMENTO

As regras principais a serem observadas pelo consultor referem-se a forma de apresentar as instruções no código do objeto. O primeiro contato com um código é o visual, seguido do analítico. No primeiro contato transmite-se ao cliente a qualidade do(s) serviço(s) prestado(s), a experiência tem mostrado quanto um código ‘bem escrito’ é apreciado e esperado, por parte do corpo técnico dos clientes. O consultor tem que ter ciência que um código ‘bem escrito’ muitas vezes faz o papel do seu cartão de visita e a qualidade apresentada uma ferramenta poderosa de ‘marketing’ para a sua empresa.

O segundo contato, o analítico, refletirá seus resultados em entendimento e tempo de resposta a solicitação de alteração(ões) como decorrência do primeiro contato. Se o primeiro tem um peso na qualidade, o segundo tem em seu peso além da qualidade o fator tempo.

Em termos práticos, a identação a ser aplicada nos códigos ABAP deverá ser de fator dois (2), ou seja, dois espaços em branco.

O alinhamento levará em conta a identação aplicada e deverá ser aplicado sempre que o código permitir, como por exemplo, na declaração de data com seus respectivos tipos e comentários.

Como já foi ilustrado no tópico sobre ‘Comentários’, o alinhamento deverá obedecer ao seguinte critério, a posição do alinhamento de uma série de comentários ou tipos correlatos, será definida pelo início da maior ‘string’, visto que o término da mesma estará ocorrendo a direita na última coluna.

Em relação ao espaçamento utilizado entre as linhas de código, o critério sugerido visto que não é obrigatório, é usar apenas uma linha. Não é objeto desse trabalho a definição dos locais em que o consultor deverá utilizar um espaçamento dentro de um código.

Porém, ilustramos o uso não esperado do recurso, ou seja, entre a declaração de data e constantes ou dentro de um mesmo bloco lógico de comandos, por exemplo, as estruturas condicionais e as estruturas simples que caracterizam laços.

Para um melhor entendimento do que foi descrito acima, ilustramos a seguir uma tela como exemplo a ser seguido.


Observação: Para manter o layout do código uniforme, todos os desenvolvedores deverão utilizar a funcionalidade “Pretty Printer” do editor para auxiliar na identação do código fonte.

A configuração do Pretty Printer deve incluir todas as palavras chaves em letras maiúsculas.


Espaçamento entre linhas nos blocos de comandos.

5. NOMENCLATURA

Todos os objetos criados pelos consultores nos projetos sob a responsabilidade da Procwork deverão seguir a nomenclatura proposta nesse documento, salvo os casos onde se faça uso da metodologia do cliente ou de parceiros.

Como convenção, adotaremos apenas a letra ‘Z’ para identificação de objetos R/3.O ambiente de desenvolvimento, quanto ao repositório de objetos do sistema R/3,

pode ser dividido por tipos de objetos, conforme seguem abaixo:

Objetos de Programa; Objetos do Dicionário; Objetos de Grupo de Função; Objetos Privados Locais; Business Engineering; Outros Objetos.

Observe que alguns objetos são comuns entre os tipos citados acima e sendo assim, as correspondentes nomenclaturas serão referenciadas apenas uma vez. As declarações de variáveis recebem um tópico dedicado, visto que sua aplicação na construção dos objetos deve seguir a mesma nomenclatura independendo do tipo do mesmo.

Nos tópicos relacionados a seguir, serão apresentadas tabelas ilustrativas quanto à nomenclatura a ser empregada na identificação dos objetos.

5.1. VARIÁVEIS

O sistema R/3 no seu ambiente de desenvolvimento pode trabalhar com variáveis (campos globais ou locais), o consultor deverá nomear todas as variáveis conforme ilustração, seguida do sinal ‘underscore’ ( _ ), mais o nome, ou nomes que melhor identifiquem o conteúdo da variável com o sinal ‘underscore’ entre os nomes.Para definir o tipo da variável, procurar utilizar a opção TYPE.

5.1.1. Declaração de Constantes

Todas as constantes devem começar por “c<tipo>_” onde <tipo> deve ser utilizado como referência ao tipo da declaração conforme tabela abaixo:

Tipo <tipo>Date DTime HFloat FInteger ICharacter CNumeric N


5.1.2. Declaração de Tipos

Todas as constantes devem ser da forma “Y<tipo>_nome”. Observe que Y_ é fixo e <tipo> deve ser utilizado como referência ao tipo da declaração conforme tabela abaixo:

Tipo <tipo>Date DTime HFloat FInteger ICharacter CNumeric NEstrutura STabela T

5.1.3. Declaração de Parameters e Selection-options

Todos os parâmetros (parameters) devem começar por “p<tipo>_” e todas as opções de seleção (select-options) devem começar por “so_”. No caso dos parâmetros <tipo> deve ser utilizado como referência ao tipo da declaração conforme tabela abaixo:

Tipo <tipo>Date DTime HFloat FInteger ICharacter CNumeric N

5.1.4. Declaração de Variáveis

Todas as variáveis devem começar por “g<tipo>_” (variáveis globais) ou por “l<tipo>_” (variáveis locais). Esta regra não vale para campos de tabelas internas! O <tipo> deve ser utilizado como referência ao tipo da declaração conforme tabela abaixo:

Tipo <tipo>Date DTime HFloat FInteger ICharacter CNumeric NEstrutura STabela TObjeto OHandler H


5.1.5. Declaração de Ranges

Todos os ranges devem começar por “gr_” (ranges globais) ou por “lr_” (ranges locais) quando for definida a tabela do range. Para definição da linha utilizada em conjunto com o range, utilizar “gs_” (linha de ranges globais) ou por “ls_” (linha de ranges locais). Vide o exemplo abaixo para declaração de ranges:

DATA: gr_matnr type range of mara-matnr, “ Descrição do range gs_matnr like line of gr_matnr, “ Linha do range

5.1.6. Declaração de Tabelas Internas

Todas as tabelas internas devem começar por “gt_” (tabelas internas globais) ou por “lt_” (tabelas internas locais). Sempre procurar declarar um tipo (TYPES) com os campos da tabela interna e utilizar os complementos STANDARD TABLE. Vide o exemplo abaixo para declaração de tabela interna:

TYPES: begin of ys_kna1, ... end of ys_kna1, yt_kna1 TYPE STANDART TABLE OF ys_kna1.DATA: gt_kna1 TYPE yt_kna1, gt_mara TYPE STANDART TABLE OF mara.

Observações:Quando a criação da tabela interna for utilizar uma estrutura do dicionário de dados, a declaração pode ser feita diretamente na declaração DATA.Caso seja necessário criar uma estrutura com TYPES, declarar a tabela interna também como um tipo e utilizar este tipo tabela no momento da criação da variável.

5.1.7. Declaração de Estruturas

Todas as estruturas devem começar por “gs_” (estruturas globais) ou por “ls_” (estruturas locais). Vide o exemplo abaixo para declaração de estruturas:

DATA gs_kna1 TYPE ys_kna1.


5.1.8. Declaração de Field-Symbol

Todos os ponteiros (field-symbol) devem ser declarados por “<g<tipo>_nome>” para field-symbols globais ou “<l<tipo>_nome >” para field-symbols locais onde <tipo> deve ser utilizado como referência ao tipo da declaração conforme tabela abaixo:

Tipo <tipo>Date DTime HFloat FInteger ICharacter CNumeric NEstrutura STabela TAny A

FIELD-SYMBOLS <gs_kna1> TYPE ys_kna1.

5.1.9. Declaração de Telas de Module Pool

As telas deste tipo de programa devem possuir uma numeração coerente com a hierarquia das telas. Respeitando a limitação das telas standard, não utilizando a numeração de 1000 a 1100.

Exemplo:0100 – Tela Principal

0110 – Aba1 do tabstrip0120 – Aba2 do tabstrip0130 – Aba3 do tabstrip


5.2. IDENTIFICAÇÃO DA APLICAÇÃO

O sistema R/3 apresenta uma classificação para as suas aplicações conforme a tabela ilustrada abaixo, essa classificação corresponde a dois caracteres, o qual será usado na composição da nomenclatura dos objetos desenvolvidos pelos consultores.

Sigla Módulo Funcional ObservaçãoSD Sales & Distribution LogisticsMM Materials Management LogisticsPP Production Planning LogisticsTM Transportation Management LogisticsQM Quality Management Human ResourcesPM Plant Maintenance Human ResourcesHR Human Resources Human ResourcesFI Financial Accounting Accounting

CO Controlling AccountingTR Treasury AccountingPS Project System Cross-ApplicationWF Workflow Cross-ApplicationIS Industry Solutions Cross-ApplicationAB ABAP – Interfaces - Gerenciador Dif. De Módulos

5.3. OBJETOS DE PROGRAMA

Os objetos ABAP desse grupo estão relacionados, com as dimensões, conforme a tabela abaixo:

OBJETO RELEASE 4.XPrograma 30 caracteresModelo 20 caracteresClasse 30 caracteresVariante 14 caracteresCampo Global 30 caracteresEvento 30 caracteresSub-Programa 30 caracteresMacro 30 caracteresTela 04 caracteresStatus GUI 20 caracteresTítulo GUI 20 caracteresInclude 30 caracteresTransação 20 caracteresMódulo de Diálogo 30 caracteres


5.3.1. PROGRAMA / FORMULÁRIOS

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘PROGRAMA’ corresponde a forma ZPMMXID. Onde:

CARÁTER DESCRIÇÃO

ZConstante que identifica o objeto como não pertencente ao padrão “standard” do R/3.

P Constante que identifica o objeto como sendo um programa.MM Identificação do módulo funcional ao qual o programa se destina.

X

Identifica o tipo de programa conforme a seqüência abaixo: I – InterfacesC – Conversão (Cargas Iniciais)E – Enhancement (Aplicações do Cliente, exits)X – Cross-Aplication (IDOC, ALE, Etc...)R – Relatórios (report simples, ALV)F – Formulários (SapScripts, Smartforms)S – Estilo de Formulários (SapScripts, Smartforms)K – Copia de Standard

IDString que identifica o objetivo do programa. Poderá ser uma seqüência numérica para a identificação do objeto. Variando de 001 à 999.

OBSERVAÇÃO: Os programas de Module Pool não seguirão o padrão acima e sim o padrão standard da SAP no caso “SAPMZMMID”.o Onde: MM – Identificação do Módulo Funcional ao qual o programa se destina.o Onde: ID – String que identifica o objetivo do programa. Poderá ser uma

seqüência numérica para identificação do objeto. Variando de 001 a 999.

5.3.2. Modelo

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘MODELO’ corresponde a forma ZPT_ID. Onde:



PT Constante que identifica o objeto como sendo uma classe

ID

Reservado a ‘string’ que melhor identifique o objeto, a dimensão e o conteúdo são livres, desde que respeitem respectivamente o limite máximo e o bom senso. A ‘string’ poderá ser do tipo simples ou composta. No caso de ser composta, dois ou mais conjuntos de caracteres, a concatenação entre os conjuntos deverá ser feita através do sinal ‘underscore’ ( _ ).


5.3.3. CLASSE

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘CLASSE’ corresponde a forma ZCLMM_ID. Onde:



CL Constante que identifica o objeto como sendo uma classeMM Identificação do módulo funcional a qual o programa se destina.

ID


5.3.4. VARIANTE

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘VARIANTE’ corresponde a forma ZVMM_ID. Onde:



V Constante que identifica o objeto como sendo uma varianteMM Identificação do módulo funcional a qual o programa se destina.

ID


5.3.5. CAMPO GLOBAL

O consultor deve considerar as definições apresentadas no tópico 5.1., porém não deixando de respeitar as dimensões informadas na tabela comparativa apresentada no tópico 5.3.


5.3.6. EVENTO

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘EVENTO’ corresponde à forma ZEMM_ID. Onde:



E Constante que identifica o objeto como sendo um eventoMM Identificação do módulo funcional a qual o programa se destina.

ID


5.3.7. SUB-PROGRAMA (Forms)

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘SUB-PROGRAMA’ corresponde a forma ZF_ID. Onde:



F Constante que identifica o objeto como sendo sub-programa

ID

Reservado a ‘string’ que melhor identifique o objeto, a dimensão e o conteúdo são livres, desde que respeitem respectivamente o limite máximo e o bom senso. A ‘string’ poderá ser do tipo simples ou composta. No caso de ser composta, dois ou mais conjuntos de caracteres, a concatenação entre os conjuntos deverá ser feita através do sinal ‘underscore’ ( _ ). Exemplo: ZF_ACAO_OBJETO => ZF_MONTA_TABELA


5.3.8. MACRO

O objeto do tipo ‘MACRO’ definido pelo consultor deve apresentar a forma ZM_ID. Considere no ‘corpo’ do objeto que conterá as macros, uma seção de declaração devidamente comentada para as mesmas. Onde:



M Constante que identifica o objeto como sendo uma macro

ID


5.3.9. TELA

A identificação dos objetos do tipo ‘TELA’ deverá apresentar apenas caracteres numéricos. O consultor deve procurar usar uma ‘seqüência’ coerente para as telas dinâmicas a serem implementadas no projeto.

5.3.10. STATUS GUI

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘STATUS GUI’ corresponde a forma ZGID. Onde:



G Constante que identifica o objeto como sendo uma status GUI

ID

Deverá conter o número da tela onde ele será utilizado. No caso de mais de um Status GUI para a mesma tela, utilizar uma seqüência de caracter ao final do nome para identificar os diversos Status GUI.

5.3.11. TÍTULO GUI

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘TÍTULO GUI’’ corresponde a forma ZUID. Onde:



U Constante que identifica o objeto como sendo um título GUIID Deverá conter o número da tela onde ele será utilizado.


5.3.12. INCLUDE

Os objetos do tipo ‘INCLUDE’ apresentarão sua nomenclatura como os objetos do tipo ‘PROGRAMA’, a menos da constante de identificação, que nesse caso será ‘I’ ao invés de ‘P’.

No caso de module pool, utilizar a nomenclatura sugerida pelo sistema no momento da criação para os quatro includes principais:

variáveis (TOP) process before output (O) process after input (I) rotinas (F)

No caso da criação de outros includes para utilização no module pool, utilizar a nomenclatura normal de includes descrita a seguir.

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘PROGRAMA’ corresponde a forma ZIMMID. Onde:



I Constante que identifica o objeto como sendo um includeMM Identificação do módulo funcional a qual o programa se destina.

IDSeqüência numérica para a identificação do objeto. Variando de 001 à 999.

5.3.13. TRANSAÇÃO

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘TRANSAÇÃO’ corresponde à forma ZTMMID. Onde:



T Constante que identifica o objeto como sendo uma transaçãoMM Identificação do módulo funcional a qual o programa se destina.

IDSeqüência numérica para a identificação do objeto. Variando de 001 à 999. Essa seqüência deverá ser seguida baseada no módulo ao qual se destina o objeto.


5.3.14. MÓDULO DE DIÁLOGO

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘MÓDULO DE DIÁLOGO’ corresponde à forma ZD_ID. Onde:



DConstante que identifica o objeto como sendo um módulo de diálogo

ID

Reservado a ‘string’ que melhor identifique o objeto, a dimensão e o conteúdo são livres, desde que respeitem respectivamente o limite máximo e o bom senso. A ‘string’ poderá ser do tipo simples ou composta. No caso de ser composta, dois ou mais conjuntos de caracteres, a concatenação entre os conjuntos deverá ser feita através do sinal ‘underscore’ ( _ ).Ex: ZD_AÇÃO_OBJETO => ZD_INICIALIZA_TELA


5.4. OBJETOS DO DICIONÁRIO

Os objetos ABAP desse grupo estão relacionados, com as respectivas dimensões, conforme a tabela abaixo:

OBJETO RELEASE 4.XTabela 30 caracteresEstrutura 30 caracteresVisão 30 caracteresElemento de Dados 30 caracteresDomínio 30 caracteresObjeto de Bloqueio 30 caracteresAjuda para Pesquisa 30 caracteresGrupo de Tipos 05 caracteres

O padrão a ser utilizado na nomenclatura de objetos do ‘Dicionário’ corresponde à forma ZWWMMID. O fator que proverá a diferença entre os objetos será o valor da constante ‘WW’, que assumirá um dos seguintes valores possíveis, conforme a tabela abaixo:

OBJETO VALOR DA CONSTANTE ‘WW’Tabela TBEstrutura STCategoria de Tabela TCVisão VWElemento de Dados DEDomínio DOObjeto de Bloqueio BOAjuda para Pesquisa SHGrupo de Tipos TY

Onde:



WW Constante que identifica o objeto conforme a tabela anterior.MM Identificação do módulo funcional a qual o programa se destina.

IDSeqüência numérica para a identificação do objeto. Variando de 001 à 999. Essa seqüência deverá ser seguida baseada no módulo ao qual se destina o objeto.

Contudo o objeto ‘GRUPO DE TIPOS’ apresenta-se com dimensão 5 e a sua nomenclatura seguirá a forma ‘ZWWMM’ onde a variável ‘WW’ assumirá o valor ‘TY’. Sendo assim poderá ser criado um Grupo de Tipos para cada módulo.

Para o Objeto de Bloqueio, a nomenclatura será a mesma descrita, exceto pela letra E no inicio do objeto, assumindo a forma EZWWMMID, onde a variável ‘WW’ assumirá o valor ‘BO’.


5.5. OBJETOS DE GRUPO DE FUNÇÃO


OBJETO RELEASE 4.XGrupo 26 caracteresMódulo de Função 30 caracteresCampo Global 30 caracteresEvento 30 caracteresMódulo PBO 30 caracteresMódulo PAI 30 caracteresSub-Programa 30 caracteresMacro 30 caracteresTela 04 caracteresStatus GUI 20 caracteresTítulo GUI 20 caracteresInclude 30 caracteresTransação 20 caracteresMódulo de Diálogo 30 caracteres

Comparando-se com os ‘Objetos de Programa’, nota-se que apenas os objetos ‘GRUPO’ e ‘MÓDULO DE FUNÇÃO’ não estão caracterizados até o presente momento. A forma a ser adotada é ZGMM_ID para objetos do tipo ‘GRUPO’ e ‘ZFMM_ID’ para objetos do tipo ‘MÓDULO DE FUNÇÃO’. Onde:



F Constante que identifica o objeto como módulo de função.G Constante que identifica o objeto como grupo.

MM Identificação do módulo funcional a qual o programa se destina.

ID



5.6. OUTROS OBJETOS


OBJETO RELEASE 4.XClasse de Desenvolvimento ou Pacote 30 caracteresInclude 30 caracteresMódulo de Função 30 caracteresMódulo de Diálogo 30 caracteresTransação 20 caracteresBanco de Dados Lógico 20 caracteresID Parâmetro SET/GET 20 caracteresMenu de Área 20 caracteresClasse de Mensagem 20 caracteresNúmero da Mensagem 20 caracteresPF-STATUSAUTHORITY-CHECKSessão BATCH INPUTMEMORY-ID

Nesse grupo, os objetos ‘INCLUDE’, ‘MÓDULO DE FUNÇÃO’, ‘MÓDULO DE DIÁLOGO’ e ‘TRANSAÇÃO’ já se encontram caracterizados em tópicos anteriores. Os demais objetos desse grupo estão caracterizados a seguir.

5.6.1. CLASSE DE DESENVOLVIMENTO OU PACOTE

O padrão a ser utilizado na nomenclatura do objeto ‘CLASSE DE DESENVOLVIMENTO’ (também conhecido como pacote nas versões mais novas do SAP) corresponde à forma ZMM_ID. Onde:




ID


Observação: Poderá ser adotado o padrão já estabelecido pela equipe de Basis.


5.6.2. REQUEST

O padrão a ser utilizado na nomenclatura da descrição das Requests corresponde à forma MM - YY - ID. Onde:

CARÁTER DESCRIÇÃOMM Identificação do módulo funcional a qual o programa se destina. YY Constante que identifica as iniciais do nome do desenvolvedor.

ID

Reservado a ‘string’ que melhor identifique o objeto, a dimensão e o conteúdo são livres, desde que respeitem respectivamente o limite máximo e o bom senso. A ‘string’ poderá ser do tipo simples ou composta.

Observação: Poderá ser adotado o padrão já estabelecido pela equipe de Basis ou pelo Cliente.

5.6.3. BANCO DE DADOS LÓGICO

O padrão a ser utilizado na nomenclatura do objeto ‘BANCO DE DADOS LÓGICO’ corresponde à forma ‘ZYMM_ID’. Onde:



Y Constante que identifica o objeto como banco de dados lógico.MM Identificação do módulo funcional a qual o programa se destina.

ID


5.6.4. ID PARÂMETRO SET/GET

O objeto ‘ID’ usado como parâmetro junto aos comandos ‘SET’ e ‘GET’ devera ser identificados pelo consultor através do formato ‘ID_SS’. Onde:

CARÁTER DESCRIÇÃOID Constante que identifica o objeto como um parâmetro ID.

SS



5.6.5. MENU DE ÁREA

O padrão a ser utilizado na nomenclatura do objeto do tipo ‘MENU DE ÁREA’ corresponde à forma ZHMM_ID. Onde:



H Constante que identifica o objeto como menu de área.MM Identificação do módulo funcional a qual o programa se destina.

ID

Reservado corresponde a forma a ‘string’ que melhor identifique o objeto, a dimensão e o conteúdo são livres, desde que respeitem respectivamente o limite máximo e o bom senso. A ‘string’ poderá ser do tipo simples ou composta. No caso de ser composta, dois ou mais conjuntos de caracteres, a concatenação entre os conjuntos deverá ser feita através do sinal ‘underscore’ ( _ ).

5.6.6. CLASSE DE MENSAGEM

O padrão a ser utilizado na nomenclatura do objeto do tipo ‘CLASSE DE MENSAGEM’ corresponde à forma ZLMM. Onde:



L Constante que identifica o objeto como classe de mensagemMM Identificação do módulo funcional a qual o programa se destina.

5.6.7. NÚMERO DE MENSAGEM

O padrão a ser utilizado na nomenclatura do objeto do tipo ‘NUMERO DE MENSAGEM’ corresponde à forma NNN. Onde:


NNNSeqüência numérica para a identificação do objeto. Variando de 001 à 999.

5.6.8. AUTHORITY-CHECK

O padrão a ser utilizado na nomenclatura do objeto do tipo ‘AUTHORITY-CHECK’ corresponde à forma ZXXXXXXX. Onde:



XXX Nome do programa que utiliza o objeto.

O objeto deve sempre conter o campo ACTVT e demais campos necessários e constar dentro do grupo de acordo com o módulo.


5.6.9. MEMORY-ID

O padrão a ser utilizado na nomenclatura do objeto do tipo ‘MEMORY-ID’ corresponde à forma ZNNN. Onde:



NNNSeqüência numérica para a identificação do objeto. Variando de 001 à 999.

5.6.10. BATCH INPUT (Pastas)

O padrão a ser utilizado na nomenclatura do objeto do tipo ‘BATCH INPUT’ corresponde à forma ZBMM_ID. Onde:



B Constante que identifica o objeto como pasta de Batch Input.MM Identificação do módulo funcional a qual o programa se destina.

ID

Reservado corresponde a forma a ‘string’ que melhor identifique o objeto, a dimensão e o conteúdo são livres, desde que respeitem respectivamente o limite máximo e o bom senso. A ‘string’ poderá ser do tipo simples ou composta. No caso de ser composta, dois ou mais conjuntos de caracteres, a concatenação entre os conjuntos deverá ser feita através do sinal ‘underscore’ ( _ ).

o Padrão para criação de pastas via programa, o gerenciador gera pastas automáticas utilizando variáveis da execução para efetuar a nomenclatura das mesmas.


5.7. BUSINESS ENGINEERING


OBJETO RELEASE 4.XModelo de Dados 26 caracteresTipo de Entidade 26 caracteresCtg. Obj. Business 10 caracteres

5.7.1. MODELO DE DADOS

O padrão a ser utilizado na nomenclatura do objeto do tipo ‘MODELO DE DADOS’ corresponde à forma ZJMM_ID. Onde:



J Constante que identifica o objeto como modelo de dados.MM Identificação do módulo funcional a qual o programa se destina.

ID


5.7.2. TIPO DE ENTIDADE

O padrão a ser utilizado na nomenclatura do objeto ‘TIPO DE ENTIDADE’ corresponde a forma ZQMM_ID. Onde:



Q Constante que identifica o objeto como modelo de dados.MM Identificação do módulo funcional a qual o programa se destina.

ID



5.7.3. CATEGORIA DE OBJETO BUSINESS

O padrão a ser utilizado na nomenclatura do objeto do tipo ‘CATEGORIA DE OBJETOS BUSINESS’ corresponde à forma ZWMM_ID. Onde:



WConstante que identifica o objeto como categoria de objeto business.


ID


6. LAY-OUT

6.1. LAY-OUT DE TELA

Devem seguir as definições da Especificação Funcional. Na sua ausência, devem ser seguidos os mesmos critérios utilizados no standard do R/3.

6.2. LAY-OUT DE SAIDA (Relatório)

Devem seguir as definições da Especificação Funcional, na sua ausência, deve ser sugerido pelo consultor abap um layout limpo e claro no tocante as cores.


7. Normas de Programação

Nesse ponto existem algumas dicas de programação para melhorar a performance e a manutenção dos programas escritos em ABAP.

7.1. TABELAS INTERNAS

Nas versões mais recentes do SAP (ECC 5.0 ou superior) não é recomenda criar tabelas internas com header line. Por está razão nenhuma tabela interna declarada em um desenvolvimento deve conter header line. Abaixo exemplo de declaração de uma tabela interna sem header line: (Seguir as normas de criação de comentários já definidas).

DATA: gt_mara type standard table of mara.

Dentro de um programa, a maior parte do tempo computacional é despendido no acesso ao banco de dados. O acesso a tabelas muito grandes pode se transformar num fator de risco ao bom desempenho de um programa, principalmente em se tratando de programas que devam ser executados periodicamente, tais como interfaces. A fim de minimizar o tempo gasto no acesso ao banco de dados, vale lembrar que em ABAP, os métodos de extração de dados (do mais eficiente para o menos) são:

Executar uma cláusula “select” numa view ao invés de utilizarmos várias tabelas. Executar uma cláusula “select” em várias tabelas utilizando joins. Executar uma cláusula “select” numa tabela. Realizar um loop numa internal table. Utilizar uma tabela lógica usando o comando “get”.


7.2. PARÂMETROS DE SELEÇÃO

Em telas de seleção, os campos devem ser sempre referenciados a um campo existente no dicionário de dados do R/3. Desta forma, o usuário poderá acessar a tela de help do campo através das teclas de função F1 e F4 quando o mouse estiver posicionado no campo.

Levar em consideração durante um desenvolvimento:

Evite a utilização de valores explícitos no programa. Para obter os dados necessários à lógica do programa, cláusulas de seleção (select statement), arquivos de entrada ou saída, utilize parâmetros ou telas de seleção para garantir flexibilidade de manutenção. Portanto evite comandos do tipo:

Forma incorreta: SELECT matnr werks FROM marc WHERE werks = '5000' … IF gh_vbfa-vbtyp_n = 'J' … gf_custo = mbew-strps * '1.2' ...

Forma Correta: SELECT matnr werks FROM marc WHERE werks = pc_werks. IF gh_vbfa-vbtyp_n = pc_vbtyp gf_custo = mbew-strps * pf_valor.

Evite também o uso do “default” para atribuir valores iniciais aos parâmetros ou em telas de seleções. Esses valores podem mudar no futuro. Dê preferência à criação de variantes para setar esses valores.

Os parâmetros de seleção devem ser validados no evento “at-selection-screen” para limitar os dados fornecidos àqueles configurados pela equipe funcional. Por exemplo: Não permitir que a data informada tenha um ano anterior ao início do ano corrente.

7.3. DECLARAÇÃO DE VARIÁVEIS

Sempre que possível utilizar o complemento TYPE para declarar variáveis, constantes, estruturas, tabelas internas, etc.

7.4. DECLARAÇÃO DE EVENTOS

O evento “START-OF-SELECTION” não deve possuir mais de 20 linhas (excluindo os comentários) para que se reflita de forma lógica e concisa o processamento global do programa. O uso de sub-rotinas (perform xxxxxxx using yyyyyyy) deve ser extensamente utilizado para que este limite de 20 linhas seja mantido.


7.5. DECLARAÇÃO DE SUBROTINAS (FORMS)

Blocos de código que são executados mais de uma vez devem ser colocados numa sub-rotina (“form”). Tal procedimento deve ser adotado para eliminar trechos de código redundante e para facilitar a depuração do programa. Uma sub-rotina deve realizar apenas um processo. Se existir alguma sub-rotina que realize mais de um processo, então deve-se dividi-la em múltiplas sub-rotinas. O nome de uma sub-rotina deve ser mnemônico. A sub-rotina que poderá ser usada em outros programas deverá ser colocada em um módulo de função.

7.6. CÁLCULOS

Evite o uso de comandos para cálculo de expressões aritméticas. Por exemplo:

gn_data1 = gn_data1 + 1 É melhor quecompute gn_data1 = gn_data1 + 1.

7.7. COMANDO MOVE-CORRESPONDING

Não é indicado utilizar este comando dentro de loops ou em seleções de dados. Mover campo a campo é sempre mais indicado (leia-se performático), para isto declarar uma estrutura ou tabela interna na mesma seqüência dos campos que devem ser movidos.

7.8. COMANDO DESCRIBE

O comando DESCRIBE é a maneira mais eficiente de determinar o número de registros de uma tabela interna. Exemplo de utilização:

*** Encontrar a quantidade de registrosDESCRIBE TABLE gh_tabela LINES gn_linhas.

7.9. COMANDO CASE

O comando CASE geralmente é mais claro, legível e um pouco mais rápido do que o comando IF. Quando testamos se um campo é igual a um outro campo, tanto faz usarmos CASE ou IF. Porém, o comando CASE é o melhor, pois além de facilitar a leitura do código, é mais eficiente depois de 2 “if’s”.


7.10. COMANDO LOOP

Por questões de performance não é recomendo utilizar o comando LOOP com o complemento WHERE. Caso seja necessário encontrar um grupo de registros em vez de utilizar o complemento WHERE utilizar o complemento FROM conforme o exemplo abaixo:

*** Ordenar os registrosSORT: gt_vbak BY vbeln ASCENDING gt_vbap BY vbeln ASCENDING.

*** Ler todos os cabeçalhos das cotaçõesLOOP AT gt_vbak ASSIGNING <gs_vbak>.

*** Localizar os itens da cotação READ TABLE gt_vbap ASSIGNING <gs_vbap> WITH KEY vbeln = <gs_vbak>-vbeln BINARY SEARCH.

*** Ler todos os itens da cotação LOOP AT gt_vbap ASSIGNING <gs_vbap> FROM sy-tabix.

*** Verifica se modificou o número da cotação IF <gs_vbap>-vbeln <> <gs_vbak>-vbeln. EXIT. ENDIF.

*** Escrever mensagem WRITE: <gs_vbap>-vbeln, <gs_vbap>-posnr.

ENDLOOP.

ENDLOOP.

Observação: para o código acima funcionar é necessário que a tabela interna esteja ordenada pelos campos de procura do comando READ TABLE. Levar em consideração caso seja necessário verificar mais de um campo no IF do segundo LOOP utilizar o complemento OR. Outro ponto de atenção é a utilização do complemento ASSIGNING que torna a execução do comando LOOP mais rápida, já que o conteúdo da tabela interna não será copiado para uma nova área de memória (isto aconteceria se tivesse movido o conteúdo da tabela interna para uma estrutura).


7.11. COMANDO WHILE

O comando WHILE é mais eficiente do que DO + EXIT. WHILE é mais fácil de entender e mais rápido durante a execução.

7.12. COMANDO SORT

Quando utilizar o comando SORT para ordenar tabelas internas, especifique quais os campos utilizados como referência. Ou seja, é mais eficiente SORT GT_ITAB BY FIELD_1 ASCENDING FIELD_2 DESCENDING que apenas SORT GT_ITAB.

7.13. COMANDO SELECT

Evite a utilização do comando SELECT sob a forma “SELECT * FROM <TABLE> WHERE ...”. Ao utilizarmos “ * ” para busca de campos estaremos trazendo do servidor de banco de dados todas as colunas da tabela TABLE. Ao invés disto, utilize a forma “SELECT FLD1 FLD2 FLD3 INTO (GC_FLD1, GC_FLD2, GC_FLD3) FROM <TABLE> WHERE ....”.

Quando o consultor for utilizar o complete FOR ALL ENTRIES em uma seleção de dados atentar para os fatos:

Sempre verificar se a tabela do FOR ALL ENTRIES não está vazia, pois se for utilizado uma tabela interna vazia para realizar uma seleção de dados será selecionado todos os registros da tabela informada no FROM.

Sempre ordenar e excluir os registros duplicados da tabela interna do FOR ALL ENTRIES. Caso a tabela interna não possa ter os registros duplicados excluídos, criar uma tabela interna temporária mover os dados e realizar as operações.

Sempre selecionar os campos conforme a ordem das tabelas transparentes.

Sempre procurar utilizar índices primários ou secundários nas seleções de dados (e sempre na mesma ordem da tabela transparente ou da criação do índice secundário). Caso algum campo não chave tenha que ser filtrado é preferível selecionar tal campo e após a seleção excluir o mesmo da tabela interna. Imagine o cenário: selecionar todas as cotações informadas no parâmetro de tela de Nº Cotações onde a data de criação seja igual ao dia de hoje. A tabela de cotações é a VBAK e seu campo chave é o VBELN. O campo ERDAT (data de criação) não é chave.

*** Seleção das cotações SELECT vbeln “ Nº Cotação erdat “ Data de Criação INTO TABLE gt_vbak FROM vbak WHERE vbeln in so_vbeln.

*** Excluir os registros que não estejam no parâmetro data


DELETE gt_vbak WHERE NOT erdat IN so_erdat.

Evitar na clausula WHERE comparações do tipo diferente (<>).

7.14. COMANDO INTO TABLE

O comando INTO TABLE é sempre mais rápido que os comandos INTO e APPEND para inserção de dados numa tabela interna. Desta forma prefira sempre a forma “SELECT * FROM <TABELA> INTO TABLE GT_ITAB” à forma “SELECT * FROM <TABELA> INTO GT_ITAB. APPEND GT_ITAB. ENDSELECT”.

7.15. COMANDO FREE

Quando os registros de uma tabela interna não forem mais utilizados no decorrer do programa utilizar o comando FREE para liberar espaço em memória.

7.16. ÍNDICE

Cada índice criado diminui a performance dos “inserts” e dos “updates” nas tabelas. No geral, tabelas onde são feitos muitos “inserts” e “updates”, deverão ter poucos índices. Da mesma forma, tabelas onde há muitos “selects”, poderão ter mais índices. Uma média de 3-4 índices por tabela é aceitável.

7.17. CÓDIGO MORTO

Evite a existência de código morto ao longo dos programas. Remova definições de campos que nunca serão usados e códigos que nunca serão executados.


7.18. COMANDO READ TABLE

Sempre que possível ordenar a tabela interna pelos campos que serão utilizados no complemento WITH KEY, nestes casos será possível utilizar o complemento BINARY SEARCH tornando a busca de registros mais performática. Outro ponto importante é utilizar o complemento ASSIGNING também por questões de performance. Vide um exemplo de utilização do comando:

*** Selecionar uma cotaçãounassign <gs_vbak>.READ TABLE gt_vbak ASSIGNING <gs_vbak> WITH KEY

vbeln = ln_vbeln BINARY SEARCH.

check <gs_vbak> is assigned.

7.19.VERIFICAÇÃO EXTENDIDA DE SINTAXE

Todos os desenvolvedores deverão utilizar a funcionalidade de Verificação Estendida de Sintaxe dos programas criados. Esta funcionalidade executa uma série de verificações no código fonte, normalmente não verificadas na checagem simplificada de sintaxe. Entre os erros detectados com esta funcionalidade encontraremos: definição de variáveis não utilizadas pelo programa, declaração desnecessária de parâmetros, forms não chamados, etc.

Para executar a Verificação Estendida, a partir do Edit ABAP, selecione Programa -> Verificar -> Verificação de Programa Ampliada | Executar Verificação Ou utilize a transação SLIN.

7.20. ANÁLISE DO TEMPO DE EXECUÇÃO

Cada desenvolvedor deverá utilizar a funcionalidade SAP de Análise do Tempo de Execução dos programas criados. Tal ferramenta nos ajuda a descobrir trechos do código fonte que apresentam baixa performance. A transação utilizada para esta análise é SE30.

7.21. CRIAÇÃO DE LITERAIS

Caso seja necessário utilizar algum hard code no programa, sempre criar constantes, por exemplo, em vez de realizar uma comparação var = ‘X’ o correto deve ser var = cc_x (onde cc_x possui o valor ‘X’). Em ocasiões que existe a necessidade de imprimir um texto fixo na tela, por exemplo, “Problemas com o cliente”, em vez de executar WRITE “Problemas com o cliente” criar um elemento de texto contendo esta mensagem (text-001). Criando elementos de texto é possível traduzir as mensagens do programa para outras línguas.


7.22. PROGRAMAÇÃO PARA O MODULO DE HR (HUMAN RESOURCES)

O modulo de HR possui algumas particularidades em termo de programação e performance que serão demonstradas abaixo:

Por questões de performance evite o uso de instruções SQL dentro do evento GET. É preferível realizar as seleções de dados fora deste evento e utilizar o comando READ TABLE para encontrar os valores desejados.

Durante a utilização de um infotipo para edição ou criação de um registro bloqueá-lo para que não haja possibilidade de perda da informação devido ao uso simultâneo de outro usuário no mesmo. Para realizar tal bloqueio/desbloqueio utilizar as funções “BAPI_EMPLOYEET_ENQUEUE” e “BAPI_EMPLOYEET_DEQUEUE” garantindo o uso exclusivo do registro.

Para acessar os dados dos infotipos sempre procure utilizar as funções como, por exemplo, “HR_READ_INFOTYPE” do que acessar as tabelas diretamente através de instruções SQL. As funções de leituras já realizam toda a verificação de permissão dos usuários para acesso de dados tornando o programa mais seguro.

Por questões de performance sempre utilizar a função “HR_PSBUFFER_INITIALIZE” antes da função de atualização de infotipos “HR_INFOTYPE_OPERATION”.


7.23. NOTAS OSS

Caso ao aplicar uma determinada Nota OSS seja necessário alterar/apagar o código padrão do SAP, teremos que seguir os passos descritos neste item.

No início do programa (caso exista um cabeçalho, imediatamente abaixo deste), colocar a seguinte referência:

Exemplo:*-----------------------------------------------------------------------* Histórico das modificações referentes a notas OSS*-----------------------------------------------------------------------* Data |Autor |Nota |Descrição *-----------------------------------------------------------------------* 10/11/2007 |Fulano |008412 |Number of range:multiple copies*-----------------------------------------------------------------------

No local da modificação sugerida pela nota OSS: quando temos que modificar/apagar/inserir uma linha, a mesma deverá ser colocada em comentário.

Exemplo:*-----------------------------------------------------------------------* Início da Nota OSS: 008412... “ <-- Alterado...... “ <-- Apagado...... “ <-- Inserido* Fim da Nota OSS: 008412*-----------------------------------------------------------------------


Documents

Manual de Padronização Desenvolvimento Abap_v1.1