1.

Arquitetura Client-Server

O R/3 trabalha com uma filosofia de cliente/servidor de 3 níveis:

Database server : responsável pelo acesso e pela atualização dos dados

Application server : responsável pelo processamento da aplicação (tempo
despendido com a interpretação de comandos ABAP)
Frontend : responsável pelo processamento dos gráficos (tempo
despendido pelo sistema R/3, ou seja, o middleware e
Kernel). Kernel = conjunto de programas utilitários que
existe dentro do R/3, servindo ao cumprimento de
inúmeras tarefas

A alocação dos servidores de aplicação é definida automaticamente no momento de logon (é

checado qual servidor está menos sobrecarregado).

Dica: Para se obter uma otimização da performance em programas ABAP, deve-se

minimizar o tempo de acesso ao database.

2. Grandes vilões no que se refere à performance

 Ninhos de select
 Select …. Endselect ao invés de comandos que recuperem do banco de dados todos os
registros de uma única vez
 Select * ao invés de select com as colunas necessárias ao processamento
 Select single sem chave completa especificada ao invés de Select up to 1 row
 Selects genéricos, ou seja, onde a cláusula where não foi fortemente especificada, com
várias condições, visando restringir
 Índices não utilizados
 Falta de índices
 Select em tabelas com alto número de registros utilizando cláusula where baseada em tela
de seleção onde o preenchimento não é obrigatório
 Definição funcional falha
 Grandes tabelas do sistema: BKPF, BSEG, EKKO, EKPO, VBAK, VBAB, MKPF, MSEG,
J_1BNFDOC, J_1BNFLIN, EKET, EKBZ.
 Funções genéricas, como por exemplo CLAF_CLASSIFICATION_OF_OBJECTS

2.1. Comunicação entre o Application Server e Database Server - Transmissão de pacotes

Premissa:
VBAK contém 1000 registros, sendo que cada registro contém 575 bytes.
Fato:
A comunicação entre o DB server e o Application server acontece em pacotes de 32.000 bytes,
dependendo da rede e equipamentos de comunicação utilizados.

 Select * from VBAK.

Portanto:
1000 registros x 575 bytes = 575.000 bytes
575.000 bytes / 32.000 = 20 pacotes
20 pacotes: na verdade este número é um pouco mais alto (mais ou menos 24), uma vez que
informações administrativas são transferidas em cada transmissão, juntamente com os dados.
O exemplo acima tenta ilustrar que, se forem selecionadas apenas as colunas neces-
sárias, a transferência de dados será menor e, consequentemente, haverá uma redução
significativa no tempo de resposta.

2.2. Select e Logical Database

 Get VBAK
 Get VBAK fields vbeln auart bname kunnr

O segundo comando é muito melhor que o primeiro. Porém, nem todos os logical database
suportam select em colunas. Para verificar se isso é possível, acesse a transação SE36,
coloque o nome do database no qual se deseja efetuar uma pesquisa e escolha a
opção: extras -> field selection.

2.3. Cursor Caching

Os seguintes comandos SQL produzem o mesmo resultado, mas cada um deles requer seu
próprio cursor uma vez que os comandos não são idênticos (verifique a ordem das colunas
após a palavra Select e na cláusula WHERE):

Select vbeln auart into (vbak-vbeln, vbak-auart) from vbak

where vbeln = nnn and auart = yyyy

Select vbeln auart into (vbak-vbeln, vbak-auart) from vbak

where auart = yyyy and vbeln = nnn

Select auart vbeln into (vbak-auart, vbak- vbeln) from vbak

where vbeln = nnn and auart = yyyy

Select auart vbeln into (vbak-auart, vbak- vbeln) from vbak

where auart = yyyy and vbeln = nnn
Desnecessários comandos Declare e Prepare podem ser evitados se os comandos SQL são
mantidos consistentes nos programas que estão sendo desenvolvidos (quando se usar select
com colunas ou declarando condições WHERE sempre use a sequência de campos
conforme definido no Data Dictionary)

2.4. Logical database e Tables statements

Report ZEmpresaXXX.
Tables: vbak, vbkd, vbpa.

Get vbak fields vbeln auart bname kunnr.

Write: vbak-vbeln, vbak-auart, …. .

Get vbpa fields parvw kunnr.

Write: vbpa-parvw, vbpa-kunnr, vbkd-zterm.

Ao invés use:

Get vbak fields vbeln auart bname kunnr.

Write: vbak-vbeln, vbak-auart, …. .

Get vbkd field zterm.

Get vbpa fields parvw kunnr.

Write: vbpa-parvw, vbpa-kunnr, vbkd-zterm.

OBS.: A estrutura do logical database VAV (utilizado anteriormente) é VBAK – VBUK – VBKD –
VBPA.

Se uma tabela não é especificada via um cartão TABLES então o sistema automaticamente
recupera somente os campos chave para aquela tabela (aqui VBUK não está presente no
cartão tables, assim somente os campos chaves são recuperados pelo sistema).

Se uma tabela é especificada via TABLES, todas as colunas são recuperadas, mesmo se
nenhum campo daquela tabela é usado no programa (veja a tabela VBKD – somente o campo
ZTERM deveria ser impresso).

Para evitar ter todas as colunas selecionadas da tabela, insira um comando GET para aquela
tabela, especificando os campos que serão utilizados pelo programa posteriormente.

2.5. Select … exit versus Select …. Up to 1 rows.

Vantagem em performance:
Select … exit. Endselect. = 150.000 ms
Select … up to 1 rows = 1.500 ms
 2.6. Check inside Select …endselect.

Comparação de Runtime é baseada numa varredura de 57.000 registros na VBAK

Select & Check = 27.958.000 ms

Select com cláusula WHERE = 3.065.000 ms

Em caso de condições de checagens muito complexas poderia ser mais rápido obter dados do
banco de dados primeiramente. SQL Trace precisa ser usado para verificar qual método é o
mais rápido.

Isso também é válido para select single.

2.7. Selects em campos sem índices

Select-options: bname_so for vbak-bname.

Select vbeln bname …. Into (vbak-vbeln …) from vbak

Where bname in bname_so order by <field> descending.

Endselect.

O sistema standard é distribuído sem um índice para o campo bname. A seleção acima irá
resultar numa varredura sequencial da tabela vbak. Isto não é aceitável num sistema em
produção. Criando um índice na tabela vbak para o campo bname irá resolver o problema
neste caso. Exceção: tabelas cuja buferização é full ou generic (neste caso não tem sentido
pois o primeiro acesso irá trazer todos os dados para a memória. Das próximas vezes, o
sistema busca do buffer e não do database – até que o dado mude novamente).

2.8. Select sum, avg, min, max versus ABAP calculations

Select matnr kwmeng meins into <internal table>

From vbap where …. .
Collect <internal table>.
Endselect.

Ao invés use:
Select matnr sum( kwmeng ) meins into table <internal table>
From vbap where ….
Group by matnr meins.
O ganho em performance para o processamento de 10.000 registros:
Select + collect = 2.370.000 ms
Select sum …. Into table = 1.574.000 ms
OBS.: o group by não pode ser usado para tabelas pool e cluster.

2.9. Select sem cláusula where

Select col1 col2 …. Into …. from vbak.

Perform calculate_stuff.
Endselect.

Um select sem cláusula WHERE indica um erro no design do programa, especialmente se o

select é usado em tabelas SAP com grande crescimento/tamanho em pouco tempo, em geral,
BKPF, BSEG, COBK, COEP, LIPK, LIPS, MKPF, MSEG, VBAK, VBAP, VBPA, VBFA.

Programas irão rodar de forma correta e bem na entrada em produção, todavia a performance
irá decrescer à medida que dados são adicionados diariamente.

2.10. Table buffering

Para analisar a buferização de tabelas use função de chamadas estatísticas: Transaction

ST02 -> details analysis menu -> call statistics (tables). Esta função ajuda você a
determinar se tabelas desenvolvidas pelo cliente são buferizadas corretamente.

Para analisar a qualidade da buferização de tabelas use a transação ST02, dê duplo click em
TABLES (generic key) e clique no pushbutton “buffered objects”.

Por que buferizar ?

Usando buferização pode-se reduzir consideravelmente o tempo que se leva para recuperar
um registro.

Tipos de buferização:

a) full: resident buffer (100 %): o conteúdo de toda a tabela é carregado no buffer no primeiro
acesso realizado na tabela
b) generic: uma chave genérica (primeiros “n” campo chaves) é especificado quando da
criação da tabela, quando se mantém technical settings. Esta chave genérica divide o
conteúdo da tabela em chamadas áreas genéricas. Quando acessando qualquer dado com
uma deteminada/especificada chave genérica, toda a área genérica é carregada no buffer.
c) Partial (single record): somente registros únicos são lidos do banco de dados e
armazenados no buffer.
Quando bufferizar uma tabela ?

Uma tabela deveria ser buferizada quando:

 Menor em tamanho (poucas linhas ou poucas colunas com tamanho de campos pe-
quenos)
 acessada muito mais para leitura
 alterações não ocorrem frequentemente

Tabelas que são boas candidatas a buferização:

 tabelas de controle/tabelas de customização

 “smal” master data tables (ex.: 100 material master records -> few changes)

Como buferizar uma tabela ?

a) Como ativar/desativar uma buferização:

 dictionary maintenance (SE11 -> technical settings)
 technical settings for a table (transaction SE13)

b) Decidindo sobre o tipo de buferização:

 full (resident = 100 %)
 generic (with number of key fields for the generic key)
 single records (partial buffering)

SQL Statements bypassing the table buffer:

 select … bypassing buffer

 select from database views (projection views are ok)
 select … distinct
 select … count, sum, avg, min, max
 select … order by (other than the primary key)
 select … for update
 where clause contains IS NULL statement
 native SQL statements (EXEC SQL … ENDEXEC)
 Avoid these statements when working with buffered tables !!!
3. Outros responsáveis pela degradação da performance

 Move corresponding é interessante para pequenas tabelas ou quando alguns campos

(mas não todos) precisam ser movimentados.
 Não use sort - appends. Ele consome muito tempo de CPU e os resultados são
frequentemente imprevisíveis.
 Sempre especifique ASCENDING ou DESCENDING em processamentos com SORT.
Qualificar todos os comados SORT através da cláusula BY <data fields> melhora a
performance e a leitura do código, evitando assim que todos os campos do registro sofram
classificação
 Use COMPUTE ao invés de ADD, SUB, MULTI, DIV desde que performance não seja um
grande problema. O comando COMPUTE é mais fácil de implementar e com ele a leitura
do programa se torna mais fácil. A diferença em performance é minuto, todavia se o
objetivo é conseguir tempo de resposta de subsegundos para transações complexas, então
deve-se usar comandos separados
 Quando da definição de uma tabela no dicionário de dados do R/3 os campos chave
sempre devem ser colocados nas primeiras posições do registro da tabela (primeiras
colunas). O banco de dados comprime os dados para todos os campos da tabela, mas a
compressão não ocorre para campos chave. A compressão também só é possível para as
colunas após o último campo chave: isso explica o porque de agrupar todos os campos
chaves nas primeiras posições
 Transparent e Pool Tables: sempre que for feito um select para buscar dados de tabelas
deste tipo pode-se qualificar a cláusula WHERE com campos chave e não chave, ou seja,
quanto mais condições puderem ser definidas, melhor para a obtenção de performance.
Isto permite que o banco de dados avalie os registros e retorne somente aqueles que
“match” com o critério de seleção definido
 Cluster table: ocorre exatamente o inverso: devido a forma de armazenamento destas
tabelas, na cláusula WHERE deve constar apenas os campos chaves e os demais
campos devem ser checados através do comando CHECK. O banco de dados não
consegue processar cluster tables como ele processa transparent tables. Forçando o
banco de dados a descompactar e checar campos (em caso de Select com campos não
chaves na cláusula WHERE) é menos eficiente, na maioria dos casos, que qualificando
somente com campos chaves e deixando o CHECK para os campos não chave após eles
terem sido retornados. Na verdade ambos modos irão funcionar, porém um deles será
ineficiente pois irá requerer grande parte da memória disponível, espaço em buffer e tempo
do banco de dados para descompactar campos não chave, o que certamente irá refletir em
performance
 Campos que serão comparados na cláusula WHERE devem ter atributos similares. Se isso
não ocorre, o sistema tem que converter o dado toda vez que a comparação é feita.
Quando isso não é possível, mova o dado a ser comparado para uma área auxiliar, antes
de efetuar a comparação (esta área auxiliar deve ser definida com o mesmo tipo e tamanho
da coluna da tabela)
 Evitar classificações em várias tabelas e, posteriormente, a realização de loops. Ou
seja, evitar construções do tipo SORT tab1, SORT tab2, …, e depois o LOOP tab1, LOOP
tab2 …. . Isso funciona, porém irá requerer mais memória e recursos para possuir todos
os dados resultantes da classificação até que eles sejam usados. Ao contrário, quando se
faz SORT seguido de LOOP, o espaço é liberado ao término do loop.
4. Quando usar interna table ou Dictionary structure

Para tabelas que são usadas repetidamente ou por vários programas, considere a
possibilidade de criar estruturas de dados no Data Dictionary (e abrí-las através do comando
TABLES) ao invés de definí-las dentro de programas individuais (através do comando DATA
…. ENDDATA).

Sobre estas circunstâncias, o uso de tabela interna através do Data Dictionary é preferível:

 a tabela interna é grande

 a tabela é acessada da mesma forma toda vez
 a mesma tabela interna é usada em vários programas
 o programa irá processar várias tabelas internas ao mesmo tempo (e então precisa de
muita memória)
 o uso de memória é um ponto chave para otimização de um programa em particular

Use o comando FREE para liberar memória alocada a tabelas internas. Este comando deve
seguir o último comando para processamento do dado na tabela.

Use o comando FREE sob as seguintes condições:

 a tabela interna é grande
 a tabela interna é classificada e reprocessada várias vezes
 o programa está processando várias tabelas internas (e portanto necessita de grande
quantidade de memória)
 o uso de memória é importante para um programa em particular ser otimizado: um LOOP
AT …. WHERE é preferível a um LOOP AT … CHECK … ENDLOOP porque estará sendo
reduzido o número de comandos a serem interpretados
5. Processamento de grandes tabelas

5.1. Quando estiver sendo manipuladas grandes tabelas é muito importante que seja
processada a maior quantidade possível de informação num primeiro momento e, se possível,
eliminar qualquer outra passagem nesta mesma tabela. Muitas vezes isso requer o uso de
tabelas internas. Cada situação deve ser analisada e avalidada, para ver qual o procedimento
correto a ser tomado: se armazenar o dado ou fazer novo acesso à tabela do Data Dictionary.
Considere as seguintes questões:

 qual o tamanho da tabela original comparado ao subset que seria armazenado em uma
tabela interna ?
 quanto espaço para armazenamento seria necessário para armazenar o dado em uma
tabela interna ?

Se o processamento precisar ocorrer somente uma vez (por exemplo, armazenar alguns
dados para posterior comparação), esteja certo que isso acontecerá fora de uma estrutura em
forma de looping (por exemplo, Select, Loop, Do), de forma que o processamento não seja
repetido desnecessariamente.

Dica: o operador IN consome muito tempo de máquina e não deveria ser usado em lugar do
operador EQ .

5.2. Expressões lógicas são avaliadas da esquerda para a direita. A avaliação termina quando
o resultado final foi estabelecido (eliminação ou inclusão completa). Todavia, quando se utiliza
os operadores AND ou OR (por exemplo, em IF, WHERE) o critério de eliminação mais comum
deve ocorrer primeiramente.

Exemplo:
Table: The following table is to be read with printing of Employees from ABC Company in
Georgia

EMPLOYEE NAME COMPANY STATE

001 Doe, Jr. ABC TX

002 Doe, M. ABC OK
003 Jones, A. XYZ TX
004 Jones, B. ABC GA
005 Jones, C. ABC TX
006 Jones, D. XYZ GA
007 Jones, E. ABC TX
008 Smith, A. ABC GA
009 Smith, B. ABC TX
010 Smith, C. ABC OK

if company = ‘ABC’ and

state = ‘GA’
write …..
endif.
 isto funciona, mas tanto os campos company quanto state precisam ser avaliados para oito
de dez campos

if state = ‘GA’ and

company = ‘ABC’
write …..
endif.
 isto necessita menos tempo para ser processado, porque ele elimina todos os registros
sem state = ‘GA’ e portanto tanto o campo company quanto state precisam ser avaliados para
somente três registros.

5.3. Índices secundários:

sempre esteja certo que o seu índice está sendo usado:

“ A well-defined and properly implemented index is one of the best performance and tuning tool
available. Because of the diversity of various database systems, however, and in particular
various database optimizers, it is not possible to establish any hard-and-fast rules for creating
and using database index. Additionally, it is impossible to guarantee that the database
optimizers will use your index “.
Para saber se o índice definido está sendo usado:
* use o SQL Trace (transação ST05) para ativar e desativar o trace
* clique em trace on
* execute a transação em questão em uma outra sessão
* retorne a ST05 e clique em trace off
* clique em list trace para visualizar os resultados de seu trace
* clique em prepare, open ou reopen para selecionar o comando SQL que
será avaliado
* clique em EXPLAIN para obter o resultado do comando SQL
5.4. Regras gerais para criação e uso de índices secundários:

5.4.1. Um índice suporta pesquisa a dados no banco de dados. Todas as tabelas standard
SAP possuem um índice primário, o qual consiste de campos chaves que o usuário define
quando da criação de uma tabela. Para os selects aonde a chave primária não pode ser
utilizada na cláusula WHERE, ou quando selects não são qualificados, o banco de dados
pesquisa a tabela inteira (executa uma varredura sequencial).

O Dicionário de Dados da SAP suporta até 16 índices para cada tabela.

Geralmente, crie índices com menos que 5 campos.

Geralmente, se uma condição inclui OR, o otimizador pára o processamento (e chama uma
varredura sequencial) tão logo o primeiro OR seja encontrado. A exceção possível é um OR
que propõe uma condição separada e única para avaliação.

Exemplo:
ZTABLE é definida com um índice secundário:

FIELD NAME TYPE LENGTH

FieldC Char 3
FieldF Char 2

Select * from ztable where

fieldc = ‘ABC’ and
(fieldf = ‘12’ or ’13’)
 isto é executado, mas não usa o índice conforme esperado

Select * from ztable where

(fieldc = ‘ABC’ and fieldf = ‘12’) or
(fieldc = ‘ABC’ and fieldf = ‘13’)
 isto é executado usando o índice

5.4.2. Informações gerais:

 Cláusulas IN são frequentemente interpretadas como condições OR e podem gerar
alguns problemas
 Índices não são usados para condições IS (NOT) NULL
 A maior parte dos otimizadores tem problemas com condições OR, NEQ e LIKE
Exemplo:

ZTABLE é definida com um índice secundário

FIELD NAME TYPE LENGTH

FieldA Char 3
FieldB Char 3
FieldC Char 2
FieldD Char 4

Select * from ztable

Where fieldA = ‘ABC’ and
field B = ‘XYZ’ and
fieldC = ‘12’.
 isto funciona bem.

Select * from ztable

Where fieldA = ‘ABC’ and
field B = ‘XYZ’ and
fieldD = ‘DEFG’.

 isto não usa o índice conforme esperado e provavelmente invoca uma varredura
sequencial da tabela baseada na chave primária

5.4.3. Considere a criação de um índice se um ou mais condições se aplicarem:

 campos não chave são repetidamente usados para fazer seleções

 somente uma pequena parte de uma grande tabela é selecionada (< 5%)
 a cláusula WHERE de um comando SELECT é simples
 os campos que compõe o índice reduzem significativamente o conjunto de registros em
uma cláusula WHERE

5.4.4. Não crie índices se uma das seguintes condições se aplicar:

 a redundância de dados de armazenamento do índice cria problemas devido ao tamanho
da tabela ou índice
 atualizações constantes criam excessivo overhead ou perda de performance durante a
atualização do índice
 manutenção de um índice (como a reorganização) causa perda dos benefícios
 estão sendo usados campos cujos valores para a maioria dos registros na tabela é um
valor inicial ou tem um valor que é idêntico para a maioria dos registros
6. Conceito de atualização em update task

Para aproveitar ao máximo os recursos computacionais de cada nível, a SAP criou um

conceito de atualização em update task. Se for feita uma pesquisa em todos os programas
"on-line" da SAP, será verificado que a atualização é sempre em funções que só fazem o
update, e que não retornam valores nem mesmo exceptions se estas ocorrerem. (CALL
FUNCTION .... IN UPDATE TASK).

Logo todas as aplicações fazem todas as checagens possíveis e imagináveis antes de

chamarem estas funções, ou seja, as exceptions que podem ocorrer são somentes as de BD
(por exemplo table space, ou algo não previsto). Se uma aplicação faz "n" atualizações, esta
irá chamar "n" funções (uma para cada update de um conjunto de tabelas) e, ao final, dará um
commit work. O que o R/3 faz é simplesmente ir criando todos estes dados em uma espécie de
log. No momento do commit work ele cria uma outra LUW no servidor de BD e passa esta
tarefa para este. Note que o programa (que esta sendo processado no servidor de aplicação),
não fica esperando a resposta se o update ocorreu corretamente ou não, ele continua o
processamento e termina a transação muitas vezes antes do servidor de DB ter terminado o
processamento.

A vantagem óbvia deste processo é a diminuição de gargalos via este "tratamento de

mensagens" entre as duas camadas (DB e aplicação).

Quando se utiliza o comando SET UPDATE TASK LOCAL o servidor de aplicação passa a
executar o update (ou seja, não é criado uma outra LUW no servidor de DB) e este fica
esperando a resposta se tudo ocorreu OK.

Um SET UPDATE TASK LOCAL é suficiente para todo o processamento do commit ser
efetuado como local. Por isso, todos os updates da SAP procuram não utilizar o comando Set
update task local. O default é o SET UPDATE (em funções). Isso evita que a performance seja
degradada.
6. Comandos Select

Visando garantir a performance e evitar problemas futuros, cuidado com os comandos

empregados. Existem alguns tipos de select mais eficientes que outros. Analise a aplicação
que será desenvolvida e faça a melhor escolha.

ALGUNS TIPOS DE SELECT

7.1. SELECT …FROM <table> INTO TABLE <INTERNAL TABLE> .

A estrutura da tabela interna deve corresponder à estrutura da tabela que está sendo
acessada. O sistema lê os registros em conjunto, não individualmente, e os coloca dentro de
uma internal table. Este processo é mais rápido que ler individualmente através de um LOOP
e ir gravando os registros, um a um.

7.2. SELECT * FROM <table> APPENDING TABLE <internal table>.

Lê os registros e os inclui - não sobrepõe - em uma internal table.

7.3. SELECT …. INTO CORRESPONDING FIELDS OF TABLE <itab>.

Neste caso a estrutura da tabela interna não precisa corresponder à estrutura da tabela que
está sendo acessada. <itab> é o nome da internal table. Movimentará os registros para as
colunas definidas na internal table que possuam nome igual ao da tabela acessada).
Obs.: corresponding ou appending corresponding não exigem o endselect.

7.4. SELECT ….. APPENDING CORRESPONDING FIELDS OF TABLE <itab>.

Lê e grava (não sobrepõe) os dados em uma internal table que possua nomes idênticos aos
nomes da tabela que está sendo lida.

7.5. SELECT SINGLE * FROM SPFLI WHERE …..<campo>….. EQ … <conteúdo>

Toda vez que se usa select single * a chave primária completa deve ser especificada. Se a
chave especificada não é qualificada, você receberá uma mensagem de warning e a
performance ficará prejudicada.
No caso de haver a necessidade de acessar um único registro via select, as opções são:
select * ….. seguido de comando exit OU select * … up to 1 row. Neste caso não é
necessário especificar a chave completa.

7.6. SELECT * FROM …<tabela>

Quando não se impõe nenhum tipo de restrição, ocorre uma varredura sequencial dos
registros da tabela. Quando se utiliza grandes tabelas, isso obviamente afeta o runtime.

Select * seleciona todas as colunas de uma tabela. É melhor sempre especificar as colunas,
pois em caso de tabelas com muitas colunas, prejudicará performance.
7.7. SELECT * FROM <tabela> WHERE <campo> eq <conteúdo>.
Lê todos os registros da tabela especificada onde o campo é igual ao conteúdo especificado.
O ideal é que se qualifique a cláusula WHERE tanto mais quanto seja possível. Atentar que
isso é válido para tabelas do tipo Pool e Transparent. Para Cluster, seguir as recomendações
dadas anteriormente.

7.8. SELECT <a1> <a2> … INTO (<f1>, <f2>, … ) FROM ….<tabela>

WHERE …… .
Lê as colunas especificadas (a1, a2). Após INTO deverão ser especificadas as áreas de
trabalho auxiliares (f1, f2). O número de colunas lidas deverá ser igual ao número de work-
areas especificadas.

7.9. SELECT * FROM <table> WHERE <table field> BETWEEN <field1> and <field2>.
Ex.: field1 = 100 e field2 = 500. Pega inclusive 100 e 500. Você trabalha com o range.

7.10. SELECT * FROM <table> WHERE <table field> LIKE ….’_R%’.

_ = a primeira letra não importa o que virá
a segunda deverá ser R (eu defini)
% = não importa a sequência de caracteres que virá.
(Varredura para que possa realizar a comparação)

7.11. SELECT MAX(campo)

MIN(campo)
AVG(campo)
COUNT(*) FROM <table> INTO (…..,……,…..,….)
WHERE ………… .

AVG e SUM: somente para campos numéricos.

Não se usa endselect.
Mais rápido fazer uma rotina “à mão” que utilizar este comando.

7.12. SELECT * FROM <table> WHERE <table field> IN (…….,…….).

Exemplo: select * from <table> where campo1 in (123,1000) - podem ser valores ou literais. É
igual a perguntar se campo1 é 123 ou 1000.

7.13. SELECT * FROM <table> WHERE <table field> IN <internal table>.

Exemplo:
DATA : begin of ITAB occurs 10,
sign(1), option(2), low like sflight-price, high like sflight-price,
end of ITAB.

* RANGES: ITAB for sflight-table

Move: ’I’ to itab-sign, ‘bt’ to itab-option, ‘500’ to itab-low, ‘1000’ to itab-high.
Append itab. Move: ’I’ to itab-sign, ‘bt’to itab-option, ‘440’ to itab-low.
Append itab.

7.14. SELECT * FROM (<table>) INTO <work area>.

Exemplo: data: begin of WA,
line(100),
end of WA.

7.15. Select * from (tabname) into WA

Write ….
Endselect.

Parameters: tabname(10) default ‘SPFLI’.

Obs.: especificando o nome da tabela dinamicamente no select statement sempre consome
mais tempo de CPU que especificando estaticamente no programa.

7.16. SELECT * FROM <table> FOR ALL ENTRIES IN <internal table> WHERE
campo1 = <conteúdo> and
campo2 = <conteúdo>
Defino uma tabela interna. Alimento os campos desta tabela interna. (move e append). No meu
select campo1 e campo2 serão os campos definidos e alimentados na tabela interna.
Esta é uma excelente solução quando se trabalha com grandes tabelas.
O select for all entries simula a funcionalidade join.

7.17. SELECT * FROM <table> ORDER BY <field1> <field2> … PRIMARY KEY.

Obs.: Classifica a tabela interna numa área auxiliar, sem afetar a tabela original. Evitar o uso
de sorts dentro de um select. Consome mais tempo que descarregar os dados em uma tabela
interna e classificá-los.

7.18. SELECT carrid MIN( price ) max( price ) INTO (carrid, minimum, maximum)
FROM sflight GROUP BY carrid.
(Todos os campos que eu quero que apareçam na minha lista eu preciso especificar após a
cláusula GROUP BY. Carrid, maximum e minimum são campos auxiliares. Se o nome do
database não é conhecido até runtime não se pode especificar a cláusula GROUP BY).
Performance não é tão boa (funções MIN, MAX, etc. geram uma varredura sequencial na
tabela).

7.19. SELECT * FROM <table> BYPASSING BUFFER.

(Usado para ler diretamente da tabela original, e não do buffer).

OBS.: Select single * sempre com chave completa especificada. Particularidade do Abap/4.
Select * - procurar evitar. Informar as colunas que serão necessárias, apenas.
8. Dicas para otimização do código (no mercado é dada pouca importância)

- Use o comando FREE para liberar espaço em internal tables; Sempre usar os comandos
Clear / Refresh após o fim de um LOOP;
- Evite comparações num SELECT com campos numéricos versus campos alfanuméricos; o
sistema perde tempo para conversão;
- Testar SY-SUBRC após cada acesso ao banco de dados;
- O comando MOVE-CORRESPONDING é bom para tabelas pequenas. É interessante que
a tabela interna contenha os campos na sequência em que serão movimentados;
- Ao utilizar o comando CASE, codificar sempre a cláusula WHEN OTHERS;
- Sempre identifique se um SORT é ascending ou descending e especifique a cláusula
BY <fields>. Caso contrário, todos os campos serão classificados.
- Evitar lógicas do tipo IF not CPOA = CPOB. É mais claro codificar IF CPOA ne CPOB.
- Evitar construções do tipo:
SORT tabela1, SORT tabela2, SORT tabela3.
LOOP tabela1, LOOP tabela2, LOOP tabela3
Para cada SORT fazer o LOOP correspondente. Aí então iniciar novo
SORT e LOOP, e assim por diante.
- Campos chave devem ser sempre os primeiros campos da tabela. Assim, todos os demais
campos serão comprimidos;
- SELECT (para Transparent e Pool Tables): a cláusula WHERE deve conter,
preferencialmente, os campos chaves e demais campos que possam restringir a
pesquisa;
- SELECT (para Cluster Tables): só os campos chaves devem ser especificados na
cláusula WHERE. Os demais devem ser checados através do comando CHECK;
- O conhecimento do conteúdo dos dados de uma tabela pode auxiliar no momento da
codificação do comando select. O campo que ocorrer em número menor de vezes
deverá constar na cláusula where antes daquele que ocorre um número maior de
vezes, caso seja necessário satisfazer a ambas condições. Isso faz com que o
processamento seja mais ágil.
- Manuseio de tabelas: Estudar a possibilidade de manuseio em tabelas internas para
agilizar o processo. Analisar também o uso de comando select, sendo o que melhor se
adapte a situação em questão.
9. Ferramentas para auxliar os desenvolvedores

Existem algumas ferramentas que auxiliam os desenvolvedores a descobrir erros (errors,

warnings, etc), bem como avaliar a performance de seus programas.

Path: Tools – Abap/4 Workbench – Test - Runtime Analysis

Existe um pushbutton chamado Tips and Tricks – Clicando-se nele poderá ser feita
comparação entre comandos Select (diferentes tipos). Dando double-click sobre um dos
exemplos você passará para outra tela, onde você visualizará a medida do tempo em
microsegundos de ambos, servindo de base de comparação.

Neste mesmo path, pode-se utilizar as facilidades do Runtime Analysis para verificar a
performance de seu programa. Ao final da execução você poderá acessar informações sobre o
seu programa (gráficos, acesso a tabelas, etc). Para tanto clique o pushbutton ANALYSE, que
somente aparecerá depois que for informado o nome do programa e/ou transação e clicado
execute.

O SQL Trace (transação ST05) é outra facilidade que pode ser utilizada para trilhar a lógica
de sua aplicação e verificar possíveis pontos de correção. Você poderá visualizar os
comandos de acesso a banco de dados utilizados, obter informações sobre um comando
específico, visualizar os índices que estão sendo utilizados (ver tópico 5.3 sobre como utilizar
o SQL Trace).

O Extended Program Check é outra facilidade que deve ser empregada visando manter o
seu código o mais correto possível. Nesta opção você poderá selecionar os ítens que você
deseja que sejam checados e o sistema apontará o seu parecer. Para tanto basta clicar os
ítens e o pushbutton PERFORM CHECK Selecionando uma linha você poderá ver os
detalhes, bem como posicionando o cursor em uma linha e clicando o pushbutton DISPLAY
ALL CHANGES.
10. Interfaces Batch ou Conversões:

Segundo a documentação da SAP, existem três métodos para conversão: Direct input, Call
transaction e o Batch Input.

 Direct Input: é um dos métodos para transferência de dados do sistema legado para o
sistema R/3. É considerado o método mais rápido. Um arquivo sequencial com dados é
gerado como um arquivo texto para processamento por alguns function modules especiais.
Estas funções executam todas as checagens normais para garantir a integridade de dados.
Quando os registros são processados com sucesso, eles são gravados diretamente nas
correspondentes tabelas do banco de dados da aplicação. Na ocorrência de erros, os
dados errados são passados para uma rotina de manuseio de exceção. O gargalo
associado com o processamento do dialog e update são eliminados neste caso. Para todas
as necessidades de transferência de dados, especialmente com transações de alto
volume, o direct input é o método mais indicado. Nota: este método deveria ser usado em
todas as situações nas quais funções de aplicação utilizando esta tecnologia existam.

 Call Transaction: é o próximo método mais rápido para processamento de dados do

sistema legado para o sistema R/3. Neste caso, o programa de transferência de dados
processa os dados do arquivo sequencial e chama a transação desejada usando um
comando Abap. Dados de um arquivo sequencial são processados via telas de aplicação
para uma única transação. A lógica de aplicação executa todos os checks e a validação
dos dados. Este é um processamento síncrono. Quando o processamento do dialog é
realizado com sucesso, o processamento do update é chamado pela aplicação
correspondente para executar todas as solicitações do banco de dados. A escolha pode
ser feita entre update síncrono ou assíncrono. Nenhum protocolo de erros ou saída para
lidar com os erros é fornecida por esta técnica. É responsabilidade do programador da
aplicação incorporar rotinas de execução e funções dos protocolos desejados como parte
do programa de transferência de dados. A nossa recomendação é usar o método Call
Transaction em todos os casos em que não existe um programa Direct Input. Somente em
situações de lidar com erros nós recomendamos que o batch-input tradicional seja
realizado para posterior processamento. Resumo: em contraste com o Batch-Input, o Call
Transaction permite que sejam passados dados diretamente ao dialog interface sem usar
uma fila. Para armazenar estes dados temporariamente, você usa uma internal table (uma
tabela BDC, a qual tem a mesma estrutura daquela utilizada no batch-input). Antes de
inputar dados na BDC table é necessário fazer um “ckeck” nos dados. Call transaction:
pode ser executado imediatamente.

 Batch-Input: o batch-input tem sido tradicionalmente selecionado como um método de

implementação de programas de transferência de dados. Um benefício que este método
traz sobre o Call Transaction é que o batch-input tem um utilitário responsável pela
administração e gerenciamento das funções do batch-input. Além do mais, utilitários
existem para monitorar e dar manutenção em tarefas associadas com este método. Assim,
não há necessidade de nenhuma programação adicional para análise de exceções e
funções de protocolo. Dados vindos de um arquivo sequencial são processados via telas
de aplicação e armazenados numa sessão batch-input. Por definição, uma sessão é uma
coleção de dados de transação para uma ou mais transações. As sessões batch-input são
fisicamente armazenadas pelo sistema num banco de dados como uma fila. Estas sessões
podem conter tanto registros de dados corretos quanto incorretos. O batch-input trata tanto
o update síncrono como o assíncrono. O método batch-input, em contraste com o método
Call Transaction, pode transferir dados do sistema legado para o sistema R/3 para
múltiplas transações da aplicação. Todavia, nenhuma nova transação é startada até que a
transação anterior tenha sido gravada no correspondente banco de dados durante o
processamento das sessões de batch-input. Também, sessões de batch-input não podem
ser geradas em paralelo. Ele pode ser processado de três modos: foreground, display
erros only ou background.
Este método oferece excelente capacidade para gerenciamento de erros e é detalhado
para análise do protocolo da transação.
Resumo: é gerado um log e pode ser programada a execução. Em caso de erro, o registro
pode ser corrigido e inserido novamente. Através deste recurso, todos os dados são
inputados na transação original SAP, ou seja, seguindo todas as consistências
necessárias, evitando assim que erros de integridade sejam cometidos.

AVALIAÇÃO:

Sempre execute alguns testes dentro do processo de transferência de dados e avalie qual
é o método mais apropriado para uso, dado o volume de dados, tamanho, recursos e
performance do sistema.

Todos os fatores sendo iguais, o método Direct Input deve ser usado em todos os casos
em que tais funções estejam disponíveis ou novas funções para transferência de dados
precisem ser desenvolvidas.

Para escolher entre o Call Transaction e o Batch-Iput, sempre use o Call Transaction
primeiro e manuseie as exceções então através do método de batch-input. Esta estratégia
é altamente recomendada em implementação de soluções de programação para
transferência de dados com sistemas legados.
11. Estudo de Caso – Cliente XYZ
(Parte do relatório de Quality Assurance da Fase III)

Dentro do escopo do XYZ seria necessário o desenvolvimento dos seguintes tipos de programa:

. Conversões
. Reports
. Formulários (SapScript)
. Interfaces

O trabalho baseou-se na análise de interfaces, haja visto as conversões já terem sido

processadas (na sua maioria) para atender a primeira fase de implantação do projeto. Mesmo
assim, foi analisado um programa de conversão, cuja técnica utilizada foi Batch-Input. Quanto aos
Reports, estes se encontram em fase de levantamento, não sendo possível, portanto, fazer
qualquer tipo de validação.

Do total de interfaces desenvolvidas, buscou-se uma amostra (7 programas), utilizando-se os

seguintes critérios:

. programas considerados críticos, ou seja, que necessitam de um tempo de resposta eficiente,

pela necessidade de serem pseudo-online e seu processamento ocorrer a cada “x” minutos;
. programas que manipulam quantidades elevadas de dados diariamente;
. grandes tabelas do R/3 (quantidade de registros versus colunas existentes);
. funções do standard que não apresentam boa performance (por serem genéricas) quando
utilizadas com finalidades específicas;
. áreas de aplicação diferentes (MM, FI, etc)
. desenvolvedores diferentes (foram analisados programas de diferentes pessoas).

Obs.: exclui-se de nossa análise todos os programas de interface que encontram-se em fase de
desenvolvimento.

Alguns dados:

. Total de interfaces : 40
. Status : 03 em desenvolvimento
02 não tiveram desenvolvimento ABAP
35 estão concluídas
. Programas selecionados : ZIFIT002, ZIFIT006, ZLUIZ001 (antigo ZIMMT001)
ZIMMT006, ZIMMT010, ZIPMR001

Quanto à confecção de especificação técnica:

1. O correto seria existir uma especificação técnica com o intuito de servir como base para o
desenvolvedor. Todavia, tal documentação está ficando pronta apenas ao término do
programa. Esta situação não é a ideal. Todavia, se torna indispensável a sua confecção
visando facilitar manutenções futuras;

Quanto ao esquema de testes:

1. É de extrema importância que, além dos testes individuais, sejam realizados testes com massa
de dados real de produção, visando reproduzir um ambiente real durante a fase de execução
das interfaces, com o objetivo de minimizar/eliminar problemas com performance;

2. Os testes devem englobar todas as condições lógicas possíveis, e até mesmo condições de
erro. Não existe esquema de “stress-test” (com grande volume de dados). A massa de dados
não deve ser gerado pelos desenvolvedores;

Quanto à uniformidade do código e ao uso da metodologia (padrões) definidos na Fase

II:

1. Na amostragem analisada foi constatado que o manual de Padrões não foi seguido de forma
íntegra. Em alguns casos (como por exemplo na Nomenclatura definida para Funções)
constante no manual, a forma utilizada nos programas é muito mais clara que aquela
anteriormente definida. Aconselha-se alterar o manual de Padrões, citando a nova forma
utilizada. No caso da definição de data-elements, este padrão não foi seguido para as tabelas
analisadas. Isso também se aplica aos nomes definidos para as sessões de Batch-input
pesquisadas via SM35 na data de nossa visita. Estes pontos não tem implicações graves sobre
os programas, todavia somente vale a pena a criação de uma metodologia caso ela seja, de
fato, seguida, e que esta visa facilitar o trabalho de pesquisa/leitura/manutenção de programas
;

2. Ainda dentro do tópico metodologia alguns pontos deveriam estar sendo seguidos: são os
nomes de variáveis. Nem todos os programas obedecem este tópico de forma integral ou
parcial. Este item é muito importante, uma vez que facilita a leitura dos programas e futuras
manutenções por terceiros ou até mesmo pela equipe técnica do XYZ;

3. Uso de mensagens fixas ao invés de text-elements, uma vez que o R/3 aceita várias
linguagens e isto é definido em momento de logon no sistema.

Quanto a performance dos programas:

1. Dentro da amostra selecionada foram encontrados erros que se repetiam. São eles:

a) Ninhos de select
b) Select * ao invés de select com suas respectivas colunas
c) Falta de condições na cláusula where para limitar o números de registros retornados através
do comando Select
d) Tabelas como BKPF, BSEG, EKKO, EKPO, VBAK, VBAB, MKPF, MSEG, J_1BNFDOC,
J_1BNFLIN devem possuir, tantos campos quanto possível para restringir a pesquisa e busca
de dados.
e) Uso da função CLAS_CLASSIFICATION_OF_OBJECTS com finalidades específicas

Devido à estrutura cliente servidor, resultados melhores de performance estarão sendo

alcançados toda vez que a comunicação entre o servidor de aplicação e o servidor de banco de
dados for minimizado.

Em vários casos encontramos selects em tabelas grandes, como por exemplo, a BKPF, trazendo-
se todos os registros que atendessem a uma única condição (por exemplo, código da transação).
É de extrema importância que, em casos de tabelas grandes (tanto em termos de volume quanto
em termos de quantidade de colunas) sejam recuperadas apenas as informações necessárias ao
atendimento do propósito do programa (colunas e condições). Deve-se lembrar que, com o passar
do tempo, a quantidade de dados presentes nestas tabelas estará crescendo; em contrapartida,
haverá uma redução da performance caso o programa não esteja fazendo seleções adequadas.
Uma forma de se obter maior seleção é inserindo um delimitador do tipo DATA, campos que
estejam presentes não somente na tabela acessada mas também na próxima que se deseja
acessar.

Dentro do exemplo acima, em forma de um ninho de Selects, é feito um outro Select para a tabela
BSEG. Ou seja, para cada registro da BKPF será acessada a tabela BSEG. Esta mesma situação
pode aparece em vários níveis, o que resulta num caos em termos de performance, à medida que
temos a base de dados sendo acrescida.

Além das precauções anteriores, as quais devem ser aplicadas sempre que possível, vale a pena
mencionar que o uso de tabelas internas agiliza muito o processamento. Selects que, num único
comando, sejam responsáveis por acessar a tabela, fazer a seleção do range de dados
necessário, movimentar estes dados para uma tabela interna e gravar estes dados terão
performance superior à uma situação de Select … endselect e infinitamente superior a uma
situação de Select … endselect em ninho.

Ilustrando uma situação semelhante, temos:

Select * from bkpf where tcode = ‘FB01’.

Select * from bseg where bukrs = bkpf-bukrs and

belnr = bkpf-belnr and
gjahr = bkpf-gjahr.
Endselect.
Endselect.

* O primeiro comando seleciona as 79 colunas da tabela bkpf através do campo TCODE que, além
de não pertencer à chave primária desta tabela, também é um critério muito amplo para pesquisa
em tabelas deste porte. Campos como company code, data, ano fiscal, entre outros, podem ser
fortes candidados a restringir a pesquisa.

* O segundo comando seleciona as 266 colunas da tabela bseg, onde os campos bukrs, belnr e
gjahr sejam iguais à tabela anterior. Como na tabela anterior não foi utilizado um critério de
seleção mais adequado, muitos registros serão retornados da bkpf e, consequentemente, para
cada um destes registros, serão retornados “n” registros da BSEG.

* Ambos os selects corresponderão a tantos acessos no banco de dados quantos registros

existirem.

Visando garantir melhor performance, poder-se-ia utilizar:

Select col1 col2 col3 … into table tab_bkpf from bkpf where <conditions>.

Select col1 col2 col3 col4 into table tab_bseg

from bseg
for all entries in tab_bkpf
where < conditions >.

OBS.: O exemplo dado de seleção de colunas é válido. Porém, vale lembrar que não é possível
fazer select colunado de tabelas Cluster.

Algumas considerações:

* Ambos os selects corresponderão a um único acesso no banco de dados.

* O primeiro comando select já seleciona, move e grava os dados numa tabela interna.
* O segundo select será baseado no resultado, já em tabela interna, do primeiro select.
* São selecionadas apenas as colunas realmente necessárias. Assim, os pacotes transmitidos
entre o servidor de banco de dados e o servidor de aplicação são menores, agilizando portanto a
transferência.
* tab_bkpf e tab_bseg são tabelas internas.

Outros erros que devem ser evitados:

a) Hard Code
Alguns programas foram desenvolvidos baseando-se apenas na configuração atual do sistema
R/3. Com isso, aparecem algumas checagens de forma fixa, por exemplo, checagens de centros
(campo werks), conta contábil, etc., o que invalida os programas caso seja alterada a
configuração.

b) Tabela de contadores idealizada para controle de processamentos e reprocessamentos não é

totalmente confiável

Foi criada uma tabela para controle do processamento, visando controlar quais registros foram ou
não processados em caso de alguma interrupção. O objetivo é permitir reprocessamentos
parciais. Tendo em mente que as transações estão sendo chamadas via Call transaction, técnica
esta que possui um commit próprio, e que a atualização da tabela de controle está num outro
commit, poderá ocorrer situações onde a tabela de controle não representa exatamente o que
aconteceu.

Necessidades:

a) Stress-test
b) Testes integrados

Comentários/Recomendações:

O ponto mais crítico está associado ao tópico de performance. É necessário fazer revisão em
todos os programas de interface, visando detectar situações semelhantes à descrita anteriormente
e providenciar as adequações necessárias.

Outro ponto de fundamental importância se refere aos testes. A garantia do bom funcionamento do
programa e a minimização de problemas com performance somente ocorrerá caso seja realizado
testes com massa de dados real, ou seja, volumes próximos ao esperado em ambiente produtivo,
cobrindo as situações que possam ocorrer.

Restrições:

Caso ocorra a entrada em produção sem a alterações nos programas, a performance será
decrescente, à medida que as bases de dados forem crescendo. Também não se pode garantir
que todas as interfaces pseudo-online serão processadas e finalizadas dentro do tempo
estipulado (por exemplo, a cada 5 minutos, etc).

Parecer:
De uma forma geral pode-se dizer que o desenvovimento está bom, porém caso os programas
não sejam revisados e adequados, certamente ocorrerão problemas de performance após a
implantação.
 QUADRO RESUMO DA SITUAÇÃO DO PROJETO DA XYZ

Tópico Status
Confecção de especificação técnica 1.
V

Esquema de testes Não validado

Uniformidade do código-metodologia- Validado com restrições
padrões
Performance Validado com restrições,
desde que os programas
sejam revisados e alterados
Outros erros Não se aplica
12. Estudo de Caso - Cliente ABC
(Parte do relatório de Quality Assurance da Fase III)

SITUAÇÃO ATUAL

Dentro do escopo da ABC seria necessário o desenvolvimento dos seguintes tipos de programa:

. Conversões
. Reports
. Formulários (SapScript)
. Interfaces

Obs.: Não houve necessidade de programas online.

Devido a alguns problemas, que serão detalhados mais adiante, o cronograma inicial cuja
expectativa era conter apenas 26 gaps sofreu alterações em termos de volume de
desenvolvimentos e também um atraso, estando neste momento a maioria dos programas em fase
de desenvolvimento e/ou testes. Novos desenvolvimentos também foram incorporados ao projeto
(cerca de oito novos programas foram criados). Assim sendo, optou-se por fazer o QA sobre os
programas em 24.06.98, independente de não estarem concluídos, uma vez que em caso da
necessidade de efetuar algum tipo de correção, haveria ainda seis dias corridos antes da data de
implantação.

Dado a esta situação, ressalta-se também que o coordenador de ABAP (parceiro da SAP) ainda
não teve tempo hábil para fazer a revisão dos programas que foram desenvolvidos, verificando o
cumprimento de normas, padrões e situações cuja performance não fosse satisfatória, antes que
os programas fossem apresentados ao Quality Assurance da SAP. A grande preocupação, no
momento, é a confecção dos programas.

Essa situação de análise de programas em desenvolvimento é atípica, uma vez que nossa análise
deveria se basear apenas sobre os programas já concluídos e revisados pelo parceiro de
implementação, mas dada a situação, isso não foi possível.

Alguns dados (dados aproximados, uma vez que o cronograma do projeto e status não estavam
atualizados):

. Total de programas : 34

. Status

1. Conversões - Cargas automáticas:

. Cadastro de código NBM : conversão realizada
. Cadastro de taxas de câmbio : conversão realizada
. Cadastro de Materiais (inicial) : conversão realizada
. Cadastro de Fornecedores (inicial) : conversão realizada

. Cadastro de Contas a Pagar (inicial) : programa em fase de testes

. Atualização de Estoques : em desenvolvimento-80 % já realizado
. Atualização de Pedidos : em desenvolvimento-80 % já realizado

2. Interfaces (em ordem de prioridade):

. Estoques (SAP -> DISPO/OP) : em desenvolvimento
. Livros Fiscais (SAP->PRECIS) : em desenvolvimento
. Pedidos (SAP -> AVERAGE) : em desenvolvimento
. Contas a Pagar (SAP -> BAYMAP) : em desenvolvimento
. Movimentos de Materiais (SAP -> BAYMAP): em desenvolvimento

. Fornecedores (SAP -> BAYMAP) : não desenvolvido

. Moedas (SAP -> AVERAGE) : não desenvolvido

Obs.: Interfaces de Estoques e Livros Fiscais são indispensáveis para a data de implantação
(01.07.98), no mínimo. As demais devem ser disponibilizadas logo após, para uso no decorrer do
mês de julho.

3. SapScripts:
. Certificado de Qualidade : desenvolvido
. Certificado de Análise : desenvolvido
. Pedidos : em testes
. Cotações : em testes
. Requisições : não será desenvolvido

4. Relatórios:
. Relatório de Confirmação de ordem de processo (1 e 2): desenvolvido
. Relatório de produção diária e mensal : aguarda definição de uma das
interfaces para ser desenvolvido
. Relatório síntese de estoque : não será desenvolvido. Será
utilizado relatório standard do R/3.

5. Matchcodes:
.Lote na ordem de processo : será desenvolvido
. Ordens não liberadas : será desenvolvido
. Ordens não confirmadas : será desenvolvido
. Materiais por grupo de listas técnicas : desenvolvido
. Fornecedores CGC/CPF : desenvolvido

Panorama das atividades:

O trabalho baseou-se na análise de interfaces, e de alguns relatórios já concluídos, haja visto a
maioria dos programas de conversão já terem sido processados antes do Quality Assurance da
Fase III. Mesmo assim, foi analisado um programa de conversão, cujas técnicas utilizadas foram
Batch-Input/Call Transaction. Posteriormente, obteve-se a informação de que estes mesmos
programas serão utilizados para as interfaces inbound (carga de dados do sistema R/3 a partir do
sistema legado). Neste caso, serão encaminhados somente os dados alterados e/ou os dados
novos. Como a carga de dados inicial apresentou tempo de processamento considerado baixo
pela equipe da ABC, utilizando os mesmos programas e com volume de dados superior ao que
existirá na execução das interfaces, este item não se torna preocupante.

Do total de interfaces desenvolvidas, buscou-se uma amostra (11 programas), utilizando-se os

seguintes critérios:
. programas considerados críticos, ou seja, que necessitam de um tempo de resposta eficiente,
pela necessidade de serem pseudo-online e seu processamento ocorrer a cada “x” minutos;
. programas que manipulam quantidades elevadas de dados diariamente;
. grandes tabelas do R/3 (quantidade de registros versus colunas existentes);
. funções do standard que não apresentam boa performance (por serem genéricas) quando
utilizadas com finalidades específicas;
. áreas de aplicação diferentes (MM, FI, etc)
. desenvolvedores diferentes (foram analisados programas de diferentes pessoas).

. Programas selecionados : ZAFIB001 - Conversão

ZACII001 - Include do programa anterior

ZAFII001 - Interface para lançamentos contábeis

ZAPPR001 - Relatório de confirmação da ordem de
Processo
ZAPPR002 - Listagem do cadastro de material
ZAMMI001 - Interface para movimento de materiais
M. BAYMAP
ZAMMI002 - Interface para livros fiscais
ZAMMI003 - Interfaces para pedidos de compras
ZAMMI010 - Interface para movimento de materiais
M. BAYMAP
ZAMMI020 - Interface para livros fiscais
ZAMMI030 - Interfaces para pedidos de compras
ZAPPI001 - Interface para produção de materiais

Obs.: Dos programas relacionados anteriormente, apenas os programas ZAPPR001 e 002 tinham
status concluído. Todos os programas foram analisados a partir de versões existentes no ambiente
de desenvolvimento da ABC.

Quanto à confecção de especificação funcional/técnica:

2. O correto seria existir uma especificação técnica com o intuito de servir como base para o
desenvolvedor. Todavia, devido ao aumento do número de programas a serem desenvolvidos
(entre programas novos e programas para correção de cargas já realizadas/programas para
auxiliar na conferência, problemas com o ambiente R/3 que tem apresentado short dumps em
transações standard) tal documentação ficará pronta apenas ao término dos
desenvolvimentos. Esta situação não é a ideal. Todavia, se torna indispensável a sua
confecção visando facilitar manutenções futuras. O coordenador do projeto está realizando um
levantamento junto à equipe funcional e fornecendo as informações necessárias para que os
desenvolvedores ABAP possam realizar suas atividades.

Quanto à documentação do projeto (cronogramas, relatórios de controle e

acompanhamento):

1. Estes documentos não estão sofrendo atualização

Quanto ao esquema de testes:

3. É de extrema importância que, além dos testes individuais, sejam realizados testes com massa
de dados real de produção, visando reproduzir um ambiente real durante a fase de execução
das interfaces, com o objetivo de minimizar/eliminar problemas com performance. Na ABC não
estão sendo feitos testes com alto volume de dados. Isso acaba mascarando problemas que
podem vir a ocorrer no futuro, caso haja um aumento significativo nos dados;

4. Os testes devem englobar todas as condições lógicas possíveis, e até mesmo condições de
erro. Não existe esquema de “stress-test” (com grande volume de dados). A massa de dados
não deve ser gerado pelos desenvolvedores nesta etapa de testes finais, pré-produção.

Quanto à uniformidade do código e ao uso da metodologia (padrões) definidos na Fase

II:

Foi estabelecido na fase II de QA que a metodologia e padrões seriam adotados do parceiro de

implementação.

4. Na amostragem analisada foi constatado que o manual de Padrões não foi seguido de forma
íntegra. Algumas das diferenças são demonstradas abaixo

. nome de programa: no manual estava estabelecido que a composição seria: Z23456789,

onde Z = fixo, 2 e 3 = ao módulo SAP (FI, MM, PP, etc), 4 a 6 = gap de origem, 7 = B (batch-input)
ou I (interface) ou R (relatório) ou S (Sapscript), 8 e 9 = número sequencial referente ao gap. Na
verdade, os programas desenvolvidos não estão obedecendo este padrão;

. classes de desenvolvimento: de fato, obedeceu a estrutura definida anteriormente, ou

seja, uma por módulo. Todavia, existem programas que não estão na sua classe de
desenvolvimento correta (exemplo, programa de FI na classe de MM);
 . nome de variáveis: notamos que a atribuição de nomes para tabelas internas, parameters,
select-options, constants e types nem sempre estiveram padronizadas entre os programas. Este
item é importante, na medida que facilita a leitura dos programas e futuras manutenções por
terceiros ou até mesmo pela equipe técnica da ABC;

. existem forms sem nenhum conteúdo sendo chamados pelos programas;

. existem variáveis definidas que não estão sendo utilizadas;
. certificar-se que tabelas definidas com cláusula occurs de forma fixa não irão
estourar.

Quanto a performance dos programas:

2. Dentro da amostra selecionada foram encontrados erros que se repetiam. São eles:

f) Ninhos de select
g) Select * ao invés de select com suas respectivas colunas
h) Falta de mais condições na cláusula where para limitar o números de registros retornados
através do comando Select
i) Tabelas como BKPF, BSEG, EKKO, EKPO, VBAK, VBAB, MKPF, MSEG, J_1BNFDOC,
J_1BNFLIN devem possuir tantos campos quanto possível para restringir a pesquisa e busca
de dados

Devido à estrutura cliente servidor, resultados melhores de performance estarão sendo

alcançados toda vez que a comunicação entre o servidor de aplicação e o servidor de banco de
dados for minimizado.

Em vários casos encontramos selects em tabelas grandes, como por exemplo, a BSEG, trazendo-
se todos os registros que atendessem a uma única condição. É de extrema importância que, em
casos de tabelas grandes (tanto em termos de volume quanto em termos de quantidade de
colunas) sejam recuperadas apenas as informações necessárias ao atendimento do propósito do
programa (colunas e condições). Deve-se lembrar que, com o passar do tempo, a quantidade de
dados presentes nestas tabelas estará crescendo; em contrapartida, haverá uma redução da
performance caso o programa não esteja fazendo seleções adequadas. Uma forma de se obter
maior seleção é inserindo um delimitador do tipo DATA, campos que estejam presentes não
somente na tabela acessada mas também na próxima que se deseja acessar, etc.

Num outro programa existe um ninho de Selects em três níveis. Para cada registro da tabela
J_1BNFDOC é feito um ou mais acessos na tabela J_1BNFLIN e um ou mais acessos na tabela
J_1BNFSTX. Ninhos como este, com o crescimento na base de dados, trará resultados
desfavoráveis à performance. Esta mesma situação se repete em outros programas.

Além das precauções anteriores, as quais devem ser sempre tomadas, vale a pena mencionar que
o uso de tabelas internas agiliza muito o processamento. Selects que, num único comando, seja
responsável por acessar a tabela, fazer a seleção do range de dados necessário, movimentar
estes dados para uma tabela interna e gravar estes dados terão performance superior à uma
situação de Select … endselect e infinitamente superior a uma situação de Select … endselect
em ninho.

Ilustrando situação semelhante, com grandes tabelas do sistema, temos:

Select * from bkpf where condition = ‘XXXX’.

Select * from bseg where bukrs = bkpf-bukrs and

belnr = bkpf-belnr and
gjahr = bkpf-gjahr.
Endselect.

Endselect.

* O primeiro comando seleciona as 79 colunas da tabela bkpf através do campo <condition> que
é um critério muito amplo para pesquisa em tabelas deste porte. Campos como company code,
data, ano fiscal, entre outros, podem ser fortes candidados a restringir a pesquisa.

* O segundo comando seleciona as 266 colunas da tabela bseg, onde os campos bukrs, belnr e
gjahr sejam iguais à tabela anterior. Como na tabela anterior não foi utilizado um critério de
seleção mais adequado, muitos registros serão retornados da bkpf e, consequentemente, para
cada um destes registros, serão retornados “n” registros da BSEG.

* Ambos os selects corresponderão a tantos acessos no banco de dados quantos registros

existirem.

Visando garantir melhor performance, poder-se-ia utilizar:

Select col1 col2 col3, … into table tab_bkpf from bkpf where <conditions>.

Select col1 col2 col3 col4 into table tab_bseg

from bseg
for all entries in tab_bkpf
where < conditions >.

Algumas considerações:

* Ambos os selects corresponderão a um único acesso no banco de dados.

* O primeiro comando select já seleciona, move e grava os dados numa tabela interna.
* O segundo select será baseado no resultado, já em tabela interna, do primeiro select.
* São selecionadas apenas as colunas realmente necessárias. Assim, os pacotes transmitidos
entre o servidor de banco de dados e o servidor de aplicação são menores, agilizando portanto a
transferência.
* tab_bkpf e tab_bseg são tabelas internas.

Exemplificando através de um trecho do programa ZAFII001:

Select mblnr bldat budat into table tab01

From bkpf where budat in s_budat

Loop at tab01.
Select * from bseg where mblnr eq tab01-mblnr.
Move-corresponding tab01 to tab02.
Move-corresponding mseg to tab02.
Append tab02. Clear tab02.
Endselect.
Endloop.

O primeiro select faz um único acesso ao servidor de banco de dados, trazendo todos os dados
necessários de uma única vez. (OK)

O select * na tabela bseg está dentro de um loop. Ou seja, este comando estará trazendo todas as
colunas desta tabela, que é uma das maiores do sistema R/3. Será movimentado através do
comando move-corresponding os campos cujos nomes sejam semelhantes de tab01 e mseg. Este
comando não oferece boa performance (gasta tempo identificando a igualdade no nome dos
campos).

Alternativa: O loop na tab01 indica que, para cada registro da tab01 (tabela interna), será
acessado um registro na bseg. Então, seria melhor proceder conforme abaixo:

Select mblnr bldat budat into table tab01 from bkpf where <conditions>.

Select col1 col2 col3 col4 into table tab_bseg (*)

from bseg
for all entries in tab01
where < conditions >.

Ou seja, evitar select * trazendo somente os campos necessários e fazer um único acesso à
tabela BSEG, trazendo todos os registros importantes para o processamento. Colocar também
mais seleções, objetivando restringir a quantidade de dados trazidos no primeiro select para,
consequentemente, restringir a quantidade de dados trazidos no segundo select. Pode-se pensar
em trazer todos os dados da BSEG para a própria tab01, através de appending corresponding
fields os table …. .
Ver help online para maiores detalhes sobre os comandos, em caso de dúvidas.

Este recurso de “for all entries” baseado na tabela anterior pode ser usado sempre, principalmente
nos casos onde performance for um fator crítico. Normalmente, os casos de selects encadeados
em forma de ninhos podem usar tal facilidade com uma incrível melhoria na performance.

Classificação dos programas pós-análise:

Exemplos de programas que encontram-se na situação de ninhos de select: ZAMMI020,

ZAMMI030, ZAMMI002, ZAMMI003.

Exemplos de programas que encontram-se na situação de vários acessos entre o servidor de

aplicação e o servidor de banco de dados: ZAMMI010.

Exemplos de programas que selecionam todas as colunas das tabelas acessadas: ZAFII001,
ZAMMI002, ZAMMI003.

Exemplos de programas que não acessam, selecionam, movimentam e gravam num único
comando select: ZAFII001.

Necessidades:

c) Stress-test
d) Testes integrados
Comentários/Recomendações:

O ponto mais crítico está associado ao tópico de performance. É necessário fazer revisão em
todos os programas, visando detectar situações semelhantes à descrita anteriormente e
providenciar as adequações necessárias.

Outro ponto de fundamental importância se refere aos testes. A garantia do bom funcionamento do
programa e a minimização de problemas com performance após entrada em produção somente
ocorrerá caso seja realizado testes com massa de dados real, ou seja, volumes próximos ao
esperado em ambiente produtivo, cobrindo as situações que possam ocorrer.

Restrições:

Caso ocorra a entrada em produção sem a alterações nos programas, a performance será
decrescente, à medida que as bases de dados forem crescendo. Também não se pode garantir
que todas as interfaces pseudo-online serão processadas e finalizadas dentro do tempo
estipulado (por exemplo, a cada “x” minutos, etc).

A documentação dos programas deverá ser providenciada, mesmo que após entrada em
produção, visando facilitar trabalhos de manutenções futuras.

Testes com massas de dados real ou com alto volume de dados eliminam/minimizam os problemas
com performance. A entrada em produção, na maioria dos casos, não é comprometida. Porém,
após alguns meses, pode-se ter um decréscimo significativo na performance.

O atraso no cronograma deveu-se ao aumento do número de desenvolvimentos, à problemas com

o ambiente R/3 da ABC, que apresentava short dump em transações online, o que impossibilitava
configurações, entrada de dados para testes, etc. Outro ponto que trouxe dificuldades para a
equipe ABAP do parceiro de implementação foi a inexistência de formulários (Sapscripts) da
localização no ambiente que eles estavam utilizando, sendo necessário desenvolvê-los a partir
de cópia de outros clientes. Principalmente devido ao problema de dumps em transações
standard, a equipe de ABAP foi inúmeras vezes interrompida para auxiliar os funcionais, tentando
“driblar” o problema, para que o projeto sofresse “menor impacto”.

Obteve-se a informação que o material de Quality Assurance da Fase II apenas foi entregue à
equipe de desenvolvimento ABAP a cerca de uma semana atrás. Vale ressaltar que este material é
altamente técnico, e basicamente voltado à equipe do projeto ABAP. O fato da equipe não ter feito
a leitura deste material desde o início do projeto traz alguns pontos negativos. Estes só não foram
maiores dada a experiência da equipe em outros projetos. Mesmo assim, certas irregularidades
poderiam ter sido evitadas.
Parecer:

De uma forma geral pode-se dizer que o desenvovimento está bom, porém caso os programas
não sejam revisados e adequados, certamente ocorrerão problemas de performance após a
implantação.
Um ponto positivo é que todos os programas possuem lógica simples e fácil para manutenções
futuras, se houver necessidade.
 3 . QUADRO RESUMO DA SITUAÇÃO DO PROJETO

Tópico Status
Confecção de especificação técnica 2.
V

Esquema de testes Não validado.

São necessários testes com
alto volume de dados.
Uniformidade do código-metodologia- Validado com restrições.
padrões
Performance Validado com restrições,
desde que os programas
sejam revisados e alterados
no que se refere à questões
de performance. Ponto
fundamental e indispensável
para correção antes da
entrada em produção.
Outros erros Não se aplica

Observação:

Valerá muito pouco todo este trabalho se a configuração da máquina não estiver correta. É
necessário que ocorra uma visita de basis se o problema de performance não está num
programa em específico, mas em vários.