Guia para otimizar o tempo de execução de relatórios e gerenciar especificações funcionais

Olá,

1. O que são melhorias?

2. O que são as saídas do usuário?

Siga o link para obter detalhes completos.

https://www.sdn.sap.com/irj/sdn/nw-development?rid=/webcontent/uuid/2342e1f3-0b01-0010-a186-fdd40488... [o link original está quebrado]

3. Você está executando um relatório. Está demorando muito tempo para

executar. Quais passos você seguiria para reduzir o

tempo de execução?

Passos para otimizar o código ABAP:

Evite usar a construção SELECT...ENDSELECT... e use SELECT ... INTO TABLE.

Utilize a cláusula WHERE em sua declaração SELECT para restringir o volume de dados recuperados.

Projete sua consulta para usar o máximo de campos de índice possível da esquerda para a direita em sua declaração WHERE.

Use FOR ALL ENTRIES em sua declaração SELECT para recuperar os registros correspondentes de uma só vez.

Evite usar uma declaração SELECT aninhada, SELECT dentro de loops.

Evite usar INTO CORRESPONDING FIELDS OF TABLE. Em vez disso, use INTO TABLE.

Evite usar SELECT * e selecione apenas os campos necessários da tabela.

Evite loops aninhados ao trabalhar com grandes tabelas internas.

Use assign em vez de into nos loops para tipos de tabela com áreas de trabalho grandes. Em caso de dúvida, chame a transação SE30 e use os exemplos e verifique seu código.

Sempre que usar READ TABLE, adicione a opção BINARY SEARCH para acelerar a busca. Certifique-se de classificar a tabela interna antes da busca binária. Esta é uma regra geral, mas tipicamente se você tem certeza de que os dados na tabela interna são menos de 200 entradas, não é necessário classificar e usar BINARY SEARCH, pois isso é um custo adicional de desempenho.

Use "CHECK" em vez de IF/ENDIF sempre que possível.

Use "CASE" em vez de IF/ENDIF sempre que possível.

Use "MOVE" com movimentos de variáveis/campos individuais em vez de "MOVE-CORRESPONDING", cria mais código, mas é mais eficiente.

BUFFER DE TABELA: Isso pode ajudar a melhorar o desempenho, mas deve ser usado com cuidado. O armazenamento em buffer de tabelas faz com que os dados sejam lidos do buffer em vez da tabela. A sincronização do buffer com a tabela ocorre periodicamente. Se esta tabela é uma tabela de transações, é provável que os dados mudem para um critério de seleção específico. Não é recomendado usar o armazenamento em buffer de tabelas nesses casos. Use o armazenamento em buffer de tabelas para dados mestres ou dados com poucas transações. Além disso, ao usar uma tabela com armazenamento em buffer, certifique-se de que o critério geral usado para o armazenamento em buffer também esteja sendo usado. Se o critério de armazenamento em buffer não for o mesmo usado em seu código, não terá efeito e o armazenamento em buffer não será útil, em vez disso, causará um custo adicional de desempenho, pois a cada vez preencherá o buffer. Nesses casos, use 'BYPASSING BUFFER' para acelerar as SQL.

ÍNDICE: A criação de índices para melhorar o desempenho não deve ser feita sem pensar. O índice acelera o desempenho, mas ao mesmo tempo adiciona dois custos adicionais, ou seja, memória e desempenho de inserção/apêndice. Ao criar um índice, a memória é usada para armazenar o índice e os tamanhos dos índices podem ser bastante grandes em tabelas de transações grandes. Ao inserir uma nova entrada na tabela, todos os índices são atualizados. Mais índices, mais tempo. Quanto mais dados, maiores forem os índices, mais tempo levará para atualizar todos os índices.

PERFORM: Ao escrever uma sub-rotina, sempre forneça um tipo para todos os parâmetros. Isso reduz o custo adicional presente quando o sistema determina por si só cada tipo a partir dos parâmetros formais que são passados.

Atualização/Modificação de tabelas internas: Se o número de entradas for superior a 200 em uma tabela interna e alguns campos estiverem sendo manipulados ou alguma coluna da tabela interna estiver sendo preenchida com base em alguma lógica, é recomendado usar FIELD-SYMBOLS. Isso elimina o custo de mover a operação por meio de uma área de memória separada (área de trabalho).

°BEM-VINDO AO SDN!

1. Melhorias

As aplicações padrão não oferecem algumas funcionalidades que você precisa. O conceito de melhoria R/3 permite adicionar sua própria funcionalidade às aplicações comerciais padrão da SAP.

Diferentes tipos de melhorias

Melhorias usando saídas de cliente

Os requisitos potenciais dos clientes que não estão incluídos no software padrão são incorporados no padrão como 'casulos' de modificação vazios. Os clientes podem então completá-los com seu próprio código. As melhorias podem estar relacionadas com programas, menus e telas. A compatibilidade ascendente é garantida. Em outras palavras, a SAP garante que a transição do software padrão para a saída e a interface que chama a saída permanecerá válida em futuras versões.

Melhorias nos elementos do Dicionário ABAP/4

Estas são melhorias do Dicionário ABAP/4 (criação de extensões de tabelas), melhorias de texto (palavras-chave específicas do cliente e documentação para elementos de dados) e saídas de campo (criação de código adicional para elementos de dados).

Vantagens das melhorias

Não afetam o código-fonte padrão da SAP

Não afetam as atualizações de software

2. Userexits são locais predefinidos no código padrão da SAP onde os clientes podem inserir sua própria lógica para ajustar processos padrão aos requisitos do cliente. Esses locais são predefinidos pela SAP.

Transação SMOD mostra quais melhorias a SAP forneceu e de quais componentes consistem.

Se deseja implementar um userexit, então deve definir um projeto de melhoria (transação CMOD), atribuir todas as melhorias (por exemplo, CATS0001, CATS0002, etc.) que precisa e então implementá-las.

Por fim, deve ativar seu projeto para ativar os userexits.

Tipos de Saídas

Existem vários tipos diferentes de user exits. Cada uma dessas saídas atua como ganchos onde pode anexar ou "pendurar" suas próprias extensões.

Saídas de Menu

As saídas de menu adicionam elementos aos menus suspensos nas aplicações padrão da SAP. Pode usar esses elementos de menu para chamar suas próprias telas ou para ativar aplicativos adicionais completos.

A SAP cria saídas de menu definindo elementos de menu especiais no Menu Painter. Essas entradas especiais têm códigos de função que começam com "+" (um sinal de mais). Especifica o texto do elemento de menu ao ativar o elemento em um projeto de complemento.

Saídas de Tela

As saídas de tela adicionam campos às telas nas aplicações R/3. A SAP cria saídas de tela colocando áreas de subtela especiais em uma tela padrão do R/3 e chamando uma subtela do cliente a partir da lógica de fluxo da tela padrão.

Saídas de Módulo de Função

As saídas de módulo de função adicionam funções às aplicações R/3. As saídas de módulo de função desempenham um papel tanto nas saídas de menu quanto de tela.

Ao adicionar um novo elemento de menu a um menu suspenso padrão, usa uma saída de módulo de função para definir as ações que devem ocorrer quando seu menu é ativado.

As saídas de módulo de função também controlam o fluxo de dados entre os programas padrão e os campos de saída de tela. Os desenvolvedores de aplicativos SAP criam saídas de módulo de função escrevendo chamadas a funções de cliente no código-fonte dos programas padrão do R/3.

Saídas de Campo

As saídas de campo permitem criar sua própria lógica de programação para qualquer elemento de dados no Dicionário. Pode usar essa lógica para realizar verificações, conversões ou processamento relacionado ao negócio para qualquer campo de tela. Exemplo: O elemento de dados BBBNR identifica o número de localização internacional de uma empresa. Pode desejar configurar seu sistema R/3 para que todos os números de localização internacionais sejam maiores que 100.

O conceito de saída de campo permite criar um módulo de função especial que contenha essa lógica.

Atribui o módulo de função especial ao elemento de dados BBBNR. Em seguida, atribui o módulo a qualquer programa e tela onde os usuários possam adicionar novos números de localização internacionais. Quando