abap apostila de treinamento

Treinamento ABAP para Funcionais

Instrutor: Leonardo Lima Coelho Página 1 de 28

ABAP para funcionais Parte I

Objetivo deste treinamento é oferecer mais recursos para o corpo de funcionais para que

eles possam construir uma melhor especificação funcional e tenham uma noção geral do

funcionamento da linguagem ABAP/4.

Sumário

1. Estrutura de funcionamento do SAP ........................................................................ 2 1.1. Como funciona a estrutura de 3 camadas do SAP........................................ 2 1.1.1. Estrutura ................................................................................................... 2 1.1.2. Work Process............................................................................................ 3 1.1.3. Vantagens da estrutura de 3 camadas no SAP.......................................... 3 1.1.4. Desvantagens da estrutura de 3 camadas no SAP. ................................... 3 1.2. Estrutura de dados do SAP........................................................................... 4 1.2.1. Domínio:................................................................................................... 4 1.2.2. Elemento de dados:................................................................................... 6 1.2.3. Tabelas:..................................................................................................... 7 1.2.4. Estruturas:............................................................................................... 14 1.2.5. Visões: .................................................................................................... 15 1.2.6. Ajudas de Pesquisa: ................................................................................ 16 1.2.7. Dicas Importantes:.................................................................................. 18 1.2.7.1 Tabelas:................................................................................................... 18 1.2.7.2 Índices: ................................................................................................... 19

2. Programação ........................................................................................................... 20 2.1. Tipo de programas.......................................................................................... 20 2.1.1. Online ......................................................................................................... 20 2.1.2. Reports........................................................................................................ 22 2.1.3. Funções e Grupo de Funções...................................................................... 23 2.1.4. Formulários de Impressão (SapScript e SmartForms)................................ 25 2.2. Tipos de processamento.................................................................................. 25 2.2.1. Processamento em Foreground................................................................... 25 2.2.2. Processamento em BackGround................................................................. 26



1. Estrutura de funcionamento do SAP

1.1. Como funciona a estrutura de 3 camadas do SAP.

1.1.1. Estrutura

Um sistema SAP R/3 é composto por três camadas:

• Frontend

• Application

• Database

Frontend é camada responsável por "exibir" as telas ao usuário.

Application é onde são processadas as operações efetuadas, transferindo

para o Frontend, os dados a serem exibidos. É nessa camada que os programas ABAP

são executados.

A camada de Application possui diversos serviços e processos (também

chamados de Work Process) disponíveis.

O desenho típico de uma instância SAP é um servidor de Banco de Dados com

um ou mais servidores de Application. Isso garante a integridade dos dados, e permite

uma distribuição de carga nos servidores de aplicativo entre os usuários.

Segue o exemplo da arquitetura em 3 camadas no desenho abaixo:



1.1.2. Work Process

1. Message: Serviço interno responsável pela comunicação entre as instâncias.

2. Dispatcher: Serviço interno responsável pelo "despacho" das requisições para

cada processo ou serviço.

3. Gateway: Garante a comunicação externa com outros sistemas

4. Enqueue: Processo responsável pelo gerenciamento da tabela de objetos de

bloqueio.

5. Dialog: Processo responsável pela execução dos processos visíveis pelo usuário.

6. Update: Processo responsável pela atualização dos dados no banco de dados.

7. Spool: Processo que gerencia a fila de impressão.

Database é a camada onde os dados são armazenados, quando a camada

Application necessita de algum dado, o mesmo é requisitado a camada de Database.

1.1.3. Vantagens da estrutura de 3 camadas no SAP

• Como o acesso é feito à somente um banco de dados a integridade de dados

é garantida pela vantagem do SAP utilizar o sistema de Enqueue e Dequeue. Isto

garante que não podemos alterar um registro que está sendo alterado por outra pessoa.

• A maior parte dos SAP´s possuem um servidor de logon balance para que ao

efetuarmos o login no sistema sejamos direcionados para o servidor que está mais

ansioso. Isto garante um melhor desempenho do sistema.

• Necessidade de um componente de cliente de pouca complexidade já que o

processamento de regra de negócio efetuado pelo servidor de aplicação. Isto garante um

bom desempenho de um aplicativo independente da máquina do cliente.

• O banco de dados pode variar de acordo com a necessidade do cliente

• O sistema de dados do servidor de aplicação pode variar de acordo com a

necessidade do cliente.

1.1.4. Desvantagens da estrutura de 3 camadas no SAP.

• Tudo que acessamos no SAP está diretamente vinculado com o banco de

dados, ou seja, se o banco de dados “cair” o SAP cai também. A fila de enqueue é finita



e pode acontecer por um erro de programação ou de procedimento desta fila estourar e

por isso nenhum registro no sistema será atualizado. Por isso é importante seguir as

recomendações da SAP com relação a configuração de tempo de time out e não realizar

batch-input em transações de origem da sm30.

• Às vezes nós não temos acesso ao DNS do cliente para efetuarmos acesso no

servidor de logon balance e por isso usamos o IP fixo da máquina de acesso. Isto não é

problema em ambientes de desenvolvimento ou QA, pois geralmente se tem apenas um

servidor de aplicação. Mas quando acessamos um ambiente produtivo devemos nos

logar na máquina mais livre de processamento, pois podemos acessar o servidor com

mais processamento indevidamente.

• Necessidade de um componente de cliente de pouca complexidade já que o

processamento de regra de negócio efetuado pelo servidor de aplicação. Isto garante um

bom desempenho de um aplicativo independente da máquina do cliente.

1.2. Estrutura de dados do SAP

1.2.1. Domínio: O domínio é a estrutura mais baixa que temos permissão de alterar. Um domínio

se associar a um ou mais elementos de dados. No domínio configuramos qual é o tipo

do dado como mostra a figura abaixo:



Caso o campo seja de um tipo numérico podemos definir o número de casas

decimais armazenados.

Alguns campos possuem rotinas de conversão que são definidas também no

domínio. As rotinas de conversão permitem que uns campos sejam armazenados de uma

forma e mostrados de outra forma.

Alguns domínios podem conter valores fixos e somente os valores listados no

domínio serão aceitos na tabela, como o exemplo mostrado na figura abaixo:

Existe também a possibilidade de restringir os dados por intervalo ou por

verificação de uma tabela.

A transação de exibição de domínio é a SE11.



1.2.2. Elemento de dados:

Os elementos de dados se associam diretamente com os campos das tabelas.

Somente um domínio pode estar associado a um elemento de dados, mas um elemento

de dados pode estar associado a diversas tabelas. O elemento de dados pode ter um tipo

fixo sem associação a um domínio. A figura abaixo mostra a tela de associação de um

elemento de dados com um domínio.

A transação de exibição de elemento de dados é a SE11.



1.2.3. Tabelas:

As tabelas são estruturas de dados que armazenam registros. As tabelas podem

ter associadas a elas diversos elementos de dados ou podem ser informados tipos fixos

sem elemento de dados. Sendo que a associação de um campo a um elemento de dados

é o mais recomendável.

As tabelas podem ser de dependentes de mandante ou não. Geralmente as tabelas

dependentes de mandante são tabelas de configuração de aplicativos do SAP, por

exemplo algumas tabela de archiving. A maior parte das tabelas do SAP são

dependentes de mandante. Ao construir uma tabela “Z” é recomendável que ela seja

dependente de mandante. Como identificar uma tabela dependente de mandante? Basta

verificar qual é o primeiro campo. A tabela na figura abaixo é dependente de mandante.

A tabela na figura abaixo não é dependente de mandante.

Os tipos mais comuns de classe de entrega de tabelas são: Tabelas de Aplicação

(Dados mestre e movimentos) e Tabelas de customizing. Pode-se definir uma tabela “Z”



como customizing e ela somente será atualizada mediante o informe de uma request

customizing, como acontece com as tabelas standard.

É necessário que toda tabela tenha uma chave primária. A chave primária é o

que garante a identificação de um único registro da tabela. Os campos que definem a

chave primária não podem se repetir. Os campos da chave primária podem ser

identificados em uma tabela do SAP como os campos que estão marcados com o flag de

“chave”. Nas tabelas dependentes de mandantes estes são obrigatórios como parte da

chave da tabela. Uma busca pela chave da tabela é sempre uma busca mais rápida do

que uma busca realizada por campos não chaves, a não ser que esses campos sejam

índices.

Índices são estruturas de busca para facilitar o acesso aos registros de uma

tabela. O índice se torna necessário quando muitos acessos são executados em uma

tabela com uma grande quantidade de registros e a busca é feita por campos que não são

chaves. Para identificar quais índices estão criados para uma tabela basta clicar no botão

“Índices” no canto superior esquerdo, como mostra a figura abaixo.

Uma tela com todos os índices da tabela será exibida, como mostra a figura

abaixo.



Com um duplo clique você pode visualizar o detalhe do índice, como mostra a

figura abaixo.

A chave estrangeira é uma importante funcionalidade dentro de uma tabela. Para

que o um registro seja inserido em uma tabela ele já deve existir em outra tabela

definida na chave estrangeira. Para verificar as chaves estrangeiras de uma tabela basta

clicar na aba e verificar quais campos possuem

preenchidos a coluna . Para verificar quais os parâmetros da chave

estrangeira basta selecionar o campo e clicar no botão então os detalhes da chave

estrangeira serão visualizados como mostra a figura abaixo.



A figura acima mostra que quando o campo “VBELN” for preenchido na tabela

VBAK ele já deve existir na tabela “VBUK”.

Caso você deseje visualizar todas as dependências da sua tabela basta clicar no

botão e selecionar quais tabelas que você quer visualizar, como mostra a figura

abaixo.



Depois clicando em aceitar você consegue ver o desenho do relacionamento.

Como mostra a figura abaixo.

No botão são exibidas algumas informações técnicas a

respeito da tabela que são definidas pelo programador que a construiu. Como mostra a

figura abaixo.



O parâmetro mais importante desta tela para o público alvo deste curso é o

check-box , pois se este check-box estiver

marcado nós poderemos visualizar todas as alterações executadas nesta tabela através da

transação SCU3, com informações importantes como usuário que realizou a alteração,

data da alteração e o valor do campo antes e depois. Não é recomendada a utilização

deste recurso de armazenamento de log em tabelas que não sejam de configuração, pois

o banco de dados pode crescer absurdamente se este flag for marcado em uma tabela de

movimento. Para que a visualização do log esteja disponível para uma tabela “Z” é

necessário também executar uma visão de atualização através do “Gerador de

atualização de tabela” que está disponível dentro do menu de utilitários na transação de

visualização da tabela. Cuidado , pois ao habilitar o “Gerador de atualização de tabelas”

você também estará disponibilizando o registro para ser atualizado via a transação

SM30.A figura abaixo mostra um gerador de atualização de tabelas.



É possível também anexar em uma tabela uma estrutura. Denominamos uma

estrutura que está anexada em uma tabela de uma Estrutura de Append. Este recurso é

muito utilizado para anexar estruturas “Z´s” em tabelas standard. A figura abaixo

mostra três estruturas de append na tabela VBAK.

Dados de uma estrutura de append:



1.2.4. Estruturas:

Estruturas não são repositórios de dados e são utilizadas para interface de telas

de programas, para modelo de passagem de parâmetros ou como estrutura de append

como foi mostrado no tópico anterior. A estrutura de append não armazena dados e por

isso não possui chave primária e índices. A figura abaixo mostra uma estrutura:



1.2.5. Visões:

Uma visão é uma estrutura de busca de dados que pode fazer referência a uma

ou mais tabelas. Quando uma busca é efetuada diversas vezes é melhor construir uma

visão, pois além da busca se efetuada com maior velocidade quando uma alteração for

efetuada em uma visão todos os programas que fazem referência a esta visão serão

alterados. As figuras abaixo mostram a estrutura de uma visão:



1.2.6. Ajudas de Pesquisa:

A ajuda de pesquisa é utilizada para dar uma dica para o usuário dos possíveis

valores que um campo pode assumir. A ajuda de pesquisa pode estar associada a um

campo de uma tabela ou a uma estrutura. Os dados exibidos em uma ajuda de pesquisa

podem ser oriundos de uma tabela ou de uma visão. A figura abaixo mostra o exemplo

de uma ajuda de pesquisa:



O exemplo abaixo mostra uma ajuda de pesquisa associada a um campo de uma

tabela:



1.2.7. Dicas Importantes:

1.2.7.1 Tabelas:

Ao definir uma estrutura de uma tabela tenha sempre em mente que quanto

mais curta for à estrutura da tabela mais rápida será a busca. Os campos de dados mestre

precisão ter uma chave estrangeira para a tabela principal. Como mostra o exemplo

abaixo.

A tabela exemplificada na figura abaixo mostra o que não se deve fazer:



• Não existe mandante na chave da tabela

• Para a chave da tabela foram usados campos de denominação ao invés da

chave da tabela de dados mestre.

• Não existe nenhuma chave na tabela mesmo esta fazendo referência a

campos standard.

1.2.7.2 Índices:

Antes de criar um índice para acesso de uma tabela lembre-se que um índice

ocupa espaço no banco de dados. Verifique se existe outro índice que tenha o critério

parcial de sua busca antes e pergunte ao abap se o custo da busca é alto.

Não existe necessidade de criar índices em tabelas que não terão uma quantidade

de dados razoável.



2. Programação

2.1. Tipo de programas

2.1.1. Online

A característica mais distinta de um programa online é o processamento por

telas. O processamento de uma tela possui 2 momentos distintos: PBO (Process Before

Output) e o PAI (Process After Input).

A transação VA01 chama um programa Online.

O PBO é o processamento que ocorre antes da exibição da tela conseguimos

visualizar bem o trecho de código de um PBO na figura a baixo.

O PAI é o processamento que ocorre sempre que existe uma interação do usuário

com o programa como, por exemplo, clicar um botão ou pressionar o enter. A figura

abaixo mostra o PAI a tela mostrada acima:



No programa OnLine também são definidos Status de Interface(botões) e Títulos

de Interface(Títulos das transações). Esses status são carregados no PBO.

Um bom programador ABAP no desenvolvimento de um programa Online irá

separar todos os tipos de processamento em arquivos diferentes (PBO, PAI e Performs).

Isto irá facilitar quando for necessário efetuar a manutenção do programa.

Exemplo de um status gui:

Ao criar uma transação que referencia um programa online é necessário

especificar qual é a tela inicial que é chamada. Como mostra o exemplo abaixo:



2.1.2. Reports

A característica mais distinta de um report é a utilização de uma tela de seleção.

Como é mostrado o exemplo da transação ME2L na figura abaixo.



Geralmente um report, como o nome diz, é utilizado para a execução de um

relatório. É possível colocar um report para ser executado em background e executar um

retorno de uma lista para o spool da tela, que pode ser visto posteriormente através da

transação sm37.

O retorno de um report pode ser uma tela simples ou um ALV.

2.1.3. Funções e Grupo de Funções

Uma função é um objeto de processamento que ser chamado por um programa

dentro ou fora do SAP. Ele pode ser executado imediatamente, com retardo ou quando

outro processo for iniciado.



Geralmente uma função apresenta dados de entrada e dados de saída.

Toda função deve estar associada a um grupo de funções. Um grupo de funções

pode ter uma ou mais funções associadas. Como mostra a figura abaixo.

Uma atenção extra deve ser dada quando uma alteração for efetuada em um

grupo de funções, pois se uma função do grupo de funções ficarem inválida todas as

funções do grupo ficarão. Não existe nenhuma funcionalidade do SAP que ofereça uma

função como interface para um processo de um usuário. As funções devem ser

chamadas de dentro de um report, um online ou um formulário de impressão.



2.1.4. Formulários de Impressão (SapScript e SmartForms)

Os formulários são leiautes de impressão. Geralmente são utilizados para

interfaces externas. Ao contrário dos reports que geralmente são utilizados em processos

internos. O SmartForms é independente de mandante e o SapScript não é. Tanto o

SapScript quanto o SmartForms possuem as mesmas funcionalidades, mas o smartforms

possui uma maior biblioteca de funcionalidades que são de fácil implementação,

fazendo com que o desempenho do programador ao desenvolver um projeto em

SmartForms seja melhor. O SmartForms não passa de uma interface para gerar códigos

de SapScript.

2.2. Tipos de processamento.

2.2.1. Processamento em Foreground

O processamento em foreground está sujeito a interação direta com o usuário.

Quando o usuário está navegando pelo SAP qualquer clique de botão ou chamada de

uma transação dispara um processo em foreground, pois em qualquer ação disparada

pelo usuário é esperada uma resposta do sistema no menor tempo possível. Na tela de

verificação de processos eles são denominados de DIA(Dialog) como mostra a figura

retirada da transação sm50.



2.2.2. Processamento em BackGround

O processamento em background está não sujeito a interação direta com o

usuário. Para executar um processo em background é necessário agendar um job . Na

tela de verificação de processos eles são denominados de BTC(batch) como mostra a

figura retirada da transação sm50.

Somente é possível escalonar Jobs de transações de reports. Para fazê-lo basta ir

até o menu “Programa� Execução background” como mostra a figura abaixo:

Em algumas empresas será pedido o dispositivo de saída como mostra a tela

abaixo:



Depois é só preencher os dados relativos ao período de execução do job. Como

mostra a tela abaixo:



Para verificar o resultado do job basta entrar na transação sm37, preencher os

critérios de seleção da transação e verificar o retorno do job.

É possível visualizar o retorno do relatório selecionando a linha do job e

clicando no botão de spool.

abap apostila de treinamento

Documents