Academia-Abap PDF

Material de treinamento – Conceitos ABAP
Academia ABAP – 2006 – PROCWORK Software.

Material de apoio – Conceitos resumidos - Instrutor: Luís Fernando Aguiar
da Rocha.
ÍNDICE:
INTRODUÇÃO:........................................................................................................................... 3
SOBRE ESSA APOSTILA:........................................................................................................ 6
DIAMANTE:................................................................................................................................. 6
R3 COMO UM SISTEMA ABERTO À COMUNICAÇÃO: ....................................................... 6
ARQUITETURA: ......................................................................................................................... 7
O MIDDLEWARE BASIS: .......................................................................................................... 9
SAP ON LINE SERVICE SYSTEM: ........................................................................................ 10
CONCEITO DE MANDANTE:.................................................................................................. 10
CHANGE REQUEST:............................................................................................................... 11
UNIDADES LÓGICAS COM SEUS MANDANTES -> DESENHO. ...................................... 12
OBJETOS ‘Z’ E ‘Y’: .................................................................................................................. 13
CLASSE DE DESENVOLVIMENTO OU PACOTE: .............................................................. 13
PROGRAMAS STANDARD DO SAP:.................................................................................... 13
FIELD EXITS ............................................................................................................................. 13
SCREEN EXIT........................................................................................................................... 17
USER-EXIT................................................................................................................................ 17
TRANSAÇÕES IMPORTANTES AO DESENVOLVIMENTO: ............................................. 18
ENTRADAS POSSÍVEIS NO CAMPO DE COMANDO: ....................................................... 18
TELAS DE SELEÇÃO:............................................................................................................. 19
PARAMETER:........................................................................................................................... 20
DECLARAÇÃO DE VARIÁVEIS: ............................................................................................ 22
CATEGORIA SIGNIFICADO ADEQUADO PARA ........................................................................ 23
MENSAGENS: .......................................................................................................................... 24
TRANSAÇÃO: .......................................................................................................................... 25
DEBUGGER:............................................................................................................................. 26
TIPOS DE TABELAS: .............................................................................................................. 27
DICIONÁRIO (DDIC). ............................................................................................................... 28
ATUALIZADOR DE TABELA.................................................................................................. 30
TABELA INTERNA................................................................................................................... 32
HEADER LINE .......................................................................................................................... 32
MODULARIZAÇÃO:................................................................................................................. 36
COMANDO WRITE: ................................................................................................................. 37
TABELA SYST: ........................................................................................................................ 37
COMMIT WORK/ROOLBACK WORK: .................................................................................. 38
LOOP – ENDLOOP: ................................................................................................................. 40
IF, ELSE, ENDIF: ...................................................................................................................... 41
CASE: ........................................................................................................................................ 42
INSERT. ..................................................................................................................................... 42
SORT. ........................................................................................................................................ 43
MODIFY. .................................................................................................................................... 44
1
DELETE..................................................................................................................................... 44
CLEAR:...................................................................................................................................... 44
INCLUDE :................................................................................................................................. 45
UPDATE: ................................................................................................................................... 47
CONCATENATE: ..................................................................................................................... 47
WS_UPLOAD E WS_DOWNLOAD: ....................................................................................... 48
WORK ÁREA: ........................................................................................................................... 49
SELECT:.................................................................................................................................... 50
SELECT <RESULT> FROM <TABLES> INTO <TARGET> WHERE <CONDITION>. .................. 50
SELECT SINGLE – LEITURA DE UM ÚNICO REGISTRO. ............................................................ 50
SELECT....ENDSELECT – LEITURA DE MÚLTIPLAS LINHAS; .................................................. 50
SELECT....FROM...INTO....FOR ALL ENTRIES IN <ITAB>...WHERE....<F1> EQ <ITAB>-
<FX>........................................................................................................................................... 51
SELECT......UP TO <N> ROWS................................................................................................ 51
SELECT <T1>~<F1> <T2>~<F1> FROM <T1> INNER JOIN <T2> ON <T1>~<F3> EQ
<T2>~<FX> INTO ...WHERE... ................................................................................................. 51
SUBMIT: .................................................................................................................................... 53
EXPORT IMPORT: ................................................................................................................... 53
READ TABLE: .......................................................................................................................... 54
MODULE POOL: ...................................................................................................................... 55
CALL SCREEN:........................................................................................................................ 56
LEAVE: ...................................................................................................................................... 56
TABLE CONTROL: .................................................................................................................. 57
COLUNA DE MARCAÇÃO:..................................................................................................... 58
CRIAÇÃO DE BOTÔES EM TELA: ........................................................................................ 59
TABSTRIP:................................................................................................................................ 59
CARGAS EM BANCO DE DADOS:........................................................................................ 62
1 - DIRECT INPUT ........................................................................................................................ 62
2 - BATCH INPUT ......................................................................................................................... 62
3 – CALL TRANSACTION ............................................................................................................. 63
4 – BAPI..................................................................................................................................... 65
SAPSCRIPT:............................................................................................................................. 65
2
INTRODUÇÃO:
O que é SAP ???
Os passos iniciais para que o SAP viesse ao mundo começaram a ser dados em 1972, na
cidade de Waldorf, na Alemanha, quando cinco engenheiros, funcionários de uma multinacional ,
decidiram criar sua própria empresa de desenvolvimento de sistemas: a SAP AG. Isso mesmo,
SAP não é apenas o nome do pacote de gestão mais falado no mundo, é também o nome da
empresa que o desenvolveu.
O nome da empresa era na verdade uma acrossemia (nome formado pelas iniciais de uma
série de palavras). As iniciais SAP significam Systeme, Anwendung und Programme (Sistemas,
Aplicações e Produtos). O AG era a abreviação de Agentur, um termo em alemão que quer dizer
Sociedade Anônima.
O primeiro produto importante da nova empresa foi o SAP R/2 (Realtime System Version
2), um conjunto de módulos de software destinado a mainframes, que em 1995 ainda era utilizado
por mais de 2000 empresas.
A medida que novos conceitos iam surgindo no campo da informática, a SAP ia

atualizando seu produto, até que em 1989, as primeiras aplicações do SAP R/3 foram
apresentadas numa conferência em Hanover, Alemanha.
R/2 e R/3 não representam versões de um mesmo sistema, tratam-se na verdade de

produtos diferentes. O R/2 era um conjunto de módulos de software destinado a mainframes,
enquanto o R/3 foi desenvolvido para o ambiente cliente/servidor (ambiente em que algumas
estações solicitam serviços, os clientes, e outras, os servidores, atendem, realizando determinados
tipos de processamento ou compartilhando recursos como impressoras, arquivos e bancos de
dados).
Os Principais Módulos do SAP R/3 (Copyright by SAP AG).
O SAP R/3 é um sistema que oferece um conjunto de módulos com diversas aplicações de
negócio. Os módulos são integrados e contém a maior parte das funcionalidades necessárias às
grandes corporações , incluindo manufatura, finanças, vendas e distribuição e recursos humanos.
Cada módulo é responsável por mais de 1000 processos de negócio, cada um deles baseado em
práticas consagradas no mundo dos negócios. A configurabilidade do sistema é tornada possível
por 8000 tabelas que administram desde a estrutura corporativa até a política de desconto
3
oferecida aos clientes. O sistema oferece o processamento de informações em verdadeiro tempo

real ao longo da empresa onde estiver implementado. Não é a toa que o sistema é um best-seller.
como provam os números a seguir. Em 1995, a SAP AG tinha mais de 6600 colaboradores ao
redor do mundo. Neste mesmo ano, a SAP liderava o mercado de softwares para ambiente
cliente/servidor. Além disso a SAP ocupava a quinta posição no ranking das empresas de software.
Hoje mais de 4000 empresas possuem o produto da SAP implementado. Um dos motivos do
sucesso da SAP é o montante investido em pesquisa e desenvolvimento e as alianças estratégicas
que forma com outros desenvolvedores de sistemas. Estes parceiros criam add-ons (programas
complementares) que suprem algumas deficiências do R/3. Este tipo de união permite que a SAP
foque seus esforços no seu principal produto.
Em 1995 o SAP chegou ao Brasil, mas para que pudesse ser utilizado no nosso pais ele
passou por um processo chamado de customização, que nada mais é que a alteração do sistema
de modo a atender a legislação fiscal brasileira .
Quando o SAP chegou ao Brasil com força total em 1991 as empresas de consultoria já
sabiam que esta ferramenta seria um ótimo instrumento para aumentar suas receitas. Sendo
assim, um ano antes elas começaram a montar a infraestrutura necessária para implementar o
pacote no Brasil. Gerentes mais experientes eram enviados ao exterior para saber como os
departamentos dedicados a implementação do SAP eram estruturados fora do país. Outro objetivo
destas viagens era conhecer a metodologia de implementação e as ferramentas utilizadas em
locais onde a experiência com o sistema fosse maior. Além disso os escolhidos para estas tarefas
passavam por cursos onde eram introduzidos ao pacote de gestão que estava para invadir o
mundo corporativo brasileiro.
Mas os preparativos para a chegada do SAP ao Brasil não envolviam apenas os gerentes
das chamadas "Big Six", havia um enorme trabalho de bastidores, deixado a cargo dos sócios
destas empresas. O resultado seria a formação de um sistema de parceria entre a SAP e as
empresas de consultoria segundo o qual o foco da SAP seria a venda do sistema, deixando a
implementação na mão de seus parceiros.
Com as práticas de SAP devidamente estruturadas, do ponto de vista organizacional ,

restava apenas uma questão: quem iria por a mão na massa e implementar realmente o sistema
nos clientes, uma vez que a princípio apenas uns poucos gerentes haviam tido treinamento formal
nos assuntos relativos ao SAP e como todos sabemos nunca foi atribuição de um gerente sentar
na frente de uma de micro-computador e configurar um pacote de gestão, tendo em mente que seu
papel em projetos é muito mais estratégico do que prático.
A resposta a esta questão era relativamente simples: as grandes consultorias possuiam um

contingente de especialistas em outros pacotes de gestão como por exemplo MMX (Suprimentos e
Manufatura) ou Interquadram (Financeiro). Estes consultores podiam não conhecer muito de SAP,
mas dominavam a metodologia de implementação de sistemas e conheciam processos de negócio
a fundo.
Estas pessoas foram então enviadas para os Estados Unidos, para tomar parte na tão
falada academia de SAP. O que era a Academia de SAP ? Era um curso de 5 semanas onde os
profissionais aprendiam como configurar o sistema e como executar uma série de transações. Os
especialistas em Interquadram faziam, em sua maioria, o curso do módulo FI/CO. Os entendidos
em MMX faziam academia de MM ou PP. Ao fim das cinco semanas de curso os participantes
deviam fazer um estudo de caso e uma prova. Para receber o certificado de implementador, o
aluno deveria ter aproveitamento de 70%. Ao voltar da academia os profissionais eram
imediatamente alocados em projetos.
4
Para enfrentar os problemas mais complexos de configuração as consultorias traziam

especialistas estrangeiros. Às vezes muitos brasileiros que trabalhavam no exterior com SAP há
algum tempo eram contratados a peso de ouro pelas grandes empresas.
Como a demanda por especialistas era maior que a oferta, as consultorias iniciaram
grandes processos de contratação. Avalanches de curriculum chegavam aos escritórios. Entre os
remetentes havia até mesmo enfermeiros . Os envelopes eram distribuídos em 4 pilhas:
- Pessoas com experiência em SAP,
- Pessoas com experiência em implementação de pacotes,
- Pessoas com conhecimento de Inglês e
- Demais
As consultorias realmente não exigiam experiência com SAP, pois o processo de formação
dos contratados seria financiado por elas mesmas. Cabe ressaltar que apenas empregados de
empresas de consultoria podiam tomar parte na academia. Em resumo os participantes eram
escritos no curso por seus empregadores.
Ao término da academia os formandos eram disputados imediatamente por todas as

consultorias num processo não muito ético. Para moralizar a situação as consultorias fizeram um
acordo de cavalheiros segundo o qual elas não poderiam roubar profissionais umas das outras.
E assim o mercado do SAP foi crescendo. À medida que mais e mais empresas utilizavam
o sistema, eram formados mais profissionais de implementação de SAP. Muitos funcionários de
empresas que passaram por implementações acabaram indo para o mercado de consultoria.
5
SOBRE ESSA APOSTILA:
Essa é uma apostila não oficial da SAP do módulo de ABAP 4 (linguagem

de programação do SAP/R3) que se destina a pessoas com experiência em
programação linear, análise estruturada e estrutura de dados.
O objetivo dessa apostila é mostrar de forma simples alguns do vários

comandos, sintaxes e técnica de programação utilizando ABAP 4. Vale ressaltar
que o material foi feito utilizando a língua portuguesa e não apresenta todo o
conteúdo de sintaxes e técnicas de programação, se tornando assim apenas
referência para o auto-estudo e gestão de uma academia ABAP 4.
A utilização das apostilas oficiais da SAP se torna, como sempre foi,

material fundamental para o estudo e aprendizagem da linguagem bem como para
a prova de certificação da SAP.
DIAMANTE:
SAP/R3 é um sistema que pode agregar diversos módulos que por sua vez
possuem diversas funcionalidades, todas integradas seguindo o conceito de
tabelas relacionais.
O R/3 segue o princípio administrativo conhecido como DIAMANTE onde

diversos módulos separados entre si podem ser acoplados dentro de um mesmo
conceito definido por sistema, onde todos esses módulos podem enxergar e
conversar entre si, garantindo integridade e integração entre todos os módulos.
R3 COMO UM SISTEMA ABERTO À COMUNICAÇÃO:
O R/3 utiliza protocolos Standard da indústria para garantir integração com

outras aplicações:
• TCP/IP: é o protocolo de comunicação difundido mundialmenmte.

• EDI: Eletronic Data Interchange , é o mecanismo utilizado para trocar
informações de negócio com diferentes sistemas; muito utilizados por
bancos.
• OLE: Object Linking and Embendding: integra aplicações PC com o R/3
(padrão Microsoft).
• Open Interfaces: Arquivamento ótico, dispositivo de código de barras,
etc.
6
Além dos protocolos Standard da indústria o R/3 também utiliza:
• RFC: Remote Function Call, que utiliza o protocolo copiado do CPI-C da

IBM para comunicação e processamento das aplicações e tasks dentro
do sistema R/3 ou com o sistema R/2 ou outros sistemas.
• ALE: Application Link Enabling permite o processamento distribuído
dentro do R/3. Na prática está associado a distribuição de informações a
partir de um modelo de divulgação pré-estabelecido.
ARQUITETURA:
O R/3 possui uma arquitetura modular de software seguindo o princípio da

arquitetura
cliente/servidor com enfoque na distribuição da força de processamento entre as
várias pataformas envolvidas.
Esta arquitetura permite que se separe a lógica da aplicação da base de

dados e da camada de apresentação. Esta configuração permite ainda otimizar os
custos e distribuir a carga através de configurações variadas de hardware. Com
isto é possível dimensionar os servidores de acordo com a carga, permitindo a
fácil escalabilidade do ambiente.
Os ganhos nesta arquitetura na implementação R/3 são muitos:

• Simples instalação de novos servidores para eliminar eventuais gargalos
de processamento;
• Servidores trabalham em paralelo, com carga homogênea e execução
local dos programas;
• Baixo tráfego de rede com a localização dos buffers de dados e
programas;
• Balanceamento de carga, seja para o processamento online (logon) seja
para o processamento batch.
Ou seja, o ponto alto da arquitetura é a facilidade para escalar e

aumentar o poder de
processamento.
Princípios cliente/servidor
Na implementação R/3, a arquitetura client/server é orientada para o

software, e não para o
hardware como estamos acostumados a ver. Desta forma, Client é quem requisita
e utiliza o serviço.
7
Um servidor de aplicação por exemplo é server de alguns serviços das

estações clients, porém é client dos serviços fornecidos pelo servidor de banco de
dados. Ou seja, o conceito do papel de quem é o cliente e de quem é o servidor é
o que prevalece não importando quem tem mais hardware ou quem normalmente
executa a atividade.
R/3 System Client/Server Configurations
Os serviços (ou camadas) fundamentais de uma aplicação são três:

Presentation, Application e Database services e existem várias formas de se
implementar um sistema R/3, a saber :
Central, onde todos os componentes estão implementados em um mesmo

host. Esta implementação corresponde a clássica implementação mainframe e
não é comum de ser implementada;
Two-tier, onde uma camada normalmente executa as funções de

presentation usualmente um PC) e a outra camada executa os serviços de
application e database. Uma outra implementação two-tier poderia ser uma
camada executando os serviços de database e a outra composta por PCs mais
potentes que executariam as funções de presentation e application. A primeira
implementação é comum em ambientes pequenos e com pouca disponibilidade de
hardware para os servidores. A última implementação é normalmente utilizada em
simulações ou desenvolvimento de software.
Three-tier, onde cada serviço tem o seu próprio host. Nesta configuração é
possível ainda assegurar uma divisão de carga na camada de aplicação,
garantindo que determinados hosts fiquem dedicados para aplicações específicas.
Por exemplo dedicar um host para servidor de aplicação dos usuários de MM,
ganhando com isto performance na distribuição dos serviços. A configuração
three-tier é a mais recomendada em R/3 por garantir a melhor distribuição de
carga e escalabilidade nos grandes sistemas.
Um sistema R/3 agrupa todos os componentes que estão associados com

um banco de dados. Se utilizamos uma implementação em 3 camadas, os
componentes do R/3 estarão presentes em todas as camadas da hierarquia:
Database Server, é instalado em um host central, onde todos os serviços de

bancos de dados
8
Um ou mais Application Servers conectados ao servidos de banco de dados.

Nestes servidores estarão sendo processados a lógica da aplicação, ou seja, os
programas.
 ários Presentation Servers conectados aos servidores de aplicação. Estas

V
máquinas são também chamadas de frontends ou workstations. Nestas máquinas
os usuários irão interagir com o sistema R/3 utilizando uma interface que proverá
os serviços de presentation.
O MIDDLEWARE BASIS:
O software Basis do R/3 (também chamado de middleware) roda em

diferentes plataformas e também pode ser adaptado para atender as
necessidades individuais das empresas. São vários os papel de BASIS:
· Provê o ambiente de runtime para as aplicações R/3

· Cuida da perfeita interação das aplicações com o sistema
· Define uma arquitetura estável para as melhorias do sistema
· Contém todas as ferramentas necessárias para a administração do
ambiente
· Permite a distribuição eqüitativa dos recursos e componentes do sistema
· Provê as interfaces necessárias para os sistemas descentralizados e os
produtos externos ao R/3
As principais características da tecnologia Basis são:
· É uma arquitetura voltada para a configuração client/server

· Trabalha com bancos de dados relacionais
· Possui interface gráfica com o usuário (GUI)
Basis é o responsável ainda pela integração dos aplicativos e do ABAP

workbench com o software
O profissional BASIS é em geral o ‘gerente’ do sistema, sendo responsável

ainda pelo transporte de requests, controle das rotinas de backup, coordenação da
manutenção do sistema (como aplicação de notas e hot packages).
9
SAP ON LINE SERVICE SYSTEM:
OSS é um service 24 x 7 disponibilizado pela SAP que permite acesso ao

banco de dados de Notas, que provêm soluções para problemas no sistema R/3.
Através do OSS os clientes abrem chamados ao suporte relatando problemas que
são analisados pela equipe da SAP.
Atualmente a SAP já disponibiliza esse serviço pela Internet. O OSS está

disponibilizado no site http://service.sap.comque faz parte do chamado market
place da SAP.
Como a grande maioria (quase totalidade) dos grandes sistemas o SAP/R3

também é passível de erros. Erros esses que podem e devem ser corrigidos com
a aplicação de notas.
Notas são comunicados/documentos emitidos pela SAP que relatam e

tentam corrigir erros em programas dos diversos módulos do SAP.
Através do portal SAPnet na WEB podemos procurar uma nota que pode
ser aplicada ao erro encontrado. Não existindo uma nota específica para o
problema devemos abrir uma OSS que é uma comunicação à SAP de um possível
problema no R3. Essa OSS então é analisada pelos profissionais da SAP que nos
informam qual o possível problema, qual a solução e se realmente não existir uma
nota específica a SAP trata de providenciar uma (cria uma nova nota e a divulga).
CONCEITO DE MANDANTE:
O R/3 é um sistema voltado para clients. Com este conceito é possível

controlar várias empresas em um único sistema, separando-os por client (ou
mandante). As chaves para se logar no sistema também são separadas por client.
Para efetuar um logon é preciso ter chave no client específico. Além disso o
sistema exige um password e por ser multilingüe , deve-se ainda especificar a
língua desejada no momento do logon.
Um client pode ser visto como uma entidade organizacional separada

dentro do R/3, com seus próprios dados e parâmetros específicos de
customização. Apesar dos dados serem armazenados em tabelas únicas, os
dados dos diferentes clients coexistem separados pela diferenciação do campo
MANDT que faz parte da chave da maioria das tabelas (client dependents). A
única exceção é a tabela T000 (definição dos clients do sistema) que é
independent apesar de ter como primeiro o campo MANDT.
10
Mandantes são como unidades independentes dentro de uma mesma

unidade lógica.
Geralmente temos a seguinte configuração de mandantes: Ambientes de

desenvolvimento e parametrizações funcionais em uma unidade lógica, ambiente
de qualidade e testes em outra unidade lógica e o ambiente de produção em outra
unidade lógica (esse representado por um mandante apenas).
CHANGE REQUEST:
As alterações no software R/3 podem ser divididas em cinco categorias:
· Customizing: é a configuração dos processos de negócio e funções de

menu através do IMG
· Personalization: são as mudanças globais das características das telas e

definição de valores default para determinados campos (SM3)
· Modification: são mudanças efetuadas pelo cliente no repositório de

objetos do R/3 (os SAP objects). estas alterações precisam ser cuidadosamente
avaliadas quando do upgrade de versões do sistema. A partir do release 4.5A a
SAP introduziu o Modification Assistent para auxiliar a gerenciar e automatizar
estas mudanças
· Enhancement: criação pelo cliente de objetos no repositório que são

referenciados pelos objetos standard do R/3 através de user exits. Estes
desenvolvimentos são os ideais por reduzirem as necessidades de modification
adjustments durante o processo de upgrade · Customer Development: criação
pelo cliente de objetos no repositório através do ABAP Workbench (programas,
etc.)
Uma change request é um “pacote” contendo os objetos que serão

transportados de um sistema R/3 para outro. Por exemplo, no caso de um abap
será encapsulado o source, no caso de uma configuração será encapsulado as
entradas nas tabela e sua respectiva ação (cria/deleta/altera). Uma change
request pode ser atribuida a vários usuários através do conceito de tarefa. Apesar
do nome tarefa ela não representa o que vai ser feito, ela representa a associação
da change request com o usuário e a respectiva documentação (que não é
obrigatoria) do que foi feito.
Todas as alterações efetuadas nos objetos do repositório são criadas e

mantidas através do ABAP Workbench e gravadas em change requests. As
demais alterações de customizing e personalizations são criadas e mantidas pelas
ferramentas de business engineer e também gravadas em change requests. Estes
11
mecanismos permitem que estas alterações sejam posteriormente propagadas

pelo landscape para consistência do ambiente.
O workbench organizer oferece mecanismos que permite que os change

requests sejam documentados através de uma descrição do seu propósito. Os
change requests devem ser criados por gerentes de projeto que associam os
objetos do repositório que serão trabalhados, onde permanecem lockados com
acesso permitido apenas aos desenvolvedores que foram autorizados ao
change. As alterações nos objetos do repositório são criadas como tasks
associadas ao change request e quando liberadas são transferidas como um todo
através das rotas que definem o landscape, já que a unidade de transporte é o
change request. A liberação de um change request faz com que uma nova versão
dos objetos nele contidos seja gravado no database de versões (somente no
sistema R/3 que foi utilizado para o desenvolvimento).
UNIDADES LÓGICAS COM SEUS MANDANTES -> DESENHO.
DESENVOLVIMENTO QUALIDADE PRODUÇÃO
REQUEST REQUEST
12
OBJETOS ‘Z’ E ‘Y’:
Todos os objetos não Standard do SAP começam com a letra Z ou Y,

portanto quando criamos um programa, transação ou tabela dentro do SAP
obedecemos essa nomenclatura de criação de nomes.
CLASSE DE DESENVOLVIMENTO OU PACOTE:
CADA MÓDULO POSSUI O SEU.

O conceito de classe de desenvolvimento ou pacote se refere a uma divisão
lógica criada por BASIS para instanciar diferentes módulos de aplicação do R/3,
proporcionando por exemplo que cada classe de desenvolvimento ou pacote
tenha uma rota de transporte específica.
Assim temos diversas classes de desenvolvimento dentro do R/3 que
permitem o transporte de change requests entre os diversos mandantes e
unidades lógicas. Temos inclusive uma classe de desenvolvimento local, que não
gera change requests e portanto não possui uma rota de transporte, sendo muito
utilizada para testes locais num determinado ambiente.
PROGRAMAS STANDARD DO SAP:
Não podem ser alterados. Caso haja essa necessidade a SAP disponibiliza
EXITS para codificação ABAP. Os programas STANDARD são “fechados”.
O que são exits?
Espaços ou “brechas” em que a SAP permite que coloquemos codificação.
Temos então:
FIELD EXITS – Que são exits criadas para determinado campo. Ao

trabalharmos com esses campos o SAP desvia a codificação para um espaço em
que podemos acrescentar código ABAP. As field exits são criadas conforme as
necessidades encontradas no ambiente de programação/regra de negócio.
A Field exit, permite que seja feita alguma seleção ou checagem de um

determinado campo no programa e tela desejados.
Para isso, se faz necessário, buscar o elemento de dados do campo que se

deseja fazer a field exit.
13
Para versões do R/3 até 4.5:

Ir até a transação CMOD, clicar AMPLIAÇÕES TEXTO(menu), depois
escolher Exits campo, aparecerão todas as fields existentes.
Para versões do R/3 após 4.5:

Rodar pela transação SE38 o relatório Standard RSMODPRF.
Para se criar uma nova:

1) Exit campo (menu ou relatório, dependendo da versão)
2) Criar
3) Digitar o elemento de dados - Avançar
4) Digitar o código, como uma função
5) Depois clicar no botão Atribuir progr/tela, colocando o nome do programa e
o número da tela, p/ pegar estas informações, clicar F1 e F9, no campo
desejado
6) Visualiza ou modifica o conteúdo da field, no botão Processar MF, deve-se
selecionar o elemento de dado desejado
7) Ativar a field exit
IMPORTANTE: Na field exit, você precisa pegar o valor digitado no campo

desejado, para isso existe a importação e a exportação, ou seja, as variáveis
INPUT e OUTPUT, você precisa sempre colocar OUTPUT = INPUT, para que o
valor possa voltar para tela origem.
Observação: A Field exit só funcionará, se a mesma estiver ativa.
Exemplo: Campo AUART na transação VA01
14
Elemento de dados: AUART

Programa: SAPMV45A
Tela:0101
Código desenvolvido
function field_exit_auart.
*"----------------------------------------------------------------------
*"*"Interface local:
*" IMPORTING
*" VALUE(INPUT)
*" EXPORTING
*" VALUE(OUTPUT)
*"----------------------------------------------------------------------
data: w_auart like vbak-auart.
w_auart = input.
export w_auart to memory id 'w_auart'.
output = input.
endfunction.
15
Exemplo da tela de ativação de field_exit:
Notar que temos uma listagem com:
• Elemento de dados.
• Status (ativo ou inativo).
• Programa (nome do programa específico ou global)
• Tela (número da tela do programa na qual a exit estará ativa)
• Numeração para quando tivermos a exit ativa para mias de uma tela ou
programa.
• Descrição herdada do elemento de dados.
Também é importante destacar que para cada função que for criada para a
field exit específica deveremos associar um grupo de funções. A dica é criar
um grupo de funções para cada field exit criada.
16
SCREEN EXIT – São locais em telas de transações Standard do SAP onde

podemos criar campos adicionais ou qualquer outro objeto em tela. As menu exits
são pré-definidas em determinadas telas de transações e criadas pela própria SAP
como uma maneira de inclusão de funcionalidades.
USER-EXIT – São espaços vazios que algumas transações e seus

programas possuem e são apresentadas como uma Include vazia dentro desses
programas onde nos dá a possibilidade de incluir codificação ABAP e alterar com
isso diversos procedimentos de programação executados pela
transação/programa Standard.
As User Exits foram desenvolvidas originalmente para o Módulo SD, com o

propósito de permitir ao usuário modificar o sistema sem, no entanto, modificar o
código fonte.
Consistem basicamente de sub-rotinas (rotinas FORM) em includes

especiais, criados em um Pool de Módulo ou Grupo de Função, onde chamará
essas sub-rotinas nos pontos do programa no qual será permitida alteração pelo
usuário.
Essas sub-rotinas devem satisfazer a nomenclatura: USEREXIT_<nome>.

A SAP nunca altera os includes.
Se novas User Exits são adicionadas em uma nova versão, elas são
colocadas em um novo programa include.
A chamada da sub-rotina já está implementada nos programas dos
módulos Standard (SD, MM, FI, etc.).
Normalmente, sub-rotinas desse tipo só trabalham com variáveis globais.
Obs: Como exemplo, podemos verificar os includes MV45AFZB e

MV45AFZZ, referente ao programa SAPMV45A.
Para encontrarmos User Exits em um determinado programa, podemos

utilizar a transação SE38, em “Utilitários”, na opção “Encontrar na Fonte”, e
“userexit_” como texto de procura. O resultado será uma lista de todas as User
Exits do programa, e onde elas foram chamadas em todas as telas do Pool de
Módulo.
Há ainda a visão de tabelas chamada INFO_MODS nas quais podemos

visualizar todas as possibilidades de exits existentes em um programa específico.
Deveremos então indicar o nome do programa que queremos buscar por exits no
campo MEMBER e o campo TYP significa qual o tipo da exit como abaixo:
17
TRANSAÇÕES IMPORTANTES AO DESENVOLVIMENTO:
SE38 – EDITOR ABAP

SE80 – OBJECT BROWSER (pode ser usada para chamarmos diversas
outras transações).
SE11 – DICIONÁRIO
SE16 – DATA BROWSER
SE71 – FORM PAINTER (EDITOR DE SAPSCRIPT)
SE10 – TRANSPORT ORGANIZER
SM30 – ATUALIZADOR DE VISÃO DE TABELAS
ST22 – ABAP ANÁLISE DE DUMP.
ST05 – TRACE REQUESTS (análise de performance).
ENTRADAS POSSÍVEIS NO CAMPO DE COMANDO:
Chamar uma transação:
- no mesmo modo (janela)

Entrar: /nxxxx (xxxx = código de transação).
- no mesmo modo (janela), a primeira tela é ignorada.

Entrar: /*xxxx (xxxx = código de transação).
- em um modo adicional
Entrar: /oxxxx (xxxx = código de transação).
Encerrar a transação atual:
18
Entrar: /n.
Atenção: modificações não gravadas são perdidas sem aviso
Eliminar o modo atual:
Entrar: /i.
Gerar uma lista de modos:
Entrar: /o.
Encerrar a transação atual e voltar ao menu inicial :
Entrar: /ns000.
Logoff do sistema:
Entrar: /nend.
Logoff do sistema sem consulta de segurança:
Entrar: /nex.
Atenção: modificações não gravadas são perdidas sem aviso.
TELAS DE SELEÇÃO:
Chama-se telas de seleção as telas especiais usadas para a informação de

valores nos programas Abap: em vez de usar o Screen Painter, podem ser criadas
por meio de instruções Abap na lógica de processamento do programa. A lógica
de fluxo de tela é fornecida pelo sistema e permanece invisível ao usuário como, o
programador da aplicação.
Definem-se as telas de seleção na parte da declaração de um programa

Abap por meio das instruções de declaração especiais (PARAMETERS, SELECT-
OPTIONS e SELECTION-SCREEN). Tais instruções declaram e formatam os
campos de entrada de todas as telas de seleção.
Os elementos mais importantes de uma tela de seleção são os campos de

entrada para valores individuais e para tabelas de seleção. Estas permitem a
entrada de critérios de seleção mais complicados e são fáceis de usar no sistema
Abap por serem processadas no próprio sistema. Como acontece no caso de
outras telas. O sistema fornece ajuda de campos e os possíveis valores para os
campos de entrada que fazem referencia a um campo do Abap Dictionary. O
19
sistema fornece conjuntos pré-configurados de valores de entrada para telas de

seleção denominados variantes. Quando é usada a instrução CALL SELECTION-
SCREEN, o sistema permite chamar uma tela de seleção de um programa Abap.
Caso se trate de um programa executável (relatório) de categoria 1, um programa
do sistema automaticamente chama a tela de seleção definida na parte de
declaração do programa. As telas de seleção acionam eventos e podem, assim,
chamar blocos de evento em programas Abap.
Posto que as telas de seleção contem principalmente campos de entrada,

os diálogos da tela de seleção são mais orientados por entradas do que as telas
definidas a partir do Screen Painter. As telas de dialogo podem conter campos de
entrada e de saída. As telas de seleção, entretanto, mostram-se apropriadas
quando o programa requer dados do usuário antes que possa continuar o
processamento.
Por exemplo, a tela de seleção poderia ser usada antes de acessar o banco
de dados, para restringir o volume de dados lidos.
PARAMETER:
OBLIGATORY
DEFAULT
AS CHECKBOX
RADIOBUTTON GROUP B1
Exercício.
Criar um REPORT utilizando todas as opções acima com PARAMETERS.
Combinar com os já apresentados
SELECT-OPTIONS:
A declaração SELECT-OPTIONS <nome> FOR <objeto de dados> insere

dois campos de entrada na tela de seleção, com o mesmo tipo definido na
referencia. Com isso, os usuários podem entrar um intervalo de valores ou
seleções mais complexas
Os diversos valores ou intervalos, entrados para uma opção de seleção,
são inseridos na tabela interna quando o usuário selecionar ´Executar´.
Exemplo:
1 - Para exibirmos em tela um parâmetro simples de entrada de dados:
20
PARAMETERS: P_PEDIDO LIKE EKKO-EBELN.
O que resultará na tela:
2 - Para exibirmos em tela um parâmetro composto de entrada de

dados (possibilitando a digitação de um RANGE de dados):
SELECT-OPTIONS:
SO_PED FOR EKKO-EBELN.
O que resultará na tela:
21
DECLARAÇÃO DE VARIÁVEIS:
É uma definição de objetos de dados.

A atribuição de categoria de objeto de dados é feita pela referencia do objeto a
uma categoria abap, a uma categoria definida pelo usuário ou a um objeto do
dictionary.
Sintaxe:
TYPE <ABAP-data-type> .
DATA: < varname> TYPE <user-definied.type>.
LIKE <ABAP-dictionary-object>.
22
O sistema permite também referir o objeto a um outro objeto de dados existentes.

Neste caso todos os atributos da categoria são herdados pelo novo objeto de
dados.
Exemplo:
DATA: <varname> LIKE <data-object>.
- Categoria de dados
2 tipos: Predefinidos
Definidos pelo usuário
- Predefinidos
No Abap existem 8 categorias de dados predefinidos:
• Numéricos:
Categoria Significado Adequado para
P numero compactado contadores, quantidade, índices, prazos
I numero inteiro moedas, comprimentos, pesos
F numero ponto flutuante calculo em um intervalo de valor muito

grande.
• Alfanuméricos:
Categoria Significado
N texto numérico
C texto (caracter)
D data
T horário (time)
X hexadecimal
23
Exemplo:
DATA: <varname> TYPE <ABAP-data-type>.
DATA: counter TYPE I,

name(18) TYPE C,
start_date TYPE D,
sum(3) TYPE P DECIMALS 2.
Numero de posições
Determina o numero de casa decimais a ser usado
• Regras para dar nome aos objetos de dados:

- Um nome pode Ter 30 caracteres no máximo.
- Os seguintes símbolos NÃO são permitidos: ( ) + . , :
- SPACE é um campo obrigatório.
MENSAGENS:
É uma caixa de texto configurada para ser exibida ao usuário quando um

determinado evento é disparado.
Todas as messages deverão ser executadas com textos padrões ou

personalizados.
Exemplos:
- Texto padrão:
MESSAGE I027 (BCTRAIN).
Chamada da Tipo de message Nº da message Texto utilizado de

message utilizada na biblioteca uma biblioteca padrão
- Texto personalizado:
MESSAGE W001(PC) WITH ‘Cuidado, operação pode gerar danos ao

sistema!’.
Chamada Tipo de Nº aleatório Utilização Texto não

da message message atribuído à não padrão
utilizada message padronizada utilizado
24
Tipos de mensagens:
A – Abend
W - Warning
I - Information
S – Status
E – Erro.
X – Exit (termina com short dump).
Exercício.
01 – Criar um report em que os parameters de entrada sejam exibidos em
mensagens (testar todos os tipos).
TRANSAÇÃO:
Conceito: Um processo lógico no sistema R/3.
Do ponto de vista do usuário, uma transação é uma unidade lógica (por

exemplo, gerar uma lista de clientes, criar uma reserva para um vôo ou executar
um programa).
Do ponto de vista do programador é um objeto complexo, que consiste num

grupo de módulos e uma série de telas. As transações se iniciam usando um
código de transação.
Depois de entrar no sistema R/3 existem 3 níveis: nível SAP, nível Work
Área e nível de aplicação. Uma transação é um processo em nível de aplicação.
Para iniciar a transação, o usuário poderá usar os menus ou entrar com 4

caracteres para o código da transação na linha de comando.
Componentes de uma Transação:

• Programa ABAP
• Diálogos do usuário (Telas, listas e telas de seleção)
• GUI – Interface gráfica do usuário (Barra de Menus, Barra de
ferramentas Standard e de aplicação e barra de títulos)
Etapas para criar uma nova transação:
Analisar o problema escrevendo uma especificação do programa. É

importante também checar se existem soluções similares já existentes;
Baseado nessas análises, escolher os tipos de diálogos do usuário (telas,
listas ou telas de seleção). As telas permitem criar diálogos amigáveis com
25
botões, controles de Tabstrip, Table Control e outros elementos gráficos.

Vide PBO, PAI e seqüências de telas e comunicação entre tela e programa;
Iniciar uma transação usando o seu código correspondente. Esse código
deve iniciar com Z ou Y e o sistema armazena código de transação na
tabela TSTC;
Inserir na caixa de texto User Command o código de transação SE80;
Clicar no botão ‘Processar Objeto’;
Escolher a opção TRANSAÇÃO e escolher o nome da transação;
Clicar em criar;
Escolher o Tipo de Transação:
Transação Diálogo – Module Pool – Chamada de tela
Transação Reports – Para reports
Transação Variante
Menu de Área – Habilitar menu de área
Transação Parâmetros
Caso os passos acima tenham sido executados com sucesso a transação
foi criada com êxito.
DEBUGGER:
É uma ferramenta de depuração de erros e análise de execução de

comandos/instruções.
Ele é utilizado para procurar erros semânticos nos programas. Existem

vários modos de iniciar o Depurador:
- No Repository Browser, selecionar Testar/Executar

- No ABAP Editor, selecionar Depuração
- Na transação a ser testada, digitar /h no campo de comando
- Em qualquer tela, selecionar Sistema => Utilitários => Depuração.
A tela Depurador tem duas áreas. A área superior exibe o código do

programa. Na área inferior, o sistema exibe várias informações adicionais,
dependendo da visão selecionada. Para alterar entre as várias visões, usam-se os
botões da parte superior da tela.
Selecionar Campos na parte inferior da tela para exibir o seu conteúdo. Posicionar
o cursor no nome do campo na área “código de programa” e selecionar F2 ou
clicar duas vezes no nome do campo.
• Pontos de parada
Finalidade: quando é selecionado Avançar no Depurador, o sistema

continua a processar até alcançar o próximo ponto de parada. Os pontos de
parada podem ser definidos como abaixo:
26
no Depurador: através de um clique duplo;

no Editor: através da instrução ABAP BREAK-POINT.
TIPOS DE TABELAS:
• Tabela Transparente
Existe uma tabela física no banco de dados para uma tabela transparente.
Todos os dados empresariais e dados de aplicação são arquivados em
tabelas transparentes.
Exemplo:
Todas as nossas tabelas do PW.ce.
EKKO – Cabeçalho do documento de compras.
EKPO - Item do documento de compras.
Nosso sistema PW.ce grava todas as informações em tabelas

transparentes
• Tabela Cluster – é uma tabela no banco de dados que contém um campo

LONG RAW (como uma “linha comprida”). O campo long raw contém uma
string concatenando várias informações. Essas tabelas existem para
permitir a criação de tabelas com mais de 255 campos que de outra forma
não seria possível por uma limitação do banco de dados.
Exemplo: Tabela BSEG.
Nosso sistema PW.ce NÃO utiliza tabelas cluster.
• Tabela Pool - Um pool de tabelas é uma tabela de banco de dados que

permite que os dados de múltiplas tabelas do R/3 sejam armazenados
dentro dele. As tabelas de Pool são uma estrutura proprietária da SAP e
são utilizadas para armazenar um grande número de tabelas muito
pequenas.
Nosso sistema PW.ce NÃO utiliza tabelas pool.
• Visão ou view – Um conjunto de duas ou mais tabelas transparente

integradas de forma relacional de forma que possam fornecer os dados de
forma integradas (fazendo um join). Muito utilizadas para melhoria de
performance de leitura dos programas ABAP, evitando que sejam criadas
leituras com condições de JOIN muito complexas e demoradas.
A view é uma “Visão de um BD”, ou seja, criam-se visões de bancos com o
27
objetivo de que certos dados sejam visualizados sempre que for chamada
uma view
associada a eles.
A maior utilidade deve-se ao fato de criar uma consulta default e toda vez
que se quiser visualizar os dados não será necessário “reinventar a roda”,
ou seja, montar todo o select novamente.
Imagine uma consulta que manipule 10 tabelas e 40 campos será que há
necessidade de ficar refazendo toda vez? Claro que não, crie uma view e
toda vez que haja necessidade faça uma chamada a ela!
Uma view não é utilizada apenas para visualização dos dados, caso se crie
uma view de apenas uma tabela, tem-se a opção de efetuar alterações
(update, insert e delete) na mesma replicando assim os dados para a tabela
de onde a view foi gerada.
• Estruturas - São como tabelas que não armazenam dados, definem um

conjunto de campos e geralmente são utilizadas para definir os dados em
interface e telas, assim como para atribuir o tipo aos parâmetros de
módulos de função. Utilizado para alocar memória para um grupo de
campos. Uma estrutura diferentemente de uma tabela não tem uma tabela
de banco de dados associada a ela.
Nosso sistema PW.ce utiliza estruturas para a exibição/alteração de

dados nas telas de nossos programas, porém esses dados NÃO estão
gravados fisicamente nessa estrutura, no caso esse campo dessa
estrutura não possui dados físicos. Os dados estão todos gravados
em tabelas transparentes.
DICIONÁRIO (DDIC).
Funciona como uma interface com um banco de dados ou ainda como um

mini gerenciador de banco de dados onde podemos definir e criar diversos objetos
de dicionário como tabelas transparentes, visões, estruturas elemento de dados,
domínios, ajudas de pesquisa e objetos de bloqueio.
SE11 – MOSTRAR.
Transação onde podemos criar, alterar, exibir eliminar objetos como:
Tabelas transparente, visões, estruturas, elementos de dados, domínios,
ajudas de pesquisa e objetos de bloqueio.
APRESENTAR TABELA TRANSPARENTE -> Conceito tabela física no BD
CRIAR UMA DE EXEMPLO: ZTALUNO.
28
MANDANTE -> SEMPRE CHAVE

TIPO DE CAMPO - CRIAR – DENOMINAÇÃO
DOMÍNIO – CRIAR E EXIBIR AS CATEGORIAS
MOSTRAR OPÇÕES TÉCNICAS.
MOSTRAR ATUALIZAÇÕES PERMITIDAS.
POPULAR A TABELA.
Exercício:
1 - Criar as tabelas ZTALUNO, ZTCLASSE, ZTPROF.
CONCEITO DE CHAVE ESTRANGEIRA – Toda chave estrangeira é chave

primária em alguma outra tabela do DDIC.
Criar uma CE entre a tabela de classe e a tabela de professores:
ZTCLASSE-CODPROF -> ZTPROF-CODPROF.
Exercício:
1 – Criar CE entre a tabela de alunos e a tabela de classe onde:
ZTALUNO-CLASSE -> ZTCLASSE-CLASSE.
APRESENTAR ESTRUTURA – Utilizado para exibir dados em tela,

passagem de
parâmetros entre programas e criação de SAPscript..
Não armazena dados -> Espaço reservado para trânsito de dados.
CRIAR UMA ESTRUTURA: ZFALUNO IDÊNTICA À TABELA ZTALUNO
Conceito de Tabelas de Verificação:
Uma verificação de valores é automaticamente executada, na tabela de

verificação, caso um campo de tela faça referencia a um campo do Abap
Dictionary com controle de chave externa.
O Sistema exibe uma mensagem de erro e disponibiliza o campo para nova

entrada quando uma tabela de verificação do campo não contem a entrada
realizada.
O botão (F4) exibe todas as entradas contidas na tabela de verificação de

um campo.
Todos os valores entrados em uma tela que possui valores fixos são,
automaticamente, comparados com esses valores fixos.
O sistema exibe uma mensagem de erro e disponibiliza o campo para nova

entrada quando uma entrada não corresponde a qualquer um dos valores fixos da
tela.
29
Exercício:
1 – Criar uma estrutura para cada tabela transparente criada (ZTALUNO,
ZTCLASSE, ZTPROFESSOR)
ATUALIZADOR DE TABELA.
MOSTRAR SM30 – ATUALIZAÇÃO DE TABELAS.

Podemos criar uma interface própria para atualizarmos dados em tabelas
transparentes. Essa interface se chama Visão de Atualização e é criada através
da transação SM30.
Temos que criar primeiro o gerados de atualização de tabela através da

transação SM11, opção do menu: utilitários -> Gerador de atualização de tabelas.
Logo após criado o gerador de atualização de tabelas devemos:

Entrar na transação SE93 -> Digitar um nome válido para a trasação e
clicar em criar.
Na tela seguinte informar uma descrição para a transação e marcar a opção
de Transação com parâmetros e confirmar:
30
Na tela seguinte informar: Uma descrição para o texto da transação. Na

opção transação informar a SM30 na caixa de texto e marcar o flag “Omitir 1ª
tela”
Na parte inferior da tela informar em valores propostos:
Nome do campo de tela Valor

VIEWNAME Nome da tabela transparente
UPDATE_LTD X
31
TABELA INTERNA.
CONCEITOS:
1 - São espaços de memória criados por um programa ABAP que só podem
ser utilizadas enquanto um programa está sendo utilizado.
2 - Armazenar dados temporariamente dentro de um prog. ABAP. As

tabelas internas só existem enquanto o programa estiver rodando.
3 - Tabelas criadas e declaradas dentro de um programa abap que não

existem fisicamente no BD.
4 - São alimentadas por seleção em tabelas ou inserção via comando do

programa e servem para guardar momentaneamente esses dados.
HEADER LINE
As tabelas internas podem ser definidas com ou sem uma linha de

cabeçalho. Uma tabela interna com linha de cabeçalho é composta por uma área
de trabalho e o corpo real da tabela, ambos endereçados com o mesmo nome.
O usuário pode declarar uma tabela interna com uma linha de cabeçalho
através do suplemento WITH HEADER LINE.
Para evitar erros, recomenda-se que o usuário crie tabelas internas sem
linha de cabeçalho. Entretanto, nas tabelas internas com linhas de cabeçalho é
quase sempre possível usar uma sintaxe reduzida para certas operações.
Uma tabela interna é uma seqüência de linhas do mesmo tipo.

Em geral as tabelas internas ( também denominada matriz) são usadas
para arquivar os resultados de processamento ou os dados de origem.
Elas são usadas para:

• Armazenamento temporário de dados das tabelas de banco de dados
para processamento posterior.
• Arquivamento de dados para exibição de listas.
• Arquivo de dados para comunicação com o computador de mesa, outros
servidores de aplicação do sistema R/3 ou sistemas não SAP.
As tabelas internas são descritas através de vários atributos, um dos quais é o tipo
de linha. O tipo de linha determina a estrutura dos registros de dados que podem
ser armazenados em uma tabela interna.
32
CARRID CONNID DISTANCIA Tipo de Linha
AA 0017 2,572
LH 0400 6,162 Dados
Outro atributo das tabelas internas são as chaves, que ajudam a identificar
as entradas da tabela. O importante na definição de uma chave é a seqüência de
seus campos.
Por exemplo, a chave CARRID CONNID é diferente de CONNID CARRID.
Existem dois tipos diferentes de acesso aos dados no Abap: com índice e
com chave.
Acesso com índice: Significa usar o índice do registro de dados que o
sistema mantem para acessar os dados.
Acesso com chave: significa usar o termo de pesquisa, em geral uma chave
da tabela ou uma chave da tabela genérica, para ter acesso aos dados.
- Categorias de Tabelas
As tabelas internas podem ser divididas em três categorias. De acordo com

o modo de acesso aos dados:
• Tabelas Standard: mantém, internamente, um índice linear e

podem ser acessadas atraves do seu índice ou de sua chaves.
• Tabelas Ordenadas: São ordenadas de acordo com a chave e

gravadas. Aqui, também um índice linear é utilizado internamente.
Este tipo de tabela também pode ser acessada através do seu
índice ou de suas chaves.
• Tabelas Aleatórias de Prova: Não mantém índice linear interno e

podem ser acessadas apenas através de suas chaves.
As seguintes operações podem ser executadas com tabelas internas

em ABAP:
Comando Efeito
APPEND Anexa o conteúdo de uma área de trabalho ao final de

uma tabela interna
INSERT Insere o conteúdo de uma área de trabalho em um
determinado ponto ( N° linha).
33
MODIFY Sobrescreve uma linha especifica com o conteúdo de

uma área de trabalho;
DELETE Apaga uma linha especifica de uma tabela interna.
LOOP AT Insere as entradas de uma tabela interna. Linha por

linha em uma área de trabalho.
READ TABLE Insere exatamente uma entrada da tabela interna

em uma área de trabalho.
SORT Ordena uma tabela interna.
CLEAR Limpa (apaga) uma área de trabalho ou uma tabela

interna.
- Preenchimento de Tabelas Internas
O sistema permite usar tabelas internas sempre que houver uma seqüência
de entradas ou linhas de mesmo tipo. Isto ocorre quase sempre quando um
programa precisa de uma copia interna de uma determinada tabela do banco de
dados.
O usuário pode preencher uma tabela interna com registros de dados de

uma tabela do banco de dados utilizando um loop SELECT para colocar registros
individuais de dados na área de trabalho de uma tabela interna e, depois,
anexando o conteúdo da área de trabalho à tabela interna no loop SELECT.
A instrução APPEND deve ser utilizada para preencher uma tabela interna.
Ao declarar uma tabela standard, o usuário não precisa usar o suplemento

STANDARD.
Exemplos de criação.
Debugar e mostrar vazia.
Passar os parameters para dentro da ITAB. Mostrar APPEND -> explicar
header line.
Exercício:
Algumas sintaxes de criação:
DATA: BEGIN OF itab_zprof OCCURS 0,

codprof like zprofessor-codprof,
34
nomeprof like zprofessor-nomeprof,

dtnasc like zprofessor-dtnasc,
END of itab_zprof.
OU
DATA: itab_zprof like zprofessor occurs 0 with header line.

DATA: BEGIN OF itab_zprofessor OCCURS 0.
include structure zprofessor.
data: idade(02) type c.
DATA: END OF itab_zprof.
OU
data: itab_zprof like zprofessor occurs 0 with heaDER LINE.
Exercício:
01 – Criar dentro do programa teste a declaração de tabela interna e

compilar.
02 – Debugar a o programa e exibir HEADER LINE -> explicar.
03 - Criar parameters para tabela ZPROFESSOR e mover para tabela
interna.
04 – Criar SELECTION SCREEN com bloco e frame.
Adendo a respeito da declaração OCCURS N em tabelas internas:
General Performance Notes for Internal Tables
OCCURS Value or INITIAL SIZE Specification
Internal tables are a dynamic data structure. Their memory requirements are met
in blocks. The initial memory allocation (hereafter called the OCCURS area), can
be controlled using the " OCCURS n" or "INITIAL SIZE n " addition in the table
definition (see DATA, TYPES). Once the OCCURS area is full, the next block to be
created is twice as big as the OCCURS area (as long as this is not greater than 8
KB). All further blocks are then created with a constant size of 12 KB.
You can leave it to the system to determine the size of the OCCURS area by
specifying n = 0. In this case, the system allocates only a "small" portion of memory
at the first INSERT or APPEND statement. "OCCURS 0" or "INITIAL SIZE 0"
means that 16 <= n <= 100 (depending on the line width).
It only makes sense to specify a concrete value of n > 0 when you know exactly
how many entries the table will have, and you want to set up the OCCURS area
exactly. This can be particularly important if you want to nest internal tables (where
an "outer" internal table contains one or more other internal tables in each line, and
the "inner" tables only have a few entries (no more than 5, for example).
35
To avoid excessive memory requirements, the system handles large values of n as

follows: The largest possible value of n is n_max = 8 KB divided by the line width.
For larger values, n is set such that n multiplied by the line width is around 12 KB.
MODULARIZAÇÃO:
CONCEITOS:
Organização do programa:
INITIALIZATION.
START-OF-SELECTION.
END-OF-SELECTION.
TOP-OF-PAGE.
Form – Perform.
A estrutura Form / Perform é muito utilizada com qualquer tipo de programa,
com ela executasse a modularização do código fonte através de blocos de
processamento.
Algumas vezes é comum ocorrerem confusões entre funções e a estrutura

form/perform pela seguinte causa:
Na função são passados valores quaisquer para serem processados e é

obtido um retorno “X” qualquer definido pelo programador, enquanto no
form/perform valores são passados para serem processados (podendo-se passar
até uma tabela inteira), mas não obtem-se um único retorno.
O que ocorre é uma chamada a um processamento em bloco passando

valores, representada pelo perform (que na realidade é uma chamada ao form). O
conteúdo do programa que vem abaixo do PERFORM só é executado se o bloco
de processamento FORM permitir, ou seja, neste tipo de estrutura não se fica
esperando um único retorno e sim um contínuo processamento.
A maior utilização do FORM / PERFORM dá-se ao fato que em um

programa bem modularizado o tempo de manutenabilidade fica reduzido gerando
assim uma otimização das tarefas.
Exemplo:
Criar os eventos e forms de processamento.

Passar parâmetros para o FORM.
36
COMANDO WRITE:
CONCEITO:
Serve tanto para mover dados tanto para saída de dados em tela.
Criar no END-OF-SELECTION a saída da tabela ZTPROF.
Separadores do WRITE -> Cabeçalho de saída.
FORMAT COLOR. INTENSIFYED ON/OFF.
Criar e mostrar a saída de dados da tabela interna ZTPROF.
Exercício:
1 – Criar o evento end-of-selection, o FORM de saída, o cabeçalho da
saída, a saída dos dados e fazer a formatação de cores.
TABELA SYST:
CONCEITO:
Tabela interna do sistema SAP/R3 que exibe controles internos
importantes para o processamento dos Programas ABAP.
A tabela Syst é representatividade de todo o sitema R/3 através de alguns

parâmetros. Parâmetros estes que permitem ao profissonal ABAP fazer
verificações no sistema.
Verificações englobam muitos detalhes, a tabela Syst é tão completa que

nos permite fazer desde verificações simples como a obtenção da data corrente
até checks mais complexos como a verificação de qual evento foi disparado pelo
usuário em um determinado momento.
Uma visão completa dos campos da tabela Syst é importante para que o
profissional ABAP fique alerta sobre quais os eventos que ele pode controlar
dentro do sistema, abaixo seguem alguns exemplos:
Sy-Index: Retorna um número de passagem atribuído, como por exemplo

dentro de um loop.
Sy-Tabix: Em tempo de execução retorna a linha atual utilizada em uma
tabela interna.
Sy-Ttabc: Número da última linha lida em uma tabela interna.
Sy-Linct: Número total de linhas de uma certa lista gerada.
Sy-Listi: Número da linha que estiver atualmente selecionada em uma lista.
Sy-Lsind: Número da lista de ramificação , pode-se por exemplo checar
quantas sub-listas foram executadas a partir de uma lista X.
Sy-Currow: Mostra a posição do cursor em uma linha.
Sy-Lisel: Mostra a linha selecioanda.
37
Sy-Cucol: Posição do cursor em uma coluna.

Sy-Binpt: Retorna se um batch input está ou não ativo.
Sy-Calld: Retorna se um modo de call está ou não ativo.
Sy-Mandt: Número do mandante logado no sistema SAP.
Sy-Opsys: Sistema operacional utilizado.
Sy-Ucomm: Mostra a ação “X” qualquer que o usuário deseja realizar, após
um evento ter sido executado pelo usuário.
Sy-Waers: Tipo de moeda utilizado.
Sy-Datum: Data do dia.
Sy-Uzeit: Hora
Sy-Uname: Usuário logado no SAP.
Sy-Host: Nome do host (máquina).
Sy-Subrc: return code (resultado de comandos)
Sy-tcode: Nome da transação.
SY-SUBRC = um dos mais importantes -> Retorna 0 (zero) se a

instrução anterior foi executada com sucesso.
Número de retorno após uma instrução ABAP.

Instrução com sucesso = 0.
Instrução com erro <> 0.
Sempre utilizado após SELECTS e diversos comandos de busca, inserção
e deleção de dados.
COMMIT WORK/ROOLBACK WORK:
Commit Work é uma técnica utilizada para salvar dados em um BD, esta
gravação é física, ou seja, os dados são “jogados” diretamente nas tabelas, para
confirmar as operações efetuadas no insert, update, etc. Normalmente deixamos o
SAP fazer este gerenciamento de gravação pois ele consiste todos os dados em
todas as tabelas, replicando assim as alterações.
O Commit não é uma técnica muito utilizada pois a margem de

acontecimentos de erros em sua execução é bastante alta.
Caso um processo de carga esteja sendo executado e aconteça um erro e

o Commit ainda não tenha sido efetuado podemos desfazer as operações
executadas até aquele momento com o comando ROLLBACK WORK.
Exemplo I:
Program .............................................
Module User_Command Input.
38
............................................................
............................................................
Case save_ok.
When ‘BACK’.
....................................
....................................
Message Axxxx.
ROLLBACK WORK.
When ‘SAVE’.
....................................
....................................
COMMIT WORK.
EndCase.
EndModule.
Exemplo II:
Ciclo de vida COMMIT x ROLLBACK
Rollback Rollback
Início |---------------------------------------|---------------------------------------| Fim

Commit Commit
Lock – Enqueue / Dequeue
O programa SAP R/3 utiliza lock nas tabelas por motivo de consistência
dados; em tempo de execução podem existir 2 ou mais pedidos de alteração
quase ao mesmo tempo em um campo X.
O sistema para evitar alterações incorretas nos seus dados, se utiliza de um

processo denominado “ LOGICAL LOCKS ” que consiste em criar uma fila de
processamento com utilização exclusiva da table para cada transação que deseja
manipular a mesma.
Exemplo:
Em um intervalo de tempo de 0,001 s. chegam duas solicitações para

alteração, a transação de nº.: 01 “trava” a tabela para que esta seja somente
manipulada por ela que chegou 1º. Após a liberação desta tabela pela transação
de nº.: 01 a nº.: 02 irá começar a manipular a tabela, ficando esta neste momento
exclusiva da própria transação.
Observa-se que o processo de travamento da table é efetuada por um objeto que

é chamado exclusivamente para isto:
39
- ENQUEUE_<Nome da Tabela>.
Para a liberação da mesma é chamado um outro objeto:
- DEQUEUE_<Nome da Tabela>.
Outro detalhe a ser observado é que antes de se utilizar os objetos, os mesmos
devem ser criados no ABAP Dictionary. A criação destes objetos poderá ser
efetuada para a manipulação de 1 ou N tabelas, vale lembrar apenas que se
houver manipulação em N tabelas deve antes existir um relacionamento entre
elas.
LOOP – ENDLOOP:
Estrutura de repetição comumente usada nos programas ABAP.
Serve para percorrermos as tabelas internas, permitindo que registro a

registro possam ser lidos e atualizados na header line fazendo com que esse
possa ser manipulado.
A instrução de loop LOOP AT .. ENDLOOP permite processar múltiplas

entradas de tabela interna. Cada vez que a instrução é executada no loop, o
sistema coloca a próxima entrada da tabela na área de trabalho <wa>
especificada no campo INTO.
O comando LOOP permite acessar as entradas da tabela interna através de

índice e de chaves.
Ao acessar através de chaves, recomenda-se restringir o numero de

entradas ou linhas a serem lidas com a clausula WHERE, exatamente como se faz
com um comando SELECT.
Sintaxe básica:
LOOP itab where campo = variável.

.
.
.
ENDLOOP.
Exercício:
01 – Dar LOOP nas tabelas internas criadas nos exercícios passados e
debugar.
02 – Dar LOOP com condições. (EX: Salário do professor maior que
R$1000,00).
40
03 – Dar LOOP na saída de resultados e só imprimir se salário <>

R$1000,00.
IF, ELSE, ENDIF:
Estrutura condicional usada para desviarmos o curso da programação TOP-

DOWN.
Sintaxe básica:
IF condiçao1.
Seqüência de comandos X
.
ELSE.
Seqüência de comandos Y
.
ENDIF.
A seqüência de comandos X será executada caso a condição 1 seja

verdadeira. Se a condição 1 for falsa somente a seqüência Y será executada.
Exercício:
01 – Criar um novo REPORT onde:
Tela de seleção com Código do aluno (obrigatório), nome do aluno e sexo

do aluno (usar a tabela ZTALUNOS como referência).
O relatório deverá ter no máximo 80 colunas .
Mudar a descrição de tela dos parâmetros utilizados para que fiquem com a
aparência do cabeçalho abaixo.
O programa deverá gravar em tabela interna todo o conteúdo da tela de

seleção e apresentar como resultado de tela a seguinte listagem:
Cód. Do aluno Nome do aluno Sexo
Na tela de saída o programa deve verificar o sexo do aluno (se = M ou F) e

preencher no campo de saída ‘Sexo’ o texto variável: ‘MASCULINO’ ou
‘FEMININO’.
41
Se o código do aluno for igual a 000 o programa imprimirá na tela de saída

a constante: ‘TÉRMINO DA LISTAGEM’ com o fundo em AMARELO.
ATENÇÃO:
01 – Adicionalmente podemos incluir um TOP-OF-PAGE com os seguintes

dados: ‘ACADEMIA ABAP 2006 – DATA DD/MM/AAAA – HORA: HH:MM:SS’
02 – os campos da tabela SYST contém valores referentes ao sistema,

como hora, data, código de transação que está sendo executada, código de
retorno de comandos (sy-subrc).
03 – Inserir na tabela interna ao menos 3 registros (1 via parameters 2 via

MOVE/APPEND.
CASE:
Instrução condicional que permite diferenciação de caso.

Exemplo:
CASE sy-ucomm. “ Verifica o valor da variável

WHEN ‘INC’. “ Executa se o usuário clicar no botão
incluir
PERFORM incluir.
WHEN ‘CANC’ OR ‘VOLT’. “ Executa se clicar no botão cancelar
SET SCREEN O.
WHEN OTHERS. “ Executa quando for escolhida outra
opção
Instruções
ENDCASE.
INSERT.
Adiciona novas linhas a uma tabela de dados.

Grava fisicamente registros em tabelas transparentes.
Se os dados da chave da tabela estiverem duplicados os registros na serão
gravados -> SY-SUBRC = 4.
Sintaxe básica:
42
INSERT dbtable FROM itab.

Adiciona os dados de uma tabela interna em uma tabela de banco de
dados.
INSERT dbtable.
Adiciona 1 registro na tabela de banco de dados.
IMPORTANTE: Confirmar com SY-SUBRC = 0 e dar COMMIT WORK.
Exercício:
01 – Utilizando o exercício anterior realizar a gravação dos dados da tabela
interna e após a gravação exibir uma mensagem do tipo I (informação) dizendo se
o registro corrente foi gravado ou não.
SORT.
O Comando SORT realiza uma organização da tabela interna conforme a

ordem declarada em sua sintaxe.
Para ordenar uma tabela interna, deve-se usar a instrução SORT. As

adições BY e ASCENDING ou DESCENDING permitem restringir a ordenação a
campos específicos e determinar a seqüência e a hierarquia da ordenação.
Campos texto podem ser ordenados por idioma utilizando o suplemento AS

TEXT.
DATA: itab_aluno TYPE TABLE OF ztaluno.
SELECT * FROM ztalunoi INTO TABLE itab_aluno.

SORT itab_aluno BY nomeal ASCENDING
dtnasc DESCENDING.
Sintaxe básica:
SORT itab BY campo1 campo2 campon.

SORT itab DESCENDING BY campo1 campo2 campon.
Exercício:
01 – utilizar o exercício anterior e exibir a saída do relatório organizando por
nome do aluno e sexo -> ASCENDING e DESCENDING.
43
MODIFY.
Realiza alterações de gravação em um registro de uma tabela interna.
Insere registros em tabelas de banco de dados, se o registro já existir um

UPDATE é executado automaticamente nesse registro.
Sintaxe básica:
MODIFY dbtable.
MODIFY dttable FROM itab.
MODIFY itab INDEX n TRANSPORTING c1 c2 cn.

MODIFY itab transporting c1 c2 cn WHERE condição.
Exercício:
01 – Com o exercício anterior alterar todos os nomes dos alunos para a
constante ‘JOSÉ DA SILVA’.
DELETE.
Deleta registros de uma tabela interna.

Deleta registros de uma tabela do BD.
Sintaxe básica:
DELETE FROM dbtable WHERE condição.
DELETE itab WHERE condição.
DELETE ADJACENT DUPLICATES FROM itab.
CLEAR:
A instrução CLEAR é utilizada para restaurar o conteúdo de um objeto de

dados ao seu valor inicial, de acordo com a sua categoria.
Considerando que as entradas da tabela interna são sempre de uma única

categoria, é suficiente uma instrução CLEAR para eliminar toda a tabela ou os
valores em sua header line.
44
Sintaxe básica:
CLEAR itab.
CLEAR itab[].
CLEAR wa.
INCLUDE :
São inclusões no programa cuja finalidade é chamar um sub-programa.

Criada uma determinada include esta pode ser utilizada por diversos programas
ao mesmo tempo bastando que para isso ela seja declarada no corpo do
programa:
INCLUDE zi_0001.
Onde zi_0001 -> Include não Standard (criada por programador).
INCLUDE <icon>
Onde <> se refere a includes pré-definidas no SAP e que podem ser

utilizadas como bibliotecas.
A declaração da include é comumente feita no início do programa após a

declaração de TABLES.
IMPORTANTE: Exibir a transação icon e explicar que podemos exibir em

lista de saída esses ícones com WRITE nome_do_ícone AS ICON.
Exercício:
01 - Retirar do programa principal todas as declarações de tabelas internas

e variáveis e colocá-las dentro de uma include criada pelo aluno.
Exercício (DELETE + ÍCONES):
01 – Deletar da tabela interna ZPROFESSOR os registros que o campo

NOME estejam vazios.
02 – Deletar da tabela transparente ZTPROFESSOR todos os registros que
SALÁRIO = 0.
45
03 – Criar um report baseado na tabela ZTPROFESSOR onde a tela de

seleção deverá conter os seguintes campos:
CÓDIGO DO PROFESSOR
NOME DO PROFESSOR
SALÁRIO
MOEDA
• Com código do professor obrigatório.
Incluir ao menos 4 registros na tabela interna de professor.
Para todos os registros da tabela interna:
Apagar da tabela transparente todos os registros onde SALÁRIO = vazio .
Para cada registro da tabela interna:
Se NOME DO PROFESSOR = vazio -> Alterar o campo da tabela interna

para a constante ‘NÃO INFORMADO’, essa informação deverá aparecer na
tela de saída com a letra VERMELHA e fundo NORMAL.
Gravar fisicamente o registro corrente na tabela transparente de

professores e :
Caso o registro seja gravado com sucesso acrescentar 1 a um contador de

acerto (variável do tipo I).
Caso o registro não seja gravado com sucesso acrescentar 1 a um contador

de erro (variável do tipo I).
ATENÇÃO:
Função para obtenção do nome do dia da semana:
RH_GET_DATE_DAYNAME
LAY-OUT DE SAÍDA:
Academia ABAP 2006 – PROCWORK Software

Data: DD/MM/AA – Quarta feira.
Hora: HH:MM:SS
Usuário : Login
46
Cód. Professor Nome Salário Moeda
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
As 3 últimas linhas do relatório trará a informação:
– INFORMAÇÃO.
- Número de registros gravados com sucesso: XX.

- Número de registros com erro : XX.
UPDATE:
Sobrescreve o conteúdo de campos na tabela transparente. Usado para

alterar o conteúdo de um ou mais campos específicos de acordo com condições
ou tabela interna.
UPDATE dbtab SET f1 ... fn WHERE condição.

UPDATE dbtab FROM TABLE itab.
Mostrar um exemplo de UPDATE num dos programas exemplo.
CONCATENATE:
Concatenar string ou pedaço de string em variáveis do tipo texto (char).
Exemplo:
Data: v_nome(15) type c value ‘JoãoMariaJose’.
Data: v_concatenado(40) type c.
Concatenate v_nome+04(05) ‘mulher do’ v_nome(04) ‘irmã do’

v_nome+09(04) into v_concatenado separated by space.
String v_concatenado ficará: ‘Maria mulher do João irmã do José’
47
WS_UPLOAD e WS_DOWNLOAD:
WS_UPLOAD:Função Standard do SAP. Tem por finalidade carregar para

tabela interna o conteúdo de um arquivo gravado localmente na estação de
trabalho. Esse arquivo deve obedecer uma formatação que possa ser lida e
jogada nos campos da tabela interna.
• Utilizar arquivo c:\teste.txt de exemplo.
Exemplo de utilização:
DATA: v_salario TYPE p DECIMALS 2.
DATA: BEGIN OF itab_prof OCCURS 0,

mandt LIKE zprof-mandt,
codprof LIKE zprof-codprof,
nomeprof LIKE zprof-nomeprof,
dtnasc LIKE zprof-dtnasc,
salario(13) TYPE c,
waers LIKE zprof-waers,
END OF itab_prof.
CALL FUNCTION 'WS_UPLOAD'

EXPORTING
filename = 'c:\teste.txt'
FILETYPE = 'ASC'
tables
data_tab = itab_prof
EXCEPTIONS
FILE_OPEN_ERROR =1
FILE_READ_ERROR =2
NO_BATCH =3
GUI_REFUSE_FILETRANSFER =4
INVALID_TYPE =5
NO_AUTHORITY =6
UNKNOWN_ERROR =7
BAD_DATA_FORMAT =8
HEADER_NOT_ALLOWED =9
SEPARATOR_NOT_ALLOWED = 10
HEADER_TOO_LONG = 11
UNKNOWN_DP_ERROR = 12
ACCESS_DENIED = 13
DP_OUT_OF_MEMORY = 14
DISK_FULL = 15
DP_TIMEOUT = 16
OTHERS = 17.
LOOP AT itab_prof.
MOVE:
itab_prof-mandt TO zprof-mandt,
itab_prof-codprof TO zprof-codprof,
itab_prof-nomeprof TO zprof-nomeprof,
itab_prof-dtnasc TO zprof-dtnasc,
48
itab_prof-waers TO zprof-waers,
itab_prof-salario TO v_salario,
v_salario TO zprof-salario.
INSERT zprof.
ENDLOOP.
WS_DOWNLOAD: Função Standard do SAP. Tem por finalidade gravar na

estação de trabalho um arquivo com os dados de uma tabela interna.
Exemplo de utilização:
CALL FUNCTION 'WS_DOWNLOAD'

EXPORTING
filename = 'c:\teste.txt'
filetype = 'ASC'
* IMPORTING
* FILELENGTH =
TABLES
data_tab = itab_prof
EXCEPTIONS
file_open_error =1
file_write_error =2
invalid_filesize =3
invalid_type =4
no_batch =5
unknown_error =6
invalid_table_width =7
gui_refuse_filetransfer =8
customer_error =9
OTHERS = 10.
Exercício:
01 – Apagar o conteúdo das tabelas ZTALUNO, ZTCLASSE e ZTPROF
utilizando DELETE.
02 – Carregar as tabelas internas de alunos, professores e classe com os
arquivos texto correspondentes.
03 – Carregar as tabelas transparentes de alunos, professores e classe
com as tabelas inernas.
04 – Com uma das três tabelas internas carregadas utilizar a função
WS_DOWNLOAD e gravar o arquivo com a nomenclatura
C:\saida_ddmmaaaa_hhmmss.txt
WORK ÁREA:
Assim como a declaração tables, podemos criar uma área de memória para
uma estrutura de dados declarada na qual podemos manipular dados de
‘cabeçalho’, não podendo portanto armazenar mais do que uma linha de
informação.
49
Essa estrutura pode ser definida campo a campo ou fazendo-se referência

a tabelas transparente, tabelas internas ou estruturas.
SELECT:
Utilizado para preenchimento de dados em memória para podermos

trabalhar com informações gravadas em tabela.
SELECT <result> FROM <tables> INTO <target> WHERE <condition>.
<results> - conjunto dos campos a serem selecionados

<tables> - tabela transparente ou visão de consulta
<target> - Estrutura de destino, em memória
<condition> - caso queira, condições de seleção
Variações
SELECT SINGLE – leitura de um único registro.
Para uma melhor performance, é necessário a apresentação da chave

primária completa na cláusula WHERE.
INTO <wa> - destino work area, registro, estrutura;

INTO (f1, f2,...,fn) – destino, campos específicos;
INTO CORRESPONDING FIELDS OF <wa> - destino, campos
correspondente de um determinada estrutura. A comparação se dá pelo nome das
colunas;
INTO TABLE <itab> - destino, para uma tabela interna;
INTO CORRESPONDING FIELDS OF TABLE <itab> - destino, campos
com mesmos nomes de uma determinada tabela interna;
SELECT....ENDSELECT – leitura de múltiplas linhas;
Para esta situação não poderemos utilizar como adicionais do código:

SELECT SINGLE, INTO TABLE e INTO CORRESPONDING FIELD OF TABLE;
É gerado um SELECT-Loop para o pocesso.(Vide FETCH);
50
SELECT....FROM...INTO....FOR ALL ENTRIES IN <itab>...WHERE....<F1>

EQ <itab>-<FX>.
FOR ALL ENTRIES – restrição de seleção com base em tab. Interna

preenchida anteriormente;
Obrigatório a apresentação de comparações dos campos da tab. Interna na
cláusula WHERE;
IMPORTANTE: CASO A TABELA INTERNA DE COMPARAÇÃO ESTEJA
VAZIA, TODOS OS REGISTRO – IRRESTRITAMENTE – SERÃO CARREGADOS
SELECT......UP to <n> ROWS
Seleção de dados com restrição de ocorrências;

<n> pode ser fixo ou variável;
Visões
SELECT <t1>~<f1> <t2>~<f1> FROM <t1> INNER JOIN <t2> ON

<t1>~<f3> EQ <t2>~<fx> INTO ...WHERE...
<t1> e <t2> tabelas a se relacionarem;

INNER JOIN condição para somente os egistros relacionados;
ON – condição da relação;
INTO e WHERE – mesmo critério da forma básica;
Exercício:
01 – Selecionar todos os dados das 3 tabelas (professores, alunos e classe)

e armazenar em tabela interna.
01.01 – Exibir um relatório com a saída (formatada campo a campo) com o
conteúdo de todas as 3 tabelas internas carregadas.
LAY-OUT:
TABELA DE ALUNOS:
Todos os campos menos o mandante.
51
TABELA DE PROFESSORES:
TABELA DE PROFESSORES:
02 – Criar o parâmetro de tela: Código do aluno.

Selecionar na tabela aluno o nome do aluno a data de nascimento e a classe do
aluno onde CODAL = Código do aluno e armazenar numa WORK ÁREA.
02.01 – Selecionar da tabela de classe o código do professor e a sala onde
CLASSE = classe do aluno e armazenar numa WORK AREA.
02.03 – Selecionar da tabela de professores o nome do professor onde
CODPROF = código do professor.
02.04 – A saída dos dados deve ser apresentada da seguinte maneira:
LAY-OUT:
CÓDIGO DO ALUNO: XXXX.

NOME DO ALUNO: XXXXXXXXXXXXXXXXXX.
Sala de Cód. do professor Nome do professor

aula
03 – Criar um parâmetro de seleção de tela Código do Professor.

Selecionar o nome do professor da tabela ZTPROFESSOR e armazenar numa
WORK AREA.
03.01 – Com o código de professor selecionar os campos classe e sala da
tabela ZCLASSE (todos os registros encontrados) e armazenar numa tabela
interna.
03.02 – Para todas as entradas da tabela interna de classe selecionar o
nome do aluno e sexo da tabela ZTALUNOS onde CLASSE = classe da tabela de
classe.
03.03 – A saída dos dados deve ser apresentada da seguinte maneira:
LAY-OUT:
CÓDIGO DO PROFESSOR: XXXX.

NOME DO PROFESSOR: XXXXXXXXXXXXXXXXXXXX.
Classe Sala Nome do aluno Sexo
52
TOTAL DA LISTAGEM: XX
SUBMIT:
Comando utilizado para chamarmos reports externos ao programa

atualmente executado.
Sintaxe básica:
SUBMIT report.
EXPORT IMPORT:
Comandos utilizados para transferência de dados entre programas.

Basicamente podemos jogar em memória e recuperar informações relevantes que
podem ser usadas em outros programas ou exits.
Podemos passar para memória dados como valores de variáveis. work
áreas e tabelas internas através do comando EXPORT e recuperar eses dados
em um determinado ponto com o comando IMPORT.
Sintaxe básica:
EXPORT work_area to memory id ‘MEM1’.
EXPORT variável to memory id ‘MEM2’.
Onde MEM1 e MEN2 são nomes qualquer dados por nós que se
referenciarão automaticamente como endereços de memória no R/3.
EXPORT itab TO DATABASE(01) id ‘MEM1’.
Onde 01 é um índice numérico sequencial dados por nós e MEM1 é um

nome qualquer dados por nós.
Por sua vez o IMPORT faz o commando contrário, ou seja, busca da

memória os dados passados pelo EXPORT:
IMPORT work_area from memory id ‘MEM1’.

IMPORT variável from memory id ‘MEM2’.
IMPORT itab from database(01) id ‘MEM1’.
53
READ TABLE:
Comando utilizado para procura de uma única ocorrência dentro de uma

tabela interna. Podemos utilizá-lo dentro de LOOP para procura dinâmica dentro
de cada laço.
Não suporta AND e OR.
A instrução READ TABLE <itab> deve ser utilizadas para ler entradas
individuais da tabela. Todas as entradas de tabela lidas são colocadas na header
line.
Com o comando READ o usuário pode acessar as entradas da tabela

interna através do índice e das chaves.
Sintaxe básica:
READ TABLE itab1 WITH KEY

campo1 = itab_2-campo1
campo2 = itab_2-campo2
campo3 = ‘001’ <BINARY SEARCH>.
A adição ‘BINARY SEARCH’ realiza uma procura mais rápida e utiliza

pesquisa binária, para funcionar corretamente a tabela deve estar sorteada pela
chave completa. Caso não seja usada essa cláusula a procura se torna linear.
READ TABLE itab1 INDEX n.
Onde INDEX n aponta para o número do registro que queremos ler dentro
da itab.
ATENÇÃO: Devemos sempre testar o retunr code (SY-SUBRC) após a

utilização do comando READ TABLE.
Exercício:
01 – Incluir um SELECT-OPTIONS na tela com o campo código da classe

da tabela ZTCLASSE (SO_CLASSE).
01.01 – Selecionar CLASSE e CÓDIGO DO PROFESSOR da tabela
ZCLASSE onde CLASSE = SO_CLASSE.
01.02 – Selecionar da tabela de professores ZTPROFESSOR todos os
CÓDPROF de acordo com as entradas da tabela ZTCLASSE selecionada.
54
01.03 – Dentro de um laço na tabela interna de classes procurar a entrada

correspondente na tabela interna de professores onde ZTPROFESSOR-
CODPROF = ZTCLASSE-CODPROF.
MODULE POOL:
Também conhecido como ON-LINE é o tipo de programa que roda sempre

em foreground e permite criação de telas, botões em telas de seleção, grid de
dados, tabstrip.
Permite atualização de dados em tela.
Controles:
INCLUDE PBO: Sigla de PROCESS BEFORE OUTPUT.

É o evento sempre executado antes da exibição da tela corrente. Todas as
telas de MODULE POOL possuem PBO, onde inserimos codificação que pode ou
não ser apresentada em tela e/ou processada.
INCLUDE PAI – Sigla de PROCESS AFTER INPUT.

É o evento sempre executado após a exibição da tela corrente. Todas as
telas MODULE POOL possuem PAI, é a codificação que processará os dados
fornecidos pela tela.
INCLUDE TOP – É o local reservado para declarações de tabelas,

estruturas, tabelas internas, variáveis, etc. Tudo que for declarado no TOP é
global (é enxergado em qualquer parte do programa).
INCLUDE FORM – Local reservado para incluirmos os FORMs criados

durante a programação. Permite melhor organização do programa.
PBO Tela do programa PAI
process before process after input.

output .
field zycie006-bukrs
module: module
load_data, authority_empresa.
status_0100,
set_screen. module:
user_command_0100.
55
• Criar a tela como “tela normal” – geralmente a primeira tela é 001.

• Criar transação para o programa.
• Declara em TOP uma work área para tabela professores.
• Mostrar a tela de desenho de LAYOUT.
• Puxar do programa o código do professor e botar em tela.
• Criar botões de saída da transação.
• Criar um botão de seleção.
• Criar break point e debugar para mostar a dinâmica do PBO e PAI.
Exercício:
01 – Criar um programa on-line com 1 tela e duas caixas de texto onde

informado o código do professor seja exibido o nome do professor. Incluir os
controles de saída do programa e criar transação para o programa.
01.01 – Após informar o código do professor e confirmar o nome do

professor deverá ser exibido no campo correspondente.
01.02 – Caso não exista o registro na tabela de professores o programa
deverá exibir uma mensagem informando que o registro não foi encontrado e
deverá limpar o campo de nome do professor.
02 – Incluir no exercício anterior um botão EM TELA que deverá chamar

uma segunda tela em branco. Essa segunda dela deve ter os controles de
VOLTAR, ENCERRAR e CANCELAR ativados e funcionando.
CALL SCREEN:
Comando executado para chamar outra tela no programa. A tela chamada

precisa estar criada e ativa.
Criar uma tela 0100 para o exercício de module pool.
LEAVE:
Abandona o processamento da tela atual.
Pode ser:
LEAVE PROGRAM.
LEAVE TO SCREEN ‘xxx’.
56
Etc... (ver help e apostilas).
TABLE CONTROL:
É o nome dado ao GRID com dados exibidos em tela. Servindo para

consulta, edição, inserção e deleção de dados de acordo com a programação
executada. Podendo ter botões de maneira a controlarmos os dados e postos
nesse grid.
Uma table control é uma área na tela na qual o sistema mostra os dados
em forma tabular. Ela é processada usando um loop.
O top line de uma table control é a header line.
O uso da Table Control é utilizado quando houver a necessidade de

desenvolvimento de protótipos module pool onde necessite navegar, visualizar,
editar, gravar dados de uma tabela transparente de forma interativa na sua screen.
A linha da tabela interna correspondente a linha da table control sendo

processada é lida da header line da tabela interna.
Os dados da header line da tabela interna são copiados para a linha

relevante da tabela interna.
Os campos do table control podem ser abertos ou fechados para edição e

alguns outros atributos podem ser alterados. Podemos controlar isso com
programação no PBO:
LOOP AT SCREEN nome_tbc.

IF screen-name = ‘campon’.
SCREEN-INVISIBLE = 1. -> ESCONDE O CAMPO.
SCREEN-INPUT = 0. -> DESABILITA PARA ENTRADA.
SCREEN-REQUIRED = 0. -> TIRA A OBRIGATORIEDADE.
ENDIF.
MODIFY SCREEN.
ENDLOOP.
Exercício:
01 – Criar um programa module pool com uma tela e um GRID com os
campos nome, data de nascimento, salário e moeda da tabela de professor.
Os campos do grid deverão estar em uma estrutura.
57
Criar os controles de voltar, encerrar e cancelar.
ATENÇÃO:
Devemos declarar o grid no TOP:
Controls: Nome_do_grid type tableview usind screen ‘0100’.
Devemos declarar a tabela interna para guardar os dados vindos da tabela
transparente e dar loop no PBO e PAI:
PROCESS BEFORE OUTPUT.
MODULE STATUS_0100.
loop at itab_prof
CURSOR tbc100-CURRENT_LINE.
MODULE CARREGA_PROF.
endloop.
*
PROCESS AFTER INPUT
MODULE USER_COMMAND_0100.
loop at itab_prof.
endloop.
COLUNA DE MARCAÇÃO:
Serve para identificarmos dentro da tabela interna do TABLE CONTROL

qual linha está marcada no momento de executarmos algum processamento.
Podemos então impor a condição de só realizar determinado processamento se a
linha estiver marcada.
Devemos clicar no flag ‘C/ col. Marc’ nos atributos da table control.
Devemos criar um campo de flag na tabela interna com o mesmo nome do

flag de atributo.
Exercício:
01 – Com a table control do exercício anterior criar coluna de marcação e
atualizar os dados da table control para a tabela interna.
58
CRIAÇÃO DE BOTÔES EM TELA:
Serve para acionarmos algum procedimento que será processado no PAI

do programa. Devemos dar nome ao botão e ao CÓDIGO DE FUNÇÃO em
propriedades.
O apertar do botão deve ser testado no module PAI e devemos testar se
SY-UCOMM = CÓDIGO DE FUNÇÃO.
Criar um botão em tela e debugar mostrando o valor do SY-UCOMM.
Exercício:
01 – Criar um botão de INSERIR no exercício anterior. Testar se na table
control existe alguma linha selecionada. Se não: dar mensagem de informação
dizendo que não há linhas selecionadas.
Se o registro (chave) já existir na tabela de professores deveremos dar uma
mensagem informando “O registro não será inserido”. Caso não exista o registro
deverá ser gravado na tabela de professores o registro selecionado.
02 – Criar um botão em tela EXCLUIR. Verificar se alguma linha foi

selecionada. Se sim: excluir o registro corrente da tabela transparente e atualizar a
table control.
TABSTRIP:
Nome dado às tela com abas, como se fossem orelhas de navegação, vide
tela abaixo:
59
São compostas por:

- Tela principal (tela de fundo)
- Declaração da tabstrib:
- Abas de controle
- Subtelas
Onde:
Tela principal:
Tela obrigatória onde conterá as chamadas das subtelas. Essa tela pode ter
campos como cabeçalho ou não ter nada, apenas as próprias subtelas. Na tela
principal obrigatoriamente precisamos ter a chamada de subscreen no PBO e no
PAI.
Exemplo:
PROCESS BEFORE OUTPUT.

MODULE STATUS_0100.
call subscreen:
SS_PROF including syst-cprog '0101',
SS_ALUN including syst-cprog '0102'.
PROCESS AFTER INPUT.

call subscreen:
ss_prof,
ss_alun.
MODULE USER_COMMAND_0100.
Declaração de TABSTRIP:
É a declaração de dados feita no TOP INCLUDE onde criamos a
TABSTRIP propriamente dita. É declarado como CONTROLS.
Exemplo:
controls:
ts_curso TYPE TABSTRIP .
Abas de controle:
É o nome da aba propriamente dita. O local onde serão criadas as
SUBSCREEN’s e deve ser criada dentro do SCREEN PAINTER.
No nosso exemplo os nomes das abas são: TAB_PROF e TAB_AL.
60
Exemplo:
Subtelas ou subscreen:
Área física criada dentro das abas de controle que contém o objeto “Área de
subtela” do screen painter.
No nosso exemplo as subscreen’s criadas tem o nome: SS_PROF e SS_ALUN.
Toda subscreen criada tem que ser referenciada a uma tela criada. No nosso
casso essas telas são 0101 e 0102. Essas telas no momento de criação são do
tipo SUBTELA.
Exercício:
01 – criar um module-pool onde:

Tela 1: Digitar o código da classe. Após clicar em botão de status ‘B1’ exibir nessa
tela o campo sala.
Tela 2: É uma tela de exibição de tabstrip que será acionada pela tela 1 clicando-
se em botão de status ‘B2’.
Tela 3 – É uma subtela da tela 2 e será a aba PROFESSOR da tabstrip. Listará o
conteúdo da tabela de proferssores onde ZTPROFESSORES-CODPROF =
ZTCLASSE-CODPROF.
61
Tela 4 – É uma subtela da tela 2 e será a aba ALUNOS da tabstrip. Listará o

conteúdo da tabela de alunos numa table control onde ZTCLASSE-CLASSE =
ZTALUNO-CLASSE (a table control poderá ter diversas linhas).
Atenção: Criar os botões de saída das telas.
CARGAS EM BANCO DE DADOS
Carga em BD é um processo de preencher tabelas com dados já existentes,

normalmente jogando os dados em um arquivo .txt e fazendo o up-load. Podemos
também alimentar tabelas internas e/ou estruturas utilizando programas e assim
fazer as cargas desses dados em tabelas ou transações existentes.
Atualmente já existem algumas ferramentas que fazem este up-load

automaticamente, em alguns casos podemos também fazer o up-load diretamente
via código puxando dados de um outro BD já existente.
Alguns tipos de cargas existentes no SAP:
1 - Direct Input
Este tipo de carga não é utilizado pois não há uma consistência dos dados
na inserção dos mesmos no SAP.
Se trata de uma gravação direta nas tabelas do sistema feita por um

programa ABAP, essa técnica não é recomendada pela SAP para gravações em
tabelas Standard devido a comprometer a integridade dos dados gravados pelas
transações Standard.
Quando os dados são gravados eles não se propagam para as outras

tabelas que manipulam os mesmos.
2 - Batch Input
O Batch Input é um processo de carga onde os dados não são inseridos

diretamente em uma tabela, eles são carregados em transações.
Essas transações são indicadas no processo de Batch Input. Para cada

transação diferente deve-se criar um novo Batch input. A partir do momento que
62
se manipula transações, evita-se o erro de inserção errada de dados nas tabelas

pois o SAP trata da propagação desses dados dentre as várias tabelas utilizadas.
O mapeamento dos campos que serão manipulados nas transações pode ser
feito de duas formas:
• Transação SHDB: Nesta transação efetua-se o mapeamento de todos os

campos a serem utilizados na execução do Batch Input. É normalmente o
método mais utilizado.
• F1 + F9: Utilizado quando a transação SHDB não está disponível, um

pouco mais trabalhoso de se usar pois cada campo será mapeado
individualmente, em cada campo a ser manipulado vou ter que pressionar
essas teclas para efetuar a verificação.
No Batch Input podemos fazer uma leitura de um arquivo .txt que conterá os
dados a serem inseridos nas transações, para isto utiliza-se a função
WS_UPLOAD. Quando o up-load é efetuado a tabela BDC serve como interface
entre o .txt e as transações, efetuando assim o gerenciamento dessa operação de
carga, incluindo neste momento a manipulação dos campos e seus respectivos
usos.
Podemos também fazer o carregamento da tabela BDC através de seleções de

dados e append em tabelas internas que servirão de passagem de dados para a
BDC.
A grande vantagem de utilização do Batch Input deve-se ao fato de que a

carga não precisa ser efetuada no momento da criação da pasta que o conterá.
A pasta pode ser criada em um dado momento e em outro processá-la, o

processo em si pode ser executado de diferentes formas, seja ele com a
intervenção do usuário, oculto (sem intervenção) ou então somente o usuário
intervir quando der um erro.
3 – Call Transaction
Normalmente utilizado como uma alternativa ao Batch Input, possui

características próprias, mas também pode se utilizar do batch input para ser
efetuado de uma forma mais “rápida”.
No call transaction existe uma transferência direta dos dados em contraste

ao batch input. Para armazenar dados de tela temporariamente é usada uma
tabela interna (tabela BDC com a mesma estrutura do batch input), a transação é
63
chamada no programa e o sistema importa os dados temporariamente

armazenados na tabela BDC para as telas de transação.
Um programa de CALL TRANSACTION tem uma estrutura similar a do BATCH

INPUT.
Chamada:
CALL TRANSACTION ‘nnnn’ USING a MODE b UPDATE ‘c’

MESSAGES INTO d.
Onde:
- ‘nnnn’ = número da transação
- ‘a’ = tabela BDC – vide B.I.
- Mode:
A (default) O sistema mostra todas as telas com seus dados.
N O sitema não mostra as telas logo após a transação ter sido
processada, existe um retorno do controle programa (o valor de
UPDATE determina se haverá atualização no BD)
E Logo que um erro ocorre na tela o sistema devia para o modo A
para que sejam efetuadas as correções.
- Update:
‘c’ Controla como as atualizações do BD chamadas pela
transação são executadas.
Divide-se em 3 modos:
A (Atualização assíncrona) A transação chamada não
aguarda até que o BD atualize o que tem que ser executado mas
passa a atualização para o SAP UPDATE TASK, o programa de
Batch Input será executado mais rápido porém não se terá um
retorno se a atualização foi bem sucedida no BD.
As ferramentas de análise e correção de erros não são tão simples
de se uasr quanto as do modo síncrono.
S (Atualização síncrona) A transação chamada aguarda até
que a atualização esteja finalizada, o processamento por motivo
dessa espera fica um pouco mais lento do que no modo assíncrono
porém esta transação pode listar erros caso aconteça algum na
execução, simplificando desta forma a análise e correção dos
mesmos.
L (Local) O BD é atualizado na chamada do processo do
programa.
- Messages Into <it_table>: Especifica que todas as mensagens geradas

pelo sistema através do CALL TRANSACTION serão armazenadas na
64
tabela interna especificada, esta tabela interna obrigatoriamente deverá ter

a estrutura: BDCMSGCOLL .
4 – BAPI
BAPI é uma ferramenta de carga de dados criada a partir da versão 4.0 e

mais comumente usada a partir da 4.5. Trata-se de um conjunto de funções
Standard criadas pela SAP que realizam de forma invisível o preenchimento dos
dados necessários a determinadas transações Standard para a criação ou
modificação de dados nessas transações sejam feitas de forma correta e
consistente.
Internamente as BAPIs agregam diversos elementos de orientação a

objetos e não permitem que a codificação da mesma seja alterada.
Devemos então passar parâmetros como tabelas e estruturas preenchidas

corretamente de acordo com a necessidade de cada transação e regra de
negócio.
Através da transação BAPI podemos visualizar as BAPIs disponíveis e

temos também uma listagem com a descrição dos parâmetros a serem
preenchidos para cada BAPI.
Se torna fundamental o acompanhamento do consultor funcional para

podermos distinguir todos os campos/parâmetros que deveremos informar para o
correto funcionamento da regra de negócio.
Exemplos de uso:
Criação de pedidos de compra;

Criação de material;
Entrada física em estoque;
Entrada fiscal em estoque;
Etc...
SAPSCRIPT:
É a forma de imprimirmos em formulários customizados. Podemos criar

formatos de páginas, tipos de parágrafo, tipos de caracteres de forma a exibirmos
em tela ou em papel formulários completamente customizados de acordo com a
real necessidade da aplicação.
65
Como exemplos de SAPscript tradicional temos o formulário de nota fiscal e o

pedido de compra. Cada empresa pode utilizar um lay-out diferente e pessoal para
a saída de sua nota fiscal de acordo com um modelo qualquer. Temos então
alguns relatórios com formulários SAPscripts que podem seguir lay-outs
estabelecidos.
Com a transação se 71 podemos criar um formulário de SAPscript.
Devemos informar no - cabeçalho -> configurações globais – o Formato de

Página que é uma configuração de tamanho de página que é configurado e criado
por BASIS na transação SPAD.
Assim para começarmos a criação de um formulário devemos saber em

primeiro lugar qual o formato de página utilizar. Podemos utilizar um já existente
ou teremos que fazer contato com a equipe de BASIS para ser criado um formato
de página específico.
Informaremos ainda o alinhamento (vertical ou horizontal), os tamanhos do

caracter, as distâncias de tabulador, a fonte padrão utilizada e variações como
sublinhado, itálico e negrito.
Os formulários são divididos em páginas e janelas, sendo que a cada página

são atribuídas as janelas que constarão da mesma. Ou seja, cada página deverá
ter uma ou mais janelas associadas. E devemos ter ao menos uma janela de
nome MAIN que indentificará a janela principal do formulário, onde as informações
mais relevantes do formulário serão impressas.
Podemos criar formulários de SAPscripts para diversas aplicações não

standards do SAP, ficando a critério de desenvolvimentos adicionais a criação dos
programas e desenho do formulário. Temos então uma nomenclatura básica para
a chamada, utilização e exibição via programa dos formulários de SAPscript:
Utilizaremos por padrão as seguintes funções:
1 – OPEN_FORM
CALL FUNCTION 'OPEN_FORM'

EXPORTING
device = 'PRINTER'
dialog = 'X'
EXCEPTIONS
canceled = 1
device = 2
form = 3
options = 4
unclosed = 5
OTHERS = 6.
66
Utilizada para abertura do formulário, onde:
Device = Dispositivo de saída – por padrão ‘PRINTER’

Dialog = Abrir caixa de diálogo de impressão de SAPscript.
2 – START_FORM
CALL FUNCTION 'START_FORM'

EXPORTING
form = 'Z_SAPSCRIPT_CURS'
EXCEPTIONS
form = 1
format = 2
unended = 3
unopened = 4
unused = 5
OTHERS = 6.
Utilizada para informarmos o nome do formulário, onde:
Form = Nome do formulário SAPscript.
3 – WRITE_FORM
CALL FUNCTION 'WRITE_FORM'

EXPORTING
window = 'CABEC'
element = 'TEXTCB'
EXCEPTIONS
element = 1
function = 2
type =3
unopened = 4
unstarted = 5
window = 6
OTHERS = 7.
Utilizada para chamar a janela e o elemento da janela corresponde no

formulário, onde:
Windown = Nome da janela do formulário SAPscript.

Element = Objeto ELEMENTO criado dentro da janela.
4 – END_FORM
CALL FUNCTION 'END_FORM'

EXCEPTIONS
67
unopened = 1
OTHERS = 2.
Utilizada para informarmos que o formulário não está mais em uso.
5 – CLOSE_FORM
CALL FUNCTION 'CLOSE_FORM'

EXCEPTIONS
unopened = 1
OTHERS = 2.
Utilizada para fechamento do formulário SAPscript.
• Utilizaremos para exemplo o programa: Z_SAPSCRIPT_CURSO e o

formulário Z_SAPSCRIPT_CURS.
Vale ressaltar ainda que na transação SE71 temos a opção Utilitários – Ativar
depurador.
Essa opção liga o debuger de SAPscript que se apresenta num lay-out um
pouco diferente do debuger conhecido para programas. Vale a pena então
ativar o debuger de SAPscript e vermos como ele se comporta.
Exercício:
Criar um report onde:
Informado o código do aluno, o report deverá chamar um formulário de
sapscript e imprimir 3 janelas onde:
Primeira janela:
RELATÓRIO DE ALUNO
Código do Aluno: XXX
Segunda janela (janela MAIN):
Nome do aluno : XXXXXXXXX
Classe : XXXX
Sexo :X
Data nascimento: XX/XX/XXXX
68
Terceira janela
Rodapé do relatório
Data: XX/XX/XXXX.
Hora: XX:XX:XX
• Todas as 3 janelas deverão ter BOX (quadrado separador com os textos

dentro).
• Utilizar formato de página já existente e alinhamento no formato vertical.
69

Academia-Abap PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Academia-Abap PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Material de treinamento – Conceitos ABAP

Academia ABAP – 2006 – PROCWORK Software.

O que é SAP ???

A medida que novos conceitos iam surgindo no campo da informática, a SAP ia

R/2 e R/3 não representam versões de um mesmo sistema, tratam-se na verdade de

Os Principais Módulos do SAP R/3 (Copyright by SAP AG).

oferecida aos clientes. O sistema oferece o processamento de informações em verdadeiro tempo

Com as práticas de SAP devidamente estruturadas, do ponto de vista organizacional ,

A resposta a esta questão era relativamente simples: as grandes consultorias possuiam um

Para enfrentar os problemas mais complexos de configuração as consultorias traziam

- Pessoas com experiência em SAP,

- Pessoas com experiência em implementação de pacotes,

- Pessoas com conhecimento de Inglês e

Ao término da academia os formandos eram disputados imediatamente por todas as

SOBRE ESSA APOSTILA:

Essa é uma apostila não oficial da SAP do módulo de ABAP 4 (linguagem

O objetivo dessa apostila é mostrar de forma simples alguns do vários

A utilização das apostilas oficiais da SAP se torna, como sempre foi,

O R/3 segue o princípio administrativo conhecido como DIAMANTE onde

R3 COMO UM SISTEMA ABERTO À COMUNICAÇÃO:

O R/3 utiliza protocolos Standard da indústria para garantir integração com

• TCP/IP: é o protocolo de comunicação difundido mundialmenmte.

Além dos protocolos Standard da indústria o R/3 também utiliza:

• RFC: Remote Function Call, que utiliza o protocolo copiado do CPI-C da

O R/3 possui uma arquitetura modular de software seguindo o princípio da

Esta arquitetura permite que se separe a lógica da aplicação da base de

Os ganhos nesta arquitetura na implementação R/3 são muitos:

Ou seja, o ponto alto da arquitetura é a facilidade para escalar e

Na implementação R/3, a arquitetura client/server é orientada para o

Um servidor de aplicação por exemplo é server de alguns serviços das

R/3 System Client/Server Configurations

Os serviços (ou camadas) fundamentais de uma aplicação são três:

Central, onde todos os componentes estão implementados em um mesmo

Two-tier, onde uma camada normalmente executa as funções de

Um sistema R/3 agrupa todos os componentes que estão associados com

Database Server, é instalado em um host central, onde todos os serviços de

Um ou mais Application Servers conectados ao servidos de banco de dados.

 ários Presentation Servers conectados aos servidores de aplicação. Estas

O software Basis do R/3 (também chamado de middleware) roda em

· Provê o ambiente de runtime para as aplicações R/3

As principais características da tecnologia Basis são:

· É uma arquitetura voltada para a configuração client/server

Basis é o responsável ainda pela integração dos aplicativos e do ABAP

O profissional BASIS é em geral o ‘gerente’ do sistema, sendo responsável

SAP ON LINE SERVICE SYSTEM:

OSS é um service 24 x 7 disponibilizado pela SAP que permite acesso ao

Atualmente a SAP já disponibiliza esse serviço pela Internet. O OSS está

Como a grande maioria (quase totalidade) dos grandes sistemas o SAP/R3

Notas são comunicados/documentos emitidos pela SAP que relatam e

O R/3 é um sistema voltado para clients. Com este conceito é possível

Um client pode ser visto como uma entidade organizacional separada

Mandantes são como unidades independentes dentro de uma mesma

Geralmente temos a seguinte configuração de mandantes: Ambientes de

As alterações no software R/3 podem ser divididas em cinco categorias:

· Customizing: é a configuração dos processos de negócio e funções de

· Personalization: são as mudanças globais das características das telas e

· Modification: são mudanças efetuadas pelo cliente no repositório de

· Enhancement: criação pelo cliente de objetos no repositório que são

Uma change request é um “pacote” contendo os objetos que serão

Todas as alterações efetuadas nos objetos do repositório são criadas e

mecanismos permitem que estas alterações sejam posteriormente propagadas

O workbench organizer oferece mecanismos que permite que os change

UNIDADES LÓGICAS COM SEUS MANDANTES -> DESENHO.