ABAP

ABAP
Workbench
SAP R/3 ®
ABAP Workbench
Release: 4.6C
Instruções para o Aluno

O material de treinamento não se destina ao aprendizado individual. Apenas em
conciliação com as explicações do instrutor o material estará completo.
Autor: Wagner Eduardo Fernandes
Nome : ___________________________________________
Departamento:______________________ Data:___/___/___
Introdução ao ABAP Workbench
Marcas Registradas
SAP e o logotipo SAP são marcas registradas da SAP AG.
MS-DOS e EXCEL são marcas registradas da Microsoft.
OS/2, CICS, MVS, ACF/VTAM, VSE, AIX, OS/400 e AS/400 são marcas registradas
da IBM.
X-Window-System é uma marca registrada da MIT University.
SINIX, UTM e BS2000 são marcas registradas da Siemens.
UNIX é uma marca registrada da AT&T.
HP-UX é uma marca registrada da Hewlett Packard.
DECnet, DECstation, DECsystem, VAXstation e VMS são marcas registradas da
DEC.
Ethernet é uma marca registrada da Xerox Corporation.
ORACLE SQL*net, SQL*+ PRO*C são marcas registradas da ORACLE Corporation.
INFORMIX-OnLine e INFORMIX-ESQL/C são marcas registradas da INFORMIX
Corporation.
Confidencialidade
Este Documento entitulado ‘ABAP Workbench SAP R/3’, desenvolvido para ser
utilizado para treinamento corporativo do ERP SAP R/3, da SAP AG, é de
propriedade exclusiva da ALLIANSYS CONSULTING LTDA, sendo proibida sua
cópia total ou parcial, ou mesmo divulgação sem prévia autorização desta empresa.
 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 2

ÍNDICE
CONFIDENCIALIDADE ............................................................................................................. 2
CAPÍTULO 1 .......................................................................................................................................... 6
NOVIDADES NO ABAP WORKBENCH ........................................................................................... 6

ESTRUTURA DE TELAS NO OBJECT NAVIGATOR ................................................................................ 6
TIPOS DE DADOS LOCAIS EM PROGRAMAS (TYPES) ........................................................................ 10
EXEMPLO DE CODIFICAÇÃO ....................................................................................................... 11
EXERCÍCIOS ....................................................................................................................................... 12
CAPÍTULO 2 ........................................................................................................................................ 13
RELATÓRIOS ..................................................................................................................................... 13
REPORTS (OVERVIEW E TÉCNICAS).................................................................................................. 13
FORMATO DE LISTA DE SAÍDA ........................................................................................................... 14
O COMANDO WRITE ........................................................................................................................ 15
ESPECIFICAÇÃO DE POSIÇÃO E TAMANHO ....................................................................................... 16
SINTAXE DO COMMANDO WRITE .................................................................................................... 17
OPÇÕES DE FORMATO ....................................................................................................................... 18
ATRIBUTOS DE SAÍDA I ..................................................................................................................... 19
ATRIBUTOS DE SAÍDA II.................................................................................................................... 20
ATRIBUTOS DOS CAMPOS DE SAÍDA ................................................................................................... 21
SÍMBOLOS E ÍCONES EM LISTAS ........................................................................................................ 22
RELATÓRIOS INTERATIVOS............................................................................................................... 23
PAGE HEADINGS ................................................................................................................................ 24
LISTAS SECUNDÁRIAS E A VARIÁVEL DE SISTEMA SY-LSIND......................................................... 25
SELEÇÃO DE LINHAS I – UTILIZANDO A VARIÁVEL DE SISTEMA SY-LISEL .................................. 26
SELEÇÃO DE LINHAS II...................................................................................................................... 27
SELEÇÃO DE LINHAS III ................................................................................................................... 28
EXERCÍCIOS ....................................................................................................................................... 29
CAPÍTULO 3 ........................................................................................................................................ 30
ABAP OPEN SQL ................................................................................................................................ 30

EXERCÍCIOS ....................................................................................................................................... 38
CAPÍTULO 4 ........................................................................................................................................ 39
ESTRUTURAS DE PROGRAMAS E DADOS ................................................................................. 39

EXERCÍCIOS ....................................................................................................................................... 46
CAPÍTULO 5 ........................................................................................................................................ 47
MODULARIZAÇÃO E ESTRUTURA DE PROGRAMAS ............................................................ 47

EXERCÍCIOS ....................................................................................................................................... 58
CAPÍTULO 6 ........................................................................................................................................ 59
TABELAS INTERNAS........................................................................................................................ 59
ENTENDENDO OS NOVOS TIPOS DE TABELAS INTERNAS ................................................................... 71
Standard ......................................................................................................................................... 71
Sorted.............................................................................................................................................. 71
Hashed............................................................................................................................................ 71

CONSIDERAÇÕES................................................................................................................................ 72
WORK ÁREA DA TABELA INTERNA ................................................................................................... 73
LOOPING DE LEITURA NA TABELA INTERNA .................................................................................... 78
ACESSANDO ENTRADAS INDIVIDUAIS EM TABELAS INTERNAS ........................................................ 79
MODIFICANDO UMA TABELA INTERNA ATRAVÉS DO ÍNDICE ........................................................... 80
MODIFICANDO UMA TABELA INTERNA ATRAVÉS DE CHAVES ......................................................... 81
DELETANDO UMA TABELA INTERNA ................................................................................................. 82
TABELAS INTENAS COM E SEM HEADER LINE .............................................................................. 83
EXERCÍCIOS ....................................................................................................................................... 84
CAPÍTULO 7 ........................................................................................................................................ 85
MÓDULOS DE FUNÇÃO ................................................................................................................... 85

BAPI .................................................................................................................................................. 97
Definição ........................................................................................................................................ 97
Integração ...................................................................................................................................... 97
BAPIS – INTERFACE COM O SISTEMA R/3 ........................................................................................ 98
BOR ................................................................................................................................................... 98
DEFINIÇÃO ......................................................................................................................................... 98
UTILIZAÇÃO ....................................................................................................................................... 98
INTEGRAÇÃO ...................................................................................................................................... 99
BAPI BROWSER ............................................................................................................................... 100
BAPIS STANDARD ............................................................................................................................ 103
BAPIS IMPLEMENTADAS COMO MÓDULOS DE FUNÇÃO ................................................................ 104
EXERCÍCIOS ..................................................................................................................................... 105
CAPÍTULO 8 ...................................................................................................................................... 106
DIALOG PROGRAMMING – ON-LINE........................................................................................ 106

SCREEN PAINTER - ABAP ............................................................................................................... 107
COMUNICAÇÃO ENTRE OS MÓDULOS .............................................................................................. 108
OVERVIEW: CRIANDO UM DIALOG PROGRAM ............................................................................... 109
CRIANDO PROGRAMAS .................................................................................................................... 110
ATRIBUTOS DO PROGRAMA ............................................................................................................. 111
DEFININDO TELAS ........................................................................................................................... 112
UTILIZANDO CAMPOS DO DICIONÁRIO ABAP................................................................................ 113
DEFININDO ELEMENTOS GRÁFICOS (GRAPHICAL SCREEN PAINTER) .......................................... 114
DEFININDO O FLUXO LÓGICO (FLOW LOGIC)................................................................................ 115
CRIANDO UMA SEQUÊNCIA DE TELAS .............................................................................................. 116
DEFININDO CAMPOS NO MODULE POOL ........................................................................................ 117
CRIANDO MODULES ABAP ............................................................................................................. 118
O PROCESSAMENTO NO THE MODULE POOL .................................................................................. 119
CHAMADAS VIA TRANSAÇÃO ........................................................................................................... 120
SEQUÊNCIA DE AÇÕES ..................................................................................................................... 121
INPUT CHECKS NO MODULE POOL ................................................................................................ 122
COMANDO FIELD E TRANSPORTE DE DADOS ................................................................................ 123
ALTERANDO A SEQUÊNCIA DE TELAS DINAMICAMENTE................................................................. 124
INTERPRETANDO FUNCTION CODES NO PROGRAMA ...................................................................... 125
MENU PAINTER: OVERVIEW ........................................................................................................... 126
DEFININDO INTERFACES I ............................................................................................................... 127
DEFININDO INTERFACES II.............................................................................................................. 128
EXERCÍCIOS ..................................................................................................................................... 129
CAPÍTULO 09 .................................................................................................................................... 130
MODIFICAÇÃO DINÂMICA EM TELAS..................................................................................... 130

EXERCÍCIOS ..................................................................................................................................... 134

CAPÍTULO 10 .................................................................................................................................... 135
TABLE CONTROL ........................................................................................................................... 135

EXERCÍCIOS ..................................................................................................................................... 146
CAPÍTULO 11 .................................................................................................................................... 147
TABSTRIP .......................................................................................................................................... 147

1 – CRIAÇÃO DO PROGRAMA ON-LINE (MODULE POOL)............................................................... 148
2 – CRIAÇÃO DAS TELAS – SCREEN PAINTER ................................................................................. 149
3 – DESENHAR A TELA COM OS TABSTRIPS DESEJADOS. ................................................................. 150
4 – DEFINIR OS ATRIBUTOS DO TABSTRIP........................................................................................ 151
5 – DEFINIÇÃO DA SUBTELA. ........................................................................................................... 152
6 – ASSOCIAÇÃO DAS PASTAS COM A(S) SUBTELAS(S). ................................................................... 153
7 – DEFINIÇÃO DE MAIS PASTAS ...................................................................................................... 154
8 – CRIAÇÃO DA TELA COM OS CAMPOS DE DADOS......................................................................... 155
9 – DEFINIÇÃO DO LAY-OUT DOS CAMPOS DAS TELAS.................................................................... 156
10 – DEFINIÇÃO DOS CONTROLES DO TABSTRIP. ............................................................................ 157
11 – CHAMANDO A EXECUÇÃO DO TABSTRIP.................................................................................. 158
12 – NAVEGAÇÃO PELO TABSTRIP .................................................................................................. 159
13 – TABSTRIP PRONTO.................................................................................................................... 161
EXERCÍCIOS ..................................................................................................................................... 162
CAPÍTULO 12 .................................................................................................................................... 163
SAPSCRIPT........................................................................................................................................ 163
1 – O QUE É SAPSCRIPT E QUANDO UTILIZAR ................................................................................ 163
2 - LIMITAÇÕES E PROBLEMAS DA FERRAMENTA .......................................................................... 163
Programa de Povoamento de SAPscript ................................................................................ 164
Abertura de formulário ............................................................................................................. 164
Inicialização de um formulário ............................................................................................... 166
Seleção dos dados...................................................................................................................... 167
Impressão dos dados nas janelas ............................................................................................ 167
3 - O FORMULÁRIO .......................................................................................................................... 169
3.1. Header ............................................................................................................................. 169
3.2. Parágrafos ...................................................................................................................... 169
3.3. Caracter String .............................................................................................................. 169
3.4. Janelas ............................................................................................................................. 170
3.5. Páginas............................................................................................................................ 171
3.6. Page Windows ................................................................................................................ 171
3.7. Text Elements ................................................................................................................. 171
4 - MANUTENÇÃO DE FORMULÁRIOS............................................................................................... 172
4.1. Criar um formulário novo ............................................................................................ 172
4.2. Copiar formulários em outro idioma (Tradução) ..................................................... 172
4.3. Copiar um formulário de outro cliente ....................................................................... 173
5 - INCLUSÃO DE LOGOS NO FORMULÁRIO ...................................................................................... 173
6 - ALTERAÇÃO DE PROGRAMAS / LAYOUT STANDARDS ............................................................... 174

Capítulo 1
Novidades no ABAP WorkBench
Estrutura de Telas no Object Navigator
Right-Click para mostrar o menu de contexto
Right-Click para
mostrar menu de
Contexto
Tamanho da tela pode ser alterado
• O Object Navigator é dividido em duas áreas:

o Uma área (à esquerda), onde a lista de objetos pode ser mostrada
hierarquicamente.
o A janela de objetos (Object Window – Localizada à direita), na qual os
objetos podem ser mostrados e editados.
A área onde os objetos são mostrados hierarquicamente pode ser fechada utilizando-se o
botão “Close Browser”.
• A lista de objetos para um objeto corrente mostrado na Object Window pode ser
mostrada pressionando-se o botão “Object List”.
• Pode-se escolher funções a partir do menu de contexto em ambas as janelas

(esquerda ou direita).
• Os objetos do repositório são organizados hierarquicamente:

• Cada componente de aplicação consiste de múltiplas classes de

desenvolvimento.
• Cada classe de desenvolvimento pode conter muitos tipos de objetos do
repositório: programas, grupos de função, Objetos do dicionário ABAP,...
• Cada objeto do repositório pode consistir de diferentes tipos de objetos:
Programas podem conter: Dados globais, types, campos, eventos,...
Grupos de função podem conter: Dados globais, módulos de função,...
• Pode-se entrar com o tipo de lista de objetos e o nome na parte superior da

hierarquia. A lista de objetos e então mostrada na área da hierarquia.
• Efetuando-se um doublé-click em um sub-objeto na lista de objetos, expande-se a

hierarquia e mostra-se uma sub-lista hierárquica.
• No caso de um sub-objeto que não possui sub-lista, este mesmo objeto será
mostrado na tela Object Window (direita).
• Pode-se utilizar os ícones para nevegar pelo histórico ou hierarquicamente entre as
listas de objeto.
Lista de objetos Prévia.

Próxima Lista de Objetos
Lista de Objetos de nível mais alto.
Lista de Favoritos, nela pode-se: Adicionar, Processar o objeto, Mostrar o tipo de

objeto, abrindo-se o editor.
Efetuar o Refresh da Lista de Objetos.

Editor
Screen
Painter
• Navegação:
o Efetuando-se um double-click em um programa existente, inicia-se a
ferramenta correspondente no Workbench na Object Window.
o Se o objeto não existir, é possível cria-lo simplesmente efetuando-se um
double-click neste objeto.
• Efetuando-se um Right-click em um objeto existente, é possível executa-lo

diretamente ou executa-lo em Debugging Mode.

Tipos de Dados Locais em Programas (Types)
Definir o
Domínio
As características técnicas dos campos são ainda definidas no domínio.
Características
técnicas
diretamente no
Data Element
A partir da versão 4.6, as características técnicas podem ser definidas diretamente no data
element, sem que haja a necessidade de criação de domínios.

TYPES: <user_defned_type> TYPE <type>

Navega para a
Double declaração local do Data
-click Type ou para a
Declaração do Type no
dicionário ABAP
DATA: <data_object> TYPE <type>
Quando da definição de types ou variáveis, você pode referenciar types pré-definidos.

Para mais informações à documentação, utilize como referência as palavras-chave TYPE ou
DATA.
Os typos pré-definidos são:
• C – Caracter
• N – Numérico
• D – Data (YYYMMMDD)
• T – Time (HHMMSS)
• X – Byte (Hexadecimal)
• I – Inteiro
• P – Packed
• F – Ponto Flutuante
• STRING – Caracter tipo string
• XSTRING – Hexadecimal para imagens.
Exemplo de Codificação

Exercícios
Utilize este espaço para colocar observações a respeito dos exercícios propostos pelo
instrutor.

Capítulo 2
Relatórios
Reports (Overview e Técnicas)
Output statements, WRITE... .

formatting options
FORMAT... .
NEW-PAGE... .
Events TOP-OF-PAGE.
TOP-OF-PAGE.
END-OF-PAGE.
Text elements
Text symbols
Headings
Selection texts
System fields
Acima podemos observar os comandos que geram as listas para impressão, bem como
eventos e elemtneos de textos utilizados.

Formato de lista de saída
DEMO/CHAP 02.A WRITE 1
*******************************************
Date 17.10.2001 Time 14:46:10
*******************************************
O comando WRITE gera uma lista de saída.
Por default, a lista consiste em uma página contínua.
Também por default, o ABAP gera duas linhas HEADER. O título da lista e o cabeçalho da
lista (se disponível) aparecece no topo à esquerda, enquanto que o número da página
aparece no topo, ao lado direito. Estes valores permanecem válidos quando o relatório é
“rolado” pela tela.

O comando WRITE
REPORT RSBBB02A.
.
.
.
WRITE: '*************'(001).
SKIP 2.
WRITE: 'Date'(002),
SY-DATUM.
WRITE: 'Time'(003), DEMO/CHAP 02.A WRITE 1
SY-UZEIT.
SKIP 2. ******************************************
WRITE: '*************'(001).
Date 17.10.2001 Time 14:46:10
*******************************************
O comando WRITE gera a saída do conteúdo de um campo, ou uma constante, de acordo

com o seu tipo básico.
Sucessivos WRITEs geram saída em uma mesma linha. Quando uma linha é completa, a
saída continua na próxima linha. Por default, dois campos que seguem um ao lado do outro
devem ser separados por um branco. Você pode usar a adição NO-GAP para suprimir a
impressão dos caracteres em branco.

Especificação de Posição e Tamanho
REPORT RSBBB02B.
WRITE: 5 '***************'(001).
SKIP.
WRITE: 5 'Date'(002),
20 SY-DATUM.
WRITE: /5 'Time'(003),
20 SY-UZEIT. DEMO/CHAP 02.B WRITE 1
ULINE /5(30) .
SKIP 2. ************************************
ULINE.
Date 10/17/1995
Time 16:18:38
_________________________
Coluna 5 Coluna 20
Você pode especificar um formato para o valor de saída. Este permite você definir uma
quabra de linha, a linha inicial e o tamanho da saída.
O aditivo ULINE produz uma linha sólida.

Sintaxe do commando WRITE
WRITE <format> <value> <options>.
<format> WRITE AT <format> <value> <options>.
<value>
/p(l)
/ Quebra
p Pos. da coluna Valor saída
l Tamanho saída Campo ou literal
<options>
Opções de formato
É necessário passar algumas informações adicionais ao comando WRITE como:
A posição da coluna, através de um valor de até 3 dígitos ou uma variável que respeite este
tamanho, usando o parâmetro acicional AT.
Você pode omitir especificações de formato inteiramente ou especificações individuais de

formato.
A ordem das cláusulas deve ser respeitada.

Opções de Formato
REPORT RSBBB02C.
DATA: DATUM TYPE D,
TIME TYPE T.
DATUM = SY-DATUM.
TIME = SY-UZEIT. DEMO/CHAP 02.C 1
WRITE: 5 'Datum'(001),
20 DATUM DD/MM/YYYY. ************************************
WRITE: /5 'Time'(002), Date 10/17/95
(8) TIME USING EDIT MASK Time 07:08:17
’_ _:_ _:_ _’ _________________________
UNDER DATUM.
Coluna 5 Coluna 20
Para formatar um campo data, você deve utilizar a opção DD/MM/YYYY. Para formatar um
campo de data sem o formato DD/MM/YYYY, você deve especificar o tamanho da saída do
campo, inclusive os caracteres de formatação (/), por exemplo.
Através da opção de formatação UNDER, você garante o posicionamento abaixo do campo

relacionado (posição relativa).
Para definir a posição dos campos, você pode usar os parâmetros LEFT-JUSTIFIED, RIGHT-
JUSTIFIED e CENTERED. O default é: campos numéricos são posicionados RIGHT-
JUSTIFIED e todos os outros, LEFT-JUSTIFIED.
Utilizando USING EDIT MASK, você pode especificar um template de formato. O underscore
indica como posição de saída . O sistema imprime diretamente qualquer outro caracter usado
no template.

Atributos de Saída I
REPORT RSBBB02E.
FORMAT INTENSIFIED OFF.
WRITE: 5 '*************'(001).
SKIP 2.
WRITE: 5 'Date'(002).
FORMAT INTENSIFIED.
WRITE: 20 SY-DATUM DD/MM/YYYY.
DEMO/CHAP 02.E 1
FORMAT INTENSIFIED OFF.
WRITE: /5 'Time'(003). ************************************
Date 17.10.1995
Time 16:18:38
_________________________
O comando FORMAT determina como os dados irão aparecer na tela.
Em qualquer formato de tela, você deve setar através do comando FORMAT os comandos
WRITE que aparecem na nova linha adiante.
O comando FORMAT tem as seguintes opções:

INTENSIFIED display highlight
INPUT entrada
COLOR <n> seta a cor do background
INVERSE influencia a cor do foreground e background
Usando o parâmetro OFF, você pode desligar qualquer opção.
Os valores abaixo são default:
: INTENSIFIED
INPUT OFF
COLOR OFF.
Usando a adição RESET, você pode resetar todos os formatos: INTENSIFIED
OFF COLOR OFF INPUT OFF.

Atributos de Saída II
REPORT RSBBB02F.
TABLES: SPFLI, SFLIGHT.
DATA: TOTAL LIKE SFLIGHT-PAYMENTSUM.
DEMO/CHAP 02.06 1
GET SPFLI FIELDS ... .
CAR ID from to
FORMAT COLOR COL_KEY. Date Sales
WRITE: /SPFLI-CARRID, AA 0017 NEW YORK SAN FRANCISCO
SPFLI-CONNID. 10/29/1995 6.466,70
11/11/1995 13.100,07
... 11/16/1995 24.500,13
GET SFLIGHT FIELDS ... . ...
FORMAT COLOR COL_NORMAL.
WRITE: SFLIGHT-FLDATE. Total sales for flight AA 0017 112.633,93
FORMAT COLOR COL_TOTAL INTENSIFÌED OFF.

WRITE: 40 SFLIGHT-PAYMENTSUM.
TOTAL = TOTAL + SFLIGHT-PAYMENTSUM.
As listas seguintes mostram as sete cores que você pode usar em relatórios. Você ativa
estas cores especificando um valor numérico ou um nome simbólico. Você pode deixar
“highlight” os elementos para facilitar a legibilidade.
FORMAT COLOR...
OFF or COL_BACKGROUND Background
1 COL_HEADING Heading
2 COL_NORMAL Corpo
3 COL-TOTAL Total
4 COL_KEY Chave
5 COL-POSITIVE Valores positivos
6 COL_NEGATIVE Valores
Negativos
7 COL_GROUP Níveis de grupo
Você pode especificar o ON, OFF e <n> (para COLOR) dinamicamente utilizando
sintaxe diferente, por exemplo:
DATA: C TYPE I VALUE 5.
FORMAT INTENSIFIED ON COLOR = C.

Atributos dos campos de saída
WRITE <field> <format1> <format 2> ... .
REPORT RSBBB02G.
TABLES: SPFLI, SFLIGHT.
PARAMETERS: LIMIT LIKE SFLIGHT-PAYMENTSUM.
GET SPFLI FIELDS CARRID CONNID.

WRITE : / SPFLI-CARRID COLOR COL_KEY ,
SPFLI-CONNID COLOR COL_KEY .
...
GET SPFLI LATE.
...
IF TOTAL GE LIMIT.
WRITE TOTAL COLOR COL_POSITIVE .
ELSE.
WRITE TOTAL COLOR COL_TOTAL .
ENDIF.
...
Usando o comando WRITE, você pode especificar atributos para um valor de saída. Os
atributos de saída são os mesmos que os do comando FORMAT.
As especificações do comando WRITE são aplicadas somente aos valores associados à este
comando. A formatação da linha sofre um overwrite.

Símbolos e Ícones em Listas
WRITE <field> AS SYMBOL. WRITE <field> AS ICON.
REPORT RSBBB02I.
TABLES SCUSTOM.
INCLUDE <SYMBOL> .
SELECT * FROM SCUSTOM DEMO/CHAP 02.I Symbols 1

ORDER BY PRIMARY KEY.
WRITE: / SCUSTOM-ID, 1 SAP AG
/ SCUSTOM-NAME, 69190 Walldorf
06227/34-0
...
/ SYM_PHONE AS SYMBOL, 2 John Smith
SCUSTOM-TELEHONE. 69190 Walldorf
SKIP. 06227/12345
ENDSELECT.
Usando a adição AS SYMBOL do comando WRITE, você pode usar símbolos em relatórios.
Os nomes dos símbolos utilizados são definidos no programa include <SYMBOL>.
Com o comando WRITE <f> AS ICON você pode incluir ícones em relatórios, você irá
precisar do programa include <ICON> declarado em seu programa. Note que nem
todos os ícones podem ser impressos em listas. Ver include <LIST>.
Para um overview de todos os símbolos disponíveis, veja a documentação

disponível. Você deve acessar os ícones pelos seus nomes previamente definidos.

Relatórios Interativos.
Eventos
Report RSDEMO00.
* Basic list
START-OF-SELECTION.
GET ... .
END-OF-SELECTION.
TOP-OF-PAGE..
* Interactive Reporting
AT PFnn.
AT LINE-SELECTION.
AT USER-COMMAND.
TOP-OF-PAGE DURING LINE-SELECTION
O relatório Interativo permite que seja gerada uma segunda lista, ou seja um segundo
relatório, a partir de um evento efetuado em uma linha deste relatório (drill-down).
Este evento pode ser destinado a várias linhas ao mesmo tempo, utilizando-se o evento AT
PF <função> , como pode também ser sensível ao double-click, neste caso utilizamos o
comando AT LINE-SELECTION.
Pode também ser utilizado o comando AT USER-COMMAND ao invés do AT PF <função>.
Algumas facilidades são criadas com o drill-down, como por exemplo o evento TOP-OF-
PAGE DURING LINE-SELECTION, o qual é utilizado para formatar cabeçalhos em listas
secundárias.

Page Headings
Text element
Basic list
REPORT RSBBB06C.
.
:
TOP-OF-PAGE DURING LINE-SELECTION.
Choose :
TOP-OF-PAGE.
Secondary list
O evento TOP-OF-PAGE ocorre quando criamos uma lista básica.

Para criarmos uma lista secundária (drill-down), o sistema dispõe do evento TOP-OF-PAGE
DURING LINE-SELECTION para criar cabeçalhos para as listas secundárias, pois o sistema
não habilita cabeçalhos para listas secundárias, como foi explicado anteriormente.

Listas Secundárias e a variável de sistema SY-LSIND
REPORT RSBBB06A.
Basic list
GET SFLIGHT. SY-LSIND:0
:.
Choose
AT LINE-SELECTION. 1. Secondary
CASE SY-LSIND . list
SY-LSIND:1
WHEN '1'.
:. Choose
2. Secondary 3. Secondary
WHEN '2'.
list list
:.
WHEN '3'.
SY-LSIND:2
SY-LSIND =
SY-LSIND - 1. Choose
:.
Uma lista pode gerar até 20 níveis de drill-down. Para os seguintes níveis de lista, você pode
utilizar as mesmas funções como as utilizadas para as listas básicas (Scroll, Print). Utiliza-se
o Ícone BACK ou EXIT para voltar aos níveis inferiores, a partir das listas secundárias.
A variável de sistema SY-LSIND contém o índice (correspondente ao nível) do report que

está sendo criado. O sistema soma 1 à variável no início do processamento do bloco
interativo. Você pode distinguir o processo para diferentes níveis, utilizando o comando
CASE, por exemplo.
Quando a variável de sistema SY-LSIND é alterada, você pode formatar o tipo de saída que
pode variar, de acordo com o tipo de relatório que pertence a cada nível de drill-down.

Seleção de linhas I – Utilizando a variável de sistema SY-LISEL
Carrid Connid Flight date
AA 0169 12121994
AA 0192 26081994 AT LINE-SELECTION.
LH 0108 25011995 MOVE: SY-LISEL(3) TO SFLIGHT-CARRID,
SY-LISEL+6(4) TO SFLIGHT-CONNID,
Choose SY-LISEL+14(8) TO SFLIGHT-FLDATE.
SELECT * FROM SBOOK
WHERE CARRID = SFLIGHT-CARRID
AND CONNID = SFLIGHT-CONNID
AND FLDATE = SFLIGHT-FLDATE.
LH 0108 25011995
SY-LISEL
WRITE : SBOOK-PRICE ,.......
Usuários freqüentemente querem selecionar a linha em uma lista corrente e mostrar dados
adicionais para aquela linha correspondente. Para prover o dado correspondente para a
respectiva linha, você pode usar a variável de sistema SY-LISEL. A linha selecionada é
automaticamente transferida para a variável SY-LISEL. O conteúdo da variável SY-LISEL é
então utilizada para recuperar dados adicionais.

Seleção de Linhas II
HIDE <field>.
Hide area
Carrier Flight no. Flight date
"SFLIGHT-CARRID" AA
AA 0169 12121994 "SFLIGHT-CONNID" 0169
LH 0454 17111994 "SFLIGHT-FLDATE"
12121994
"SFLIGHT-CARRID" LH
"SFLIGHT-CONNID" 0454
Choose
"SFLIGHT-FLDATE"
17111994
REPORT RSBBB06C.
..
GET. SFLIGHT.
WRITE: SFLIGHT-CARRID,18 SFLIGHT-CONNID,
... .
HIDE: SFLIGHT-CARRID, SFLIGHT-CONNID,
SFLIGHT-FLDATE.
Você pode utilizar o comando HIDE para “esconder”o conteúdo do campo que deverá ser
utilizado como chave para gerar uma nova lista. Estes campos declarados no HIDE são
armazenados em uma área especial. O sistema armazena para cada campo, seu nome e
valor.

Seleção de Linhas III
HIDE <field>.
Hide area
SY-LISELFlight no. Flight date
"SFLIGHT-CARRID" AA
Carrier "SFLIGHT-CONNID" 0169
0000000015
AA 0169
0001
12121994 "SFLIGHT-FLDATE"
LH 0454 17111994 12121994
"SFLIGHT-CARRID" LH
.. "SFLIGHT-CONNID" 0454
.
"SFLIGHT-FLDATE"
Choose
17111994
LH 0454 17111994
SY-LISEL
LH 0454 17111994 ?
SFLIGHT SFLIGHT SFLIGHT SFLIGHT-PRICE
-CARRID -CONNID -FLDATE REPORT RSBBB06C.
AT LINE-SELECTION.
SELECT
SELECT ** FROM
FROM SBOOK
SBOOK WHERE...
WHERE... .
WRITE: SBOOK-CARRID SBOOK-CONNID, ...
Quando o usuário selecionar uma linha e ativar a tecla de função, o sistema executa a
seguinte sequencia automaticamente antes de processar o bloco correspondente:
A variável de sistema SY-LISEL é preenchida com o conteúdo da linha selecionada. O

conteúdo do campo, disponível na área HIDE é utilizado para selecionar o conteúdo de
alguma seleção posterior.

Exercícios
instrutor.

Capítulo 3
ABAP Open SQL
O banco de dados de um programa ABAP pode ser acessado pelo Open SQL ou pelo
Native SQL.
As instruções do Open SQL são um subconjunto do Standard SQL totalmente integrado na

linguagem ABAP. Permitem ao usuário acessar o banco de dados de maneira uniforme a
partir dos programas, independentemente do sistema de banco de dados em uso. As
instruções do Open SQL são convertidas em instruções do Standard SQL específicas do
banco de dados pela interface do banco de dados. O Open SQL contém a Linguagem de
Manipulação de Dados (DML), parte do Standard SQL, que permite ler e modificar os
dados. A Linguagem de Definição de Dados (DDL) e a Linguagem de Controle de Dados
(DCL), partes do Standard SQL, são controladas pelo ABAP Dictionary e pelo conceito de
autorização, respectivamente, os quais unificam e ampliam as funções oferecidas pelos
vários sistemas de banco de dados.
O Open SQL contém instruções DML SELECT, UPDATE, INSERT, DELETE e MODIFY. O
usuário não deve modificar as entradas do banco de dados sem antes entender o conceito
de transação SAP (consultar o capítulo Conceito de Transação deste curso). As instruções
do Open SQL definem um valor no campo código de retorno SY-SUBRC. Se SY-SUBRC = 0,
a operação foi bem sucedida. Se SY-SUBRC <> 0, a operação não teve sucesso.
The R/3 Client/Server Architecture

Presentation
Application
ABAP ABAP
Database
FIGURA024 – Arquitetura Client/Server

Open SQL Statements: Overview

Open SQL: Only DML (Data Manipulation Language)
INSERT
UPDATE
SELECT
DELETE
MODIFY
ABAP Dictionary: DDL (Data Definition Language)
FIGURA025 – SQL Overview
SELECT Statement: Overview
Which columns? SELECT <result> FROM <table> W hich table(s)?

INTO <target> Where to?
WHERE <Condition> W hich lines?
Single line
} Multiple lines
}
Particular
column
R
 SAP AG
FIGURA026 – Statements Overview

Native SQL está conectado ao ABAP de forma bem genérica. Permite ao usuário aplicar
todas as funções oferecidas pela interface de programação do sistema do banco de dados
que esteja sendo usado. Diferentemente das instruções do Open SQL, as instruções do
Native SQL não são verificadas e convertidas pela interface do banco de dados. Em vez
disso, passam diretamente ao sistema do banco de dados, ou seja, os programas escritos
usando o Native SQL são específicos do banco de dados. Convém não usar o Native SQL
para escrever aplicações do sistema R/3.
FIGURA027 – SQL Nativo
A instrução SELECT do Open SQL deve ser usada para ler dados do banco de dados.
Subjacente à instrução SELECT existe uma lógica complexa que permite acesso a muitos
tipos diferentes de tabelas do banco de dados.
A instrução contém uma série de cláusulas, cada qual com uma tarefa diferente:
A cláusula SELECT especifica se o resultado da seleção deve ser uma linha simples ou
várias linhas; se os campos que devem ser incluídos no resultado; se o resultado poderá
conter duas ou mais linhas idênticas.
A cláusula INTO especifica o objeto de dados interno do programa no qual o usuário deseja
colocar os dados selecionados.
A cláusula FROM especifica a origem dos dados (tabela do banco de dados ou visão).
A cláusula WHERE especifica as condições que devem ser atendidas por uma entrada de
tabela para ser incluída no resultado.

FIGURA028 – Sintaxe Comando SELECT
A instrução SELECT SINGLE permite ao usuário ler uma linha simples de uma tabela do
banco de dados. Para garantir a leitura de uma única entrada, é preciso especificar todos os
campos-chave da cláusula WHERE.

Using the SELECT Statement for a Single Line

SELECT SINGLE <f1> .. <fn> FROM <dbtab> ...
... INTO <wa>
... INTO (<f1>, ..., <fn>)
... INTO CORRESPONDING FIELDS OF <wa>
WHERE <key1> <op> ... AND <key2> <op> ...
Table fields and work area fields have the same names
DATA wa_spfli LIKE spfli.
SELECT SINGLE
Tabelle SPFLI carrid connid airpfrom airpto
FROM spfli
INTO CORRESPONDING FIELDS OF wa_spfli
WHERE carrid = 'LH' AND connid = '400'.
FIGURA029 – SELECT SINGLE
Sendo usada a adição CORRESPONDING FIELDS OF na cláusula INTO, o usuário pode

preencher a área-alvo de trabalho, componente por componente. O sistema apenas
preenche aqueles componentes que têm nomes idênticos às colunas da tabela do banco de
dados. Se essa adição não for utilizada, o sistema preenche a área de trabalho a partir do
lado esquerdo, desconsiderando sua estrutura. Caso o sistema encontre uma entrada de
tabela condizente com essas condições, SY-SUBRC tem valor 0.
Caso o operador não use a adição SINGLE na cláusula SELECT, o sistema lê todas as
entradas da tabela que satisfaçam o critério da cláusula WHERE. O programa ABAP lê os
dados, linha por linha, na área-alvo em um loop. Deve-se usar a instrução ENDSELECT para
marcar o final do loop.

Using the SELECT Statement for Several Lines

SELECT <f1> .. <fn> FROM <dbtab> ...
... INTO <wa>
... INTO (<f1>, ..., <fn>) SELECT loop
... INTO CORRESPONDING FIELDS OF <wa>
WHERE <tabfeld> <operator> <value>.
ENDSELECT.
Fills work area
DATA wa_spfli LIKE spfli.
SELECT carrid connid airpfrom airpto

Table SPFLI
INTO CORRESPONDING FIELDS OF wa_spfli
FROM spfli WHERE ...
Statements for every entry read
ENDSELECT.
R
 SAP AG
FIGURA030 – SELECT - ENDSELECT
Todas as instruções entre SELECT e ENDSELECT são executadas para cada entrada do
banco de dados que é lida. Quando o sistema seleciona pelo menos uma entrada, SY-
SUBRC = 0. Depois que a instrução SELECT tiver sido executada em cada passo do loop, o
campo de sistema SY-DBCNT contém o número de linhas lido. Depois da instrução
ENDSELECT, esse campo conterá o número total de linhas lido.
O sistema permite ler, de uma só vez, os dados da tabela do banco de dados para uma
tabela interna usando a instrução SELECT … INTO TABLE (busca de matriz).

Using the SELECT Statement for an Internal Table

SELECT <f1> .. <fn> FROM <dbtab>
INTO TABLE <itab>
WHERE ...
ABAP
Internal
table
Reads all data

records specified in
the W HERE condition
from the database
Table SPFLI
 SAP AG
FIGURA031 – SELECT INTO TABLE

O sistema não utiliza um loop para ler os dados para uma tabela interna. Assim, não é
preciso usar uma instrução ENDSELECT. Quando o sistema consegue ler pelo menos uma
entrada da tabela, SY-SUBRC = 0. Utilizar uma busca de matriz é, quase sempre, mais
eficiente do que ler as entradas da tabela em um loop e anexá-las a uma tabela interna.
FIGURA032 – SELECT com a Cláusula INTO TABLE
O usuário especifica quais os registros de dados que devem ser lidos do banco de dados
usando a cláusula WHERE. O sistema permite digitar apenas os nomes dos campos da
tabela do banco de dados a serem lidos na cláusula WHERE.
O nome da tabela do banco de dados a ser acessado encontra-se na cláusula FROM

(exemplo de uma instrução correta: SELECT ... FROM spfli WHERE carrid = ... ; exemplo de
uma instrução incorreta: SELECT ...FROM spfli WHERE spfli-carrid = ... ) e <value> pode ser
qualquer objeto de dados: literal, uma constante ou um campo. Várias condições lógicas
podem ser acrescentadas à cláusula WHERE usando-se AND ou OR.

Exercícios
instrutor.

Capítulo 4
Estruturas de Programas e Dados
O conceito de categoria do ABAP permite ao usuário diferenciar claramente entre

categorias de dados e objetos de dados. Categorias de dados e objetos de dados
ocupam dois intervalos de nomes diferentes, ou seja, um nome pode significar tanto
uma categoria de dados quanto um objeto de dados.
A atribuição de categorias de objeto de dados é feita pela referência do objeto a uma

categoria ABAP predefinida, a uma categoria definida pelo usuário ou a um objeto
do Dictionary. O sistema também permite referir o objeto a um outro objeto de dados
existente. Neste caso, todos os atributos da categoria são herdados pelo novo objeto
de dados.
As categorias de dados definidas pelo usuário podem ser elementares ou

estruturadas. As categorias de dados elementares não podem ser divididas em
outros componentes. Por outro lado, as categorias de dados estruturadas são
compostas livremente de categorias de dados elementares e estruturadas. Nas
categorias de dados estruturadas existe uma diferença entre categorias de
estruturas e categorias de tabelas:
• Categorias de estruturas (conhecidas como estruturas ou registros em outras
terminologias) podem ter componentes de qualquer categoria.
• Categorias de tabelas (conhecidas como matrizes em outras terminologias)
podem ter linhas de qualquer tipo.
No nível mais elevado, categorias de estruturas e categorias de tabelas podem
conter em si outras categorias de estruturas e de tabelas.
P r e d e fin e d D a ta T y p e s Predefined
Data type
User-defined
(P,I,F,C,N,D,T,X)
Elementary Structured
Structured type Table type
D a ta ty p e M e a n in g In it ia l v a lu e S ta n d a r d P e r m it te d
le n g th le n g th
P packed num ber 0 8 1 -1 6

numeric
I in t e g e r 0 4 4
F f lo a t in g p o in t n o . 0 .0 0 0 ... 8 8
N n u m e r ic t e x t 0 0 ...0 1 1 -m a x .
C
alphanumeric
te x t b la n k 1 1 -m a x .
D d a te (Y Y Y Y M M D D ) 00000000 8 8
T t im e ( H H M M S S ) 000000 6 6
X h e x a d e c im a l X '0 0 ' 1 1 -m a x .
R
 SAP AG
FIGURA066 – Data Types

No ABAP existem oito categorias de dados predefinidos. As categorias de dados

numéricos P, I e F têm as seguintes propriedades e intervalos de valores:
Categoria propriedade interv. valor adequada para

I nº inteiro -231 a +231 contadores, quantidades,
índices,
prazos
P nº decimal 2 carac. por byte moedas , comprimentos, pesos
F pto. flutuante -2,2E-308 a +1,8E308 cálculo em um intervalo de
valor muito grande
Os cálculos com números da categoria I são os mais econômicos; em seguida vêm

as categorias F e P. Mas deve-se observar que a aproximação pode induzir a erros
com números da categoria F. Especificamente, desaconselha-se comparar dois
números dessa categoria (ponto flutuante). Em vez disso, é preciso verificar se a
diferença entre os dois fica dentro de uma tolerância aceitável. Números com ponto
flutuante devem ser usados apenas para problemas matemáticos nos quais possam
ser aceitos erros de aproximação. Para problemas comerciais, em geral usa-se a
categoria P.
Nas categorias de números P, dois dígitos são armazenados em cada byte. A última
metade do byte é usada para o sinal de menos ou mais.
Nas categorias de dados P,N,C e X, o sistema permite digitar um comprimento entre

parênteses depois do nome da categoria. O comprimento default das categorias
será usado se o campo "comprimento" estiver em branco.
Na categoria de dados P, é possível usar o suplemento DECIMALS para determinar

o número de casas decimais a ser usado (máximo = 14). Se nenhuma categoria for
informada, automaticamente o campo será de categoria C.
Cada campo elementar se apresenta de modo standard, com um valor inicial

adequado à sua categoria. O usuário pode definir um valor de início para um campo
elementar usando o suplemento VALUES. Com VALUES o sistema permite apenas
a especificação de um objeto de dados fixo.
Regras para dar nomes aos objetos de dados:

• Um nome pode ter 30 caracteres, no máximo (letras, números ou símbolos).
• Os seguintes símbolos NÃO são permitidos: ( ) + . , :
• SPACE é uma constante predefinida.
Definir categorias de estruturas usando a sintaxe TYPES: BEGIN OF <type>, ... ,

END OF <type>. Os componentes da estrutura podem ser definidos como um objeto
de dados: o usuário define o comprimento e a categoria. As categorias de estrutura
podem conter outras categorias de estrutura ou categorias de tabelas.

Por uma questão de compatibilidade, também se pode definir estruturas utilizando

DATA: BEGIN OF <rec>, ..., END OF <rec> sem ter de declarar uma categoria de
estrutura.
Regras para nomear estruturas:

• Um nome pode ter 30 caracteres, no máximo (letras, números ou símbolos).
• Os nomes não podem conter apenas números.
• Recomendações: Como caractere inicial, utilizar sempre uma letra; em
nomes compostos, utilizar uma sublinha.
Uma tabela interna é uma sequência de linhas de mesmo tipo. As categorias de

tabelas podem conter outras categorias de tabelas ou de estruturas. Para saber
como definir as categorias de tabelas, consulte o capítulo Tabelas internas ou a
documentação da palavra-chave TYPES.
Objetos de dados e categorias definidas pelo usuário também podem ser definidos
mediante consulta aos objetos do ABAP Dictionary. O suplemento LIKE com as
instruções DATA e TYPES deve ser usado para fazer referência a um objeto do
ABAP Dictionary.
• Sempre que um objeto do ABAP Dictionary é modificado, todos os objetos de
dados e categorias definidas pelo usuário que fazem referência a esse objeto
são alterados para refletir tais modificações.
O usuário pode definir categorias de dados em um grupo de categorias no ABAP
Dictionary em vez de defini-las no programa ABAP. O nome do grupo de categorias
no ABAP Dictionary tem 5 caracteres, no máximo. Os nomes das categorias no
grupo de categorias <typepool> devem iniciar com <typepool> seguido por uma
sublinha. As categorias de um grupo de categorias devem ser declaradas nos
programas ABAP com o comando TYPE-POOLS.
A instrução PARAMETERS é um elemento de linguagem declarativa para

estabelecimento de campos internos do relatório. A diferença entre as instruções
PARAMETERS e DATA está em que os campos declarados usando PARAMETERS
são apresentados para entrada na tela de seleção.
Utilizando a instrução PARAMETERS, o sistema permite utilizar as adições TYPE e

LIKE, assim como quando é utilizada a instrução DATA. Similarmente à forma com
que se usa VALUE com DATA para atribuir um valor inicial, o sistema permite usar o
suplemento DEFAULT com a instrução PARAMETERS para definir um valor default
para o campo. Este valor pode ser uma literal, uma constante ou um campo de
sistema que toma o seu valor do sistema no momento em que o relatório é
processado (por exemplo, sy-datum).
A instrução TABLES declara um objeto de dados interno que atua como uma
interface de tela sempre que os campos da tela se referirem ao mesmo objeto do
Dictionary. TABLES deve ser usada para definir uma área de trabalho apropriada no
programa ABAP para aqueles dados que o usuário digita em uma tela ou que são
passados à tela pelo programa.

As constantes são definidas através da palavra-chave CONSTANTS do ABAP. As

constantes exigem o suplemento VALUE pois este define os seus valores. O ABAP
reconhece duas categorias de literais: os literais numéricos e os literais de texto,
sendo que estes últimos estão sempre entre aspas simples (‘).
Números inteiros (precedidos por sinal de menos, se negativos) são armazenados

como literais numéricos sob as categorias I (até nove dígitos, inclusive) ou P (dez
dígitos ou mais). Todos os outros literais (caracteres, números decimais, números
com ponto flutuante) são armazenados como literais de texto sob a categoria de
dados C.
Se necessário, o processador ABAP executa uma conversão de categoria (consulte

a transparência sobre conversão de categoria). Para inserir um sinal de aspas
simples (‘) em um literal de texto é preciso digitá-lo duas vezes. Símbolos de texto
são literais de texto.
Símbolos de texto são um outro tipo de literal. Ao contrário dos literais de texto
simples, os símbolos de texto têm a vantagem de poder ser traduzidos. Os símbolos
de texto permitem retirar textos do texto fonte para armazená-los em outro lugar,
onde possam ser mais facilmente alterados para objetos como listas independentes
de linguagem.
O sistema permite endereçar símbolos de texto em um programa de uma das duas

formas:
• TEXT-<xxx> (xxx = sequência de caracteres de três dígitos)
• '<Text>'(<xxx>) (xxx = sequência de caracteres de três dígitos)
A criação de símbolos de texto pode ser feita usando Forward Navigation ou o

Repository Browser sob Elementos de texto. Até este ponto, conhecemos as
seguintes instruções declarativas:
TYPES Definição da categoria

DATA Definição dos campos elementares, cadeias de campo e tabelas internas
CONSTANTS Definição de constantes
PARAMETERS Definição de parâmetros de entrada
TABLES Definição de áreas de trabalho de tabelas
No capítulo Tabelas internas, assim como no subcapítulo sobre Telas de seleção do

capítulo Diálogos, o texto disserta sobre a seguinte instrução declarativa:
SELECT-OPTIONS Definição das opções de seleção
O sistema exibe uma síntese das instruções declarativas do ABAP pressionando-se

o botão Editor "i" e selecionando-se ABAP Overview, Síntese da Linguagem de
programação ABAP Classificação das palavras-chave por categoria.

A instrução CLEAR é usada para restaurar qualquer objeto de dados variável ao

valor inicial, adequado a esta categoria. Nas estruturas, cada componente individual
é restaurado. As tabelas internas são restauradas, componente por componente,
linha por linha, aos seus valores iniciais, adequados a esta categoria.
Existem várias instruções do ABAP com as quais é possível atribuir valores a

objetos de dados. A mais importante delas é a instrução MOVE. Se não houver
correspondência entre as estruturas e as categorias dos objetos de dados, é porque
existem regras de conversão de categoria.
As instruções MOVE-CORRESPONDING <rec1> TO <rec2> transportam os valores,

campo a campo, entre as estruturas <rec1> e <rec2>. Isto funciona apenas se os
componentes tiverem nomes idênticos.
O sistema procura em todos os campos do <rec1> os nomes que também ocorrem

em <rec2> e transporta o campo <rec1>-<field name> para <rec2>-<field name> em
todos os casos em que houver concordância. Todos os outros campos permanecem
inalterados.
Se o usuário relacionar uns com os outros objetos de dados de categorias

diferentes, ABAP executa uma conversão de categoria, desde que tenha sido
definida uma regra de conversão para as categorias em questão.
Uma síntese abrangente das regras de conversão para categorias elementares pode
ser encontrada na documentação on-line do comando DATA. Os campos de
categoria C são gravados com justificação à esquerda. Usando-se "converter para
campos da categoria C", o campo é preenchido com espaços em branco se for muito
curto e truncado se for muito longo (ver os exemplos 1 e 2, acima).
Ao converter um campo de categoria C em campo de categoria P, o sistema permite

apenas dígitos, sinal de menos ou mais e o ponto decimal (ver o exemplo 3, acima).
O sistema permite converter um campo compactado em campo de categoria C: os
zeros precedentes são convertidos em espaços (ver o exemplo 4, acima).
O sistema ABAP tem regras para conversão de:

• estruturas em estruturas
• campos elementares em estruturas
• estruturas em campos elementares
As tabelas internas podem ser apenas convertidas em outras tabelas internas. Em

seguida, os tipos de linha adequados são convertidos.

A palavra-chave COMPUTE é opcional. O sistema permite agrupar expressões em

parênteses, o quanto possível. Os operadores e os parênteses que fazem parte das
expressões valem por uma palavra. Assim sendo, devem estar separados por
espaços. Entretanto, o parêntese de abertura não deve estar separado do nome da
função, por exemplo: SQRT( ... )
Errado: a = (B+EXP(C))*E/SIN(3-G).
Certo: a = ( B + EXP( C ) ) * E / SIN( 3 - G ).
Existe uma aritmética separada no processador do ABAP para cada uma das
categorias de dados P, I e F. Uma expressão aritmética é calculada usando-se
apenas uma aritmética simples. A hierarquia que determina qual aritmética será
usada é a seguinte: I, P, F. Os operadores e o campo do resultado passam para a
determinação da aritmética (ver RSAAA04K).
O retorno dos operadores DIV e MOD é sempre um número inteiro (ver a
documentação on-line de COMPUTE). O retorno da função STRLEN é o
comprimento de uma cadeia. Na documentação on-line de COMPUTE encontra-se
uma síntese de todas as funções. Para as operações aritméticas simples, o sistema
permite usar formas abreviadas de ADD, SUBTRACT, MULTIPLY e DIVIDE.
O sistema permite endereçar e modificar sub-áreas de um campo elementar

especificando o offset e o comprimento. Não se deve usar offset e comprimento com
estruturas. Neste caso, deve-se endereçar os subcampos de modo simbólico. Com
algumas instruções, os detalhes de offset e de comprimento podem ser fornecidos
como variáveis (MOVE, ASSIGN, parâmetro atual, WRITE ... TO).
O sistema ABAP calcula o número de dias desde 01.01.0001, se o campo de data

for convertido para um campo numérico. Inversamente, um valor numérico atribuído
a um campo de data é interpretado como o número de dias desde 01.01.0001. Os
valores dos campos de datas são convertidos em valores numéricos (número de
dias desde 01.01.0001) antes de qualquer cálculo.
O sistema ABAP não tem uma instrução GOTO ou equivalente. Existem outros
comandos de controle, assim como aqueles acima mencionados. Por exemplo, a
instrução de loop LOOP ... ENDLOOP que lê tabelas internas, e a diferenciação de
caso
AT ... ENDAT para processamento de nível de controle na instrução LOOP.
As instruções de controle podem ser agrupadas.
As expressões lógicas podem ser ligadas com NOT, AND e OR. As expressões em
parênteses podem ser agrupadas tanto quanto possível. Os parênteses que
denotam sub-expressões sempre valem por uma palavra. Assim, devem estar
separados por espaços. Se forem comparados dois campos da categoria C com
comprimentos diferentes, o campo mais curto será encompridado para se igualar ao
mais longo no momento em que a comparação é feita, pelo preenchimento com
espaços, a partir da extrema direita. Existe uma série de outros operadores

comparativos que podem ser usados para comparar cadeias e comparações de bit.
(Ver a documentação on-line da instrução IF).
As instruções IF e CASE permitem diferenciações de caso:
CASE ... ENDCASE:

• Apenas uma das sequências das instruções é executada.
• A instrução WHEN OTHERS é opcional.
IF ... ENDIF:
• As instruções ELSE e ELSEIF são opcionais.
• Desde que a expressão lógica esteja informada, a sequência seguinte de
instruções é executada.
• A seção ELSE ou ELSEIF é processada quando a expressão lógica não
estiver mencionada. Se não existir a instrução ELSE ou nenhuma outra
ELSEIF, o programa avança depois da instrução ENDIF.
• O sistema permite incluir qualquer número de instruções ELSEIF entre IF e
ENDIF. No máximo, uma das sequências de instruções será executada.
Os loops DO e WHILE também são usados no sistema ABAP. sy-index é o contador

do loop dos comandos de loop DO e WHILE. O valor de sy-index é igual a 1 durante
o primeiro passo do loop, e o sistema o aumenta 1 a cada passo do loop.
Os loops DO têm as seguintes características:

• O parâmetro <n> TIMES é opcional. Se não estiver especificado, será preciso
construir uma condição de terminação no loop (ver a instrução EXIT).
• A quantidade de passos do loop não pode ser alterada pelo campo sy-index,
nem o contador do loop em DO ... ENDDO.
Os loops WHILE têm as seguintes características:

• Desde que informada a expressão lógica, a sequência de instruções é
executada.
• O número de passos do loop não pode ser alterado pelo campo sy-index no
loop WHILE...ENDWHILE.
Existem duas instruções disponíveis para o processamento do loop:

• CHECK <logical expression>: Se não for preenchido o campo da expressão
lógica, o sistema passa ao próximo passo do loop. Todas as instruções entre
CHECK e ENDDO / ENDWHILE são ignoradas. Se a expressão lógica for
informada, a instrução CHECK fica sem efeito.
• Consultar também: a documentação da palavra-chave CONTINUE.
• As instruções EXIT na estrutura de um loop fazem com que o sistema saia do
loop atual.

Exercícios
instrutor.

Capítulo 5
Modularização e estrutura de programas
Um programa ABAP é um conjunto de blocos de processamento. Bloco de

processamento é uma seção passiva de um texto de programa, processado em
seqüência quando chamado. Blocos de processamento são as menores unidades
do ABAP e não podem ser divididos ou agrupados.
Todas as declarações globais são processadas quando o programa é gerado e
formam um bloco de processamento lógico. Por motivos de organização, todas as
declarações globais devem ser inseridas no início dos programas.
FIGURA045 - Global Data
Em todos os programas vistos neste curso até o momento, havia apenas um bloco
de processamento além da declaração de dados. Em casos como esse, o bloco não
precisa ser explicitamente declarado. Todavia, em programas mais complexos, são
necessários vários blocos de processamento, com tipo e nome especificados.
Todas as declarações globais são reconhecidas pelo sistema por meio das palavras-
chave declarativas do ABAP. Essas palavras formam um bloco de processamento
lógico (independentemente do local onde elas estão situadas no texto do programa).
Quando o programa é gerado, o sistema pesquisa todo o código de programa para

localizar instruções declarativas. No entanto, por motivos de organização, entrar

todas as instruções declarativas no início dos programas.
Há diversos tipos de blocos de processamento:
Blocos de tempo: em programas executáveis (tipo 1), o sistema supervisor ABAP é

responsável por chamar os blocos de tempo em uma seqüência especial,
desenvolvida para gerar uma lista.
• Subprogramas: módulos internos do programa, que possuem uma interface.

Com uma declaração ABAP, é possível chamar um subprograma em um
programa, a partir de qualquer outro bloco de processamento.
• Módulos de função: módulos com uma interface transparente, disponíveis
em todo o sistema. Esses módulos podem ser chamados de qualquer bloco
de processamento e em qualquer programa ABAP que utilize uma declaração
ABAP especial.
• Existe outro tipo de bloco de processamento que será abordado no capítulo
Diálogos.
Quando chamados, todos os blocos de processamento são processados em

seqüência. Se um subprograma ou módulo de função é chamado a partir de um
bloco de processamento, o sistema interrompe o bloco, para processá-lo. Ao
retornar para o bloco de processamento, a execução é retomada a partir da próxima
declaração ABAP.
Os eventos mais facilmente compreensíveis são os de um programa executável (tipo

1). O sistema supervisor ABAP chama blocos de tempo em uma seqüência criada
para gerar e processar listas:
• Primeiramente, o bloco de tempo INITIALIZATION é chamado

• Em seguida, uma tela de seleção é enviada ao servidor de apresentação
• Assim que o usuário sai da tela de seleção, START-OF-SELECTION é
ativado
• Uma lista é enviada ao servidor de apresentação.

FIGURA046 – INITIALIZATION

FIGURA047 – START-OF-SELECTION
Em um programa ABAP, um bloco de tempo tem início com uma palavra-chave de

evento e termina quando o próximo bloco de processamento começa. Não há uma
declaração ABAP que represente o fim de um bloco de tempo. Os blocos de tempo
são chamados pelo sistema supervisor ABAP. A ordem em que os blocos de tempo
são organizados no programa é irrelevante – o sistema possui uma ordem
predefinida para que eles sejam ativados.
START-OF-SELECTION é o primeiro evento para processamento de dados e

geração de uma lista. Ele é chamado pelo sistema supervisor ABAP assim que o
usuário sai da tela de seleção standard.
INITIALIZATION é um evento que pode ser usado para definir um grande número de
valores propostos. Esse bloco de tempo permite definir valores propostos que só
podem ser determinados no tempo de execução. No exemplo anterior, é atribuído o
valor ‘2’ para a variável F3. Em seguida, o sistema supervisor ABAP pode enviar
uma tela de seleção para o servidor de apresentação com essa variável e caso ela
apareça na tela, esse valor será mostrado ‘2’ e ainda é passível de modificação.
Os subprogramas são blocos de processamento com uma interface definida, que

podem ser chamados a partir de qualquer outro bloco de processamento por meio
de uma declaração ABAP. Os subprogramas permitem encapsulamento do
programa interno. Os parâmetros da interface são chamados de parâmetros
formais e os parâmetros que o usuário passa para o subprograma são chamados
parâmetros atuais.

FIGURA048 – Parâmetros atuais

FIGURA049 – Parâmetros formais
O bloco de processamento de um subprograma começa com 'FORM <subroutine

name> <interface definition>' e termina com ' ... ENDFORM. ' . É possível utilizar a
declaração DATA em uma rotina FORM para declarar os dados locais. Se um objeto
local tem o mesmo nome de um objeto global, o global será invisível dentro do
subprograma.

FIGURA050 – Definição de variáveis LOCAIS
A interface é definida da seguinte maneira:
• Após USING, deve-se relacionar em uma lista todos os parâmetros que o

subprograma só precisa ler.
• Após CHANGING, deve-se relacionar em uma lista todos os parâmetros que
o subprograma vai modificar e cujos valores serão transferidos para o
programa de chamada.
Digitar os parâmetros como a seguir:
• Usar TYPE para que o parâmetro siga um determinado modelo, que pode ser
definido internamente no programa ou pode ser um tipo ABAP predefinido
• Usar LIKE para fazer um parâmetro compatível com um objeto de dados
global ou tipos ABAP Dictionary
• Existe a possibilidade de omitir o tipo. Nesse caso, o parâmetro formal herda
o tipo do parâmetro atual correspondente.
• Se o nome do parâmetro é utilizado após USING ou CHANGING, o
endereço do objeto de dados do programa de chamada é transferido
(transferência de endereço).

• Se VALUE (<nome do parâmetro>) é utilizado em vez do nome do

parâmetro, o sistema cria automaticamente uma cópia local do parâmetro
(pass by value).
Dentro de um programa é possível definir dados globais. Todos os dados que

constam em uma declaração DATA de um programa ABAP mas não são indicados
em uma rotina FORM são interpretados como dados globais. Os dados globais
podem ser visualizados em todo o programa, inclusive nos subprogramas.
Os dados locais são definidos dentro dos subprogramas. A declaração DATA pode
ser utilizada em uma rotina FORM para indicar objetos de dados que são visíveis
apenas dentro dessa rotina. Esses objetos existem somente quando FORM está em
execução. Se um objeto de dados local e um objeto de dados global têm o mesmo
nome, durante a execução do subprograma, apenas o objeto local pode ser
mencionado por esse nome.
Double-Click
FIGURA051 – Criação de FORM’s
As rotinas FORM podem ser chamadas a partir de qualquer bloco de processamento

ABAP por meio de PERFORM <nome do subprograma> <interface>. É
recomendável inserir as rotinas FORM no final do texto de programa, para que os
programas sejam mais facilmente compreensíveis. Posicionar as rotinas depois de

todos os blocos de tempo pode evitar muitos erros em potencial, já que as

declarações FORM delimitam os blocos de tempo.
O número de parâmetros atuais deve ser igual ao de parâmetros formais. Não é

possível ter parâmetros opcionais. Os parâmetros são atribuídos na seqüência em
que estão relacionados na lista.
Quando um subprograma é chamado com a declaração PERFORM, o sistema

verifica se os tipos dos parâmetros atuais de PERFORM são compatíveis com os
parâmetros formais. Há diferentes verificações para os diferentes tipos:
• Verificações completas de tipo:

− TYPE D, F, I ou T.
LIKE <f>,TYPE <ud> Esses tipos são totalmente especificados. O sistema
verifica se a categoria de dados do parâmetro atual está de acordo com o tipo do
parâmetro formal(<ud> = definido pelo usuário).
Verificações parciais de tipos genéricos

TYPE C, N, P ou X. O sistema verifica se o parâmetro atual possui o tipo C,
N, P ou X. O comprimento do parâmetro e o número de casas decimais no
suplemento DECIMALS (tipo P) são transferidos do parâmetro atual para o
parâmetro formal.
− TYPE <ud> todas as informações não especificadas dos tipos genéricos,
definidos pelo usuário, são herdadas de um parâmetro atual pelo
parâmetro formal.
A interface é definida na rotina FORM. USING e CHANGING na declaração do

PERFORM são apenas para documentação.

FIGURA052 – Typing nos FORM’s
Com LIKE ou TYPE, as estruturas de dados podem ser transferidas (por exemplo:
estruturas, linhas de cabeçalho de tabelas internas, áreas de trabalho de tabelas)
com uma descrição da estrutura. Os campos individuais de uma estrutura não são
reconhecidos no subprograma se o tipo do parâmetro formal não é especificado.
É necessário especificar o tipo de parâmetro formal correspondente na declaração

FORM antes de transferir uma tabela interna para um subprograma, como seria feito
com uma estrutura. As tabelas internas são transferidas sem a área de trabalho.
Desse modo, é necessário declarar uma dessas tabelas com uma declaração DATA
local.
Há diversas maneiras de especificar o tipo de uma tabela:
• TYPE TABLE O sistema verifica se o parâmetro atual é uma tabela interna.

Todos os atributos e a estrutura da tabela são transferidos do parâmetro atual
para o formal.
• LIKE <do> A categoria de dados do parâmetro atual deve ser exatamente a
mesma que o tipo do parâmetro formal (<do>= objeto de dados)

• TYPE <ud> A categoria de dados deve ser a mesma do tipo definido pelo
usuário <ud>. É possível declarar tipos genéricos.
• LIKE <Dictionary type> A categoria de dados deve ser compatível com o tipo
ABAP Dictionary.

Exercícios
instrutor.

Capítulo 6
Tabelas internas.
Uma tabela interna (também denominada matriz) é uma sequência de entradas ou

linhas de mesmo tipo. Em geral, elas são usadas para arquivar os resultados de
processamento ou os dados de origem.
São usadas para:

Armazenamento temporário de dados das tabelas do banco de dados para
processamento posterior
Arquivamento de dados para a exibição de listas
Arquivo de dados para comunicação com o computador de mesa, outros servidores
de aplicações do sistema R/3 ou sistemas não-SAP.
O número de linhas de uma tabela interna não é estático nem predeterminado. O

sistema de tempo de execução do ABAP expande as tabelas internas de modo
dinâmico, de acordo com a necessidade. Os únicos fatores limitantes do volume de
dados que pode ser administrado por uma tabela interna são as barreiras de
capacidade concretas definidas durante a instalação do sistema.
Na definição, 8 KB de memória estão alocados para cada tabela interna. Caso seja
necessária mais memória durante o tempo de execução, o sistema coloca à
disposição mais blocos de 8 KB.

FIGURA034 – Tabelas internas
As tabelas internas são descritas através de vários atributos, um dos quais é o tipo
de linha.
Esse tipo de linha determina a estrutura dos registros de dados que podem ser
armazenados em uma tabela interna. O tipo de linha de uma tabela interna pode ser
composto de qualquer categoria de dados do ABAP, incluindo outras tabelas
internas.

FIGURA035 – Sintaxe – Tabelas Internas
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 sequência de seus
campos. Por exemplo, a chave CARRID CONNID é diferente da chave CONNID
CARRID.
As chaves da tabela interna também podem ser definidas como EXCLUSIVAS ou

NÃO EXCLUSIVAS. Isso determina se as entradas com chaves idênticas podem ser
aceitas ou não.
O sistema permite o acesso aos registros de dados em uma tabela interna de formas
diferentes, similares aos tipos de acesso aos dados para tabelas normais do banco
de dados. O usuário pode acessar um só registro de dados, ou múltiplos, ou todos
os registros da tabela ao mesmo tempo.
O tipo de acesso define como o ABAP acessa entradas individuais de tabela.

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
mantém para acessar os dados
Acesso com chave: significa usar um termo de pesquisa, em geral uma chave de
tabela ou uma chave de tabela genérica, para ter acesso aos dados.

Outro atributo de tabela interna é a categoria de tabela. 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

através do seu índice ou de suas chaves.
Tabelas ordenadas: são ordenadas de acordo com a chave e gravadas. Aqui,
também, um índice linear é atualizado 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.
A categoria de tabela a ser usada depende de como as entradas daquela tabela são
normalmente acessadas. Tabelas standard devem ser usadas se as entradas forem
normalmente acessadas através de índice; se as entradas forem feitas normalmente
através de chaves, recomenda-se a tabela ordenada; se forem feitas exclusivamente
com chaves, devem ser utilizadas tabelas aleatórias de prova.
T a b le T y p es
A N Y T A B LE
IN D E X T A B LE
LE H A S H E D T A B LE
LE
S T A N D A R D T A B LE S O R T E D T A B LE
A c ce ss w ith n n
in d e x
A c ce ss w ith
k ey
U n iq u e /
n o n -u n iq u e k ey N O N - U N IQ U E U N IQ U E | N O N -U N IQ U E U N IQ U E
A c ce ss u sin g m a in ly in d e x m a in ly k e y s o n ly k e y s R
 SAP AG
FIGURA036 – Tipos de Tabelas Internas

Ao contrário dos conceitos de matriz em outras linguagens de programação, em

ABAP não se permite o acesso direto às entradas de tabela: tais operações são
conduzidas através de áreas de trabalho.
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)
MODIFY sobrescreve uma linha específica com o conteúdo de uma área de
trabalho
DELETE apaga uma linha específica 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
As quatro categorias de tabela (<itabkind>), com os tipos de linhas(<linetyp>),

sequências-chave(<keydef>) e o modo exclusivo/não exclusivo ( UNIQUE|NON-
UNIQUE ) são utilizados para especificar todos os atributos de uma tabela.
Na definição, 8 KB de memória são alocados para cada tabela interna. Caso se

precise de mais memória durante o tempo de execução, o sistema coloca à
disposição da tabela outros blocos de 8 KB. Se necessário, a quantidade de
memória atribuída a uma tabela interna pode ser reduzida no começo de cada
programa. O suplemento opcional INITIAL SIZE <n> proporciona à tabela memória
suficiente no início do tempo de execução para armazenar o volume "n" de entradas
de tabela.
Como mencionado no capítulo sobre estruturas de dados do programa ABAP, o

sistema permite usar tabelas internas sempre que houver uma sequência de
entradas ou linhas de mesmo tipo. Isto ocorre quase sempre quando um programa
precisa de uma cópia interna de uma determinada tabela do banco de dados (por
exemplo.
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:
APPEND <wa> TO <itab> acrescenta o conteúdo de uma área de trabalho <wa> ao
final da tabela interna <itab>. Ao declarar uma tabela standard, o usuário não
precisa usar o suplemento STANDARD.

FIGURA037 – Comando APPEND
O usuário pode preencher uma tabela interna com todo o conteúdo de uma tabela
do banco de dados utilizando uma única instrução SELECT. Assim, o sistema lê os
registros em lote, não individualmente. Depois, este lote é inserido como um todo na
tabela interna. Este tipo de acesso de leitura é mais eficiente do ponto de vista da
performance do que ler e inserir dados em loop, registro por registro. Considerando
que aqui não é usado qualquer loop, a instrução ENDSELECT não é necessária.
Ao utilizar o formulário básico ...INTO TABLE..., todos os registros de dados já

encontrados são inseridos na tabela interna e todas as entradas anteriores da tabela
são sobrescritas. Com o formulário ...INTO CORRESPONDING FIELDS OF
TABLE... todos os campos da quantidade de resultado são colocados nos
respectivos campos da tabela interna. Isso é muito útil quando a tabela interna em
questão for composta de várias colunas específicas de uma tabela do banco de
dados.

FIGURA038 – Cláusula INTO CORRESPONDING FIELDS OF
Para ordenar uma tabela interna, deve-se usar a instrução SORT. As adições BY
<f> e ASCENDING ou DESCENDING permitem restringir a ordenação a campos
específicos e determinar a sequência e a hierarquia da ordenação.
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 a tabela através de chaves, recomenda-se restringir o
número de entradas ou linhas a serem lidas com a cláusula WHERE, exatamente
como se faz com um comando SELECT.
No início de cada loop, SY-TABIX é preenchido com o índice da entrada da tabela

atual. Depois que o loop é processado, SY-TABIX volta ao valor que possuía antes
do início do processamento do loop.

A cada passo do loop,

varia SY-TABIX
FIGURA040 – SY-TABIX
A instrução READ TABLE <itab> deve ser utilizada para ler entradas individuais da
tabela. Todas as entradas de tabela lidas são colocadas na área de trabalho <wa>.
Se o acesso de leitura tiver sido bem sucedido, o campo SY-SUBRC é igual a zero;
todos os outros valores significam que o acesso de leitura não pôde ser executado
com sucesso. O sistema fornece automaticamente ao campo SY-TABIX o valor do
índice da entrada de tabela lida.
Com o comando READ o usuário pode acessar as entradas da tabela interna

através do índice e das chaves. Ao acessar uma tabela interna com chaves, o termo
de pesquisa é tirado dos campos-chave da tabela interna, enquanto os valores do
termo de pesquisa são tirados dos respectivos subcampos da área de trabalho <wa>
que foi informada no campo FROM. Assim, o sistema lê a primeira entrada <itab>
que corresponde ao termo de pesquisa.
READ TABLE <itab> ... INDEX . Lê o número de entrada da tabela .

FIGURA041 – READ TABLE
Como utilizar o acesso com índice para processar entradas individuais da tabela
interna:
A instrução MODIFY <itab> [FROM <wa>] INDEX sobrescreve a entrada da

tabela i com o conteúdo da área de trabalho. A linha i já deve existir.
A instrução INSERT [<wa> INTO] <itab> INDEX cria uma nova entrada de
tabela antes de i utilizando o conteúdo da área de trabalho. Se a tabela tiver
entradas = -1, o conteúdo da área de trabalho é anexado à tabela interna.
A instrução DELETE <tab> INDEX elimina a entrada de tabela i.

FIGURA042 – Efetivando alterações no conteúdo de tabelas internas
As instruções MODIFY TABLE, INSERT TABLE e DELETE TABLE permitem

acessar as entradas da tabela interna através de chaves.
Ao acessar uma tabela interna com chaves, o termo de pesquisa é tirado dos
campos-chave da tabela interna e os valores do termo de pesquisa são tirados dos
respectivos subcampos da área de trabalho <wa> que foi informada no campo
FROM.
Note que, se usada com uma tabela standard, a instrução INSERT TABLE atua
como APPEND. Mas quando usada com uma tabela ordenada, INSERT TABLE
insere as entradas já ordenadas.

FIGURA043 – MODIFY TABLE
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.
CLEAR <wa> - inicializa uma área de trabalho <wa>.

FIGURA044 - CLEAR
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 (linha
de cabeçalho) e o corpo real da tabela, ambos endereçados com o mesmo nome.
A interpretação desse nome depende do contexto em que é utilizado. Por exemplo:
em MOVE o nome é interpretado como linha de cabeçalho; em SEARCH é
interpretado como o corpo da tabela.
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 linhas de cabeçalho. Entretanto, nas tabelas internas com
linhas de cabeçalho é quase sempre possível usar uma sintaxe reduzida para
certas operações.

Entendendo os novos tipos de Tabelas internas
Standard
As linhas podem ser acessadas utilizando o índice da tabela ou a chave. Ao utilizar a
chave, o tempo de resposta dependerá da quantidade de entradas da tabela. A chave será
sempre não única.
Sorted
As linhas são sempre gravadas de acordo com a sua chave. As linhas são
acessadas utilizando o índice ou a chave. Ao utilizar a chave, o tempo de resposta terá
relação logarítmica com a quantidade de linhas de tabela, pois é utilizada pesquisa binária. A
chave de uma tabela sorted pode ser tanto UNIQUE quanto NON-UNIQUE. Tabelas sorted
são geralmente conhecidas como index tables.
Hashed
As linhas são acessadas pela chave. O tempo de resposta é constante, não dependendo
do número de entradas na tabela, pois utiliza um algoritmo especial. Neste tipo de tabela a
chave deve sempre ser UNIQUE.

Considerações
Ao ler tabelas tipo Sorted ou Hashed, utilizar WITH TABLE KEY, caso contrário o
sistema utilizará a procura linear ao invés de binary search.
Não preencher tabelas internas tipo Sorted com operações com índice (INSERT wa
INTO tab1 INDEX tabix, APPEND tab1 FROM wa), pois o sort será corrompido.
IMPORTANTE !!!
Uma tabela interna tipo Sorted não pode ser re-ordenada.
Um bom exemplo de utilização de tabela interna tipo Hashed é a armazenagem de

dados mestre freqüentemente lidos, que são carregados em uma tabela interna, para evitar
leituras redundantes na base de dados.
O comando MODIFY pode ser utilizado com uma cláusula WHERE.

Work Área da Tabela Interna
As Work Áreas (WA) têm o papel do Header Line em uma tabela sem o mesmo.
Todas as leituras e/ou gravações têm necessariamente que passar pela WA.

Definição de Tabelas internas
Uma Tabela Interna pode ser definida através do comando DATA (Como na versão
3.0F), ou através do comando TYPE.
A principal diferença entre esses dois modos de declaração de Tabelas é que:

• No primeiro caso (DATA), a declaração da tabela já está alocando o espaço
em memória.
• No segudo caso (TYPE), somente é feita uma referência do tipo definido no
TYPES, sendo assim, não ocupa lugar na memória, sendo necessário, para
isso, a declaração da tabela através do comando DATA, fazendo referência
a um TYPE.

Preenchendo uma Tabela Interna
Para preenchimento da Tabela interna, todos os dados são movidos previamente

para uma Work Área (wa) e posteriormente inseridos na tabela interna.

Preenchendo a Tabela Interna a partir da Transparent Table (Select)
Para leitura de uma tabela transparent, o Select gera dados para a Work Área (wa) e
posteriormente é feito o Append a partir dessa Work Área, efetivando-se a inserção.
A Cláusula INTO TABLE faz a inserção dos dados diretamente, sem passar pela
Work Área. Este segundo exemplo é muito mais performante que o primeiro.

Sorteando Tabelas Internas

Looping de leitura na Tabela Interna

Acessando Entradas individuais em Tabelas internas

Modificando uma Tabela Interna através do Índice

Modificando uma Tabela Interna através de Chaves

Deletando uma Tabela Interna

Tabelas Intenas COM e SEM Header Line

Exercícios
instrutor.

Capítulo 7
Módulos de Função
Módulos de função são subprogramas externos com uma interface transparente. A

interface é considerada transparente porque não está incluída nas declarações do
programa ABAP para a parte executável do módulo de função. A interface é definida
separadamente e pode ser atualizada independentemente do texto.
Com os parâmetros opcionais, acréscimos à interface podem tornar as declarações

do programa ABAP completamente executáveis sem qualquer modificação. Eles são
armazenados de forma centralizada no Repository R/3.
Cada módulo de função pertence a um grupo de funções. Um grupo de funções é

um programa ABAP do tipo F, criado exclusivamente para armazenar módulos de
função. O Sistema de informação de substituição permite procurar módulos de
função. O Function Builder, uma das ferramentas do ABAP Workbench, é utilizado
para criar módulos de função. Além de utilizar os módulos de função dentro de um
sistema R/3, também é possível chamá-los a partir de outros sistemas R/3, R/2 ou
externos.
FIGURA053 – Grupo de Funções

Cada módulo de função pertence a um grupo de funções. O grupo de funções é um

programa ABAP com o tipo F, criado exclusivamente para conter módulos de
função. Os grupos de função não são executáveis. Os módulos de função são
subprogramas externos – eles não podem ser gravados no programa que os chama.
Quando um módulo de função é chamado, o sistema carrega todo o grupo de

funções na área de memória do programa de chamada. Todos os módulos de
função de um grupo de funções possuem um tema em comum. Por exemplo: todos
os módulos do grupo SCAL executam cálculos de data.
Grupos de funções são criados no browser de substituição. O nome de um grupo

de funções pode ter até 30 caracteres. São permitidos apenas caracteres
alfanuméricos e a sublinha (_). Se o usuário não está usando o próprio conjunto de
nomes, o grupo de funções deve começar por Z_ ou Y_. Tão logo são chamados,
os grupos de funções se tornam acessíveis no sistema.

Ao criar uma função, deve-se associá-la a um

Grupo de Função previamente existente.
FIGURA054 – Grupo de funções no Function Builder
A categoria de objeto Grupo de funções, no browser de substituição, permite criar

um novo módulo de função em um grupo de funções existente. Um módulo de
função é composto de dados administrativos, interface, texto fonte e documentação.
O nome de um módulo de função pode ter, no máximo, 30 caracteres. São
permitidos apenas caracteres alfanuméricos e a sublinha (_).
Caso o usuário não esteja utilizando o próprio conjunto de nomes, o módulo de

função deve começar por Z_ ou Y_. Um módulo de função se torna ativo no sistema
quando é chamado pelo usuário. Assim que a chamada é feita, o sistema gera o
grupo de funções a que o módulo pertence.
Um módulo de função é composto de:
Informações administrativas: nome do módulo de funções, breve descrição, grupo

de funções, responsável, última modificação feita por... , tipo de processamento,
classe de desenvolvimento…
Interface
• Parâmetros da interface: é possível utilizar objetos de dados elementares,
estruturas ou tabelas internas como parâmetros de importação, exportação e
modificação. Os módulos de função utilizam os mesmos métodos de
transmissão de parâmetros que as rotinas FORM.

• Exceções: se, durante o processamento, ocorre um erro em um módulo, é

possível inserir a correção dentro do próprio módulo como uma exceção.
• Documentação da interface: é necessário fornecer uma breve descrição
dos parâmetros e das exceções da interface. Para entrar mais dados na
documentação, basta clicar sobre qualquer uma dessas descrições. A
documentação do módulo de função contém interligações automáticas para
informações mais detalhadas.
Texto fonte e Documentação: É possível documentar separadamente cada
módulo de função. Essa informação pode ser traduzida e exibida no idioma do
usuário.
FIGURA055 – Function Builder – Inf. Administrativas

FIGURA056 – Function Builder – Parâmetros de Importação
FIGURA057 – Function Builder – Parâmetros de Exportação

FIGURA058 – Function Builder – Changing
FIGURA059 – Function Builder – Tabelas

FIGURA060 – Function Builder – Exceções

Como exemplo de parâmetros de interface são utilizados parâmetros de

importação:
Como no caso das rotinas FORM, é possível:
• Determinar uma estrutura ou tipo de referência para tornar obrigatória uma

verificação de tipos nos parâmetros de interface. É necessário definir um tipo
de referência para estruturas e para tabelas internas. Se o usuário não
determina um tipo de referência para os parâmetros elementares, o parâmetro
formal herda o tipo do parâmetro atual.
• Determinar, ao definir a interface, se os parâmetros devem ser transferidos
por referência ou por valor. No primeiro caso, a opção 'Referência' é
selecionada.
Diferentemente da rotinas FORM, os módulos de função permitem definir os

parâmetros opcionais de interface. Nesse caso, o usuário pode fornecer um valor
proposto. Esse valor (ou o valor inicial da categoria de dados correspondente) é
utilizado se o programa de chamada não fornece o parâmetro.
Os tipos do ABAP Dictionary ou os tipos predefinidos ABAP só podem ser utilizados

para verificação. Uma categoria de tabela deve ser gravada em um pool de tipos no
ABAP Dictionary, para as tabelas internas.
Do ponto de vista do módulo de função, parâmetros de importação são aqueles
recebidos do programa e parâmetros de exportação são aqueles retransmitidos para
o programa.
É possível antecipar possíveis erros e escrever o programa de modo que eles não
causem erros de tempo de execução. As possíveis exceções são denominadas na
interface do módulo de função e acionadas a partir do texto de programa, por meio
da declaração RAISE. Cada programa que chama o módulo de função consulta sy-
subrc para interpretar as exceções. No módulo de função também é possível
garantir que o sistema exiba uma mensagem de erro se a exceção ocorrer, mesmo
que ela não seja diretamente tratada pelo programa de chamada. Para obter mais
informações, consulte a documentação e pesquise as palavras-chave MESSAGE ...
RAISING.

FIGURA062 – Exemplo de Sintaxe
O sistema cria um modelo de programa para cada módulo de função. Os parâmetros

de interface e exceções definidas pelo usuário são automaticamente inseridas como
linhas de comentário no texto do módulo. Todavia, é preciso lembrar que é a
definição da interface, não essas linhas, o que realmente define a interface. Não
modificar manualmente as linhas de comentário pois elas são automaticamente
atualizadas quando a definição da interface sofre alguma alteração. As declarações
ABAP do módulo de função são escritas entre as declarações FUNCTION e
ENDFUNCTION. Por exemplo: o usuário aciona a exceção MAX_EQ_0 por meio da
instrução RAISE MAX_EQ_0.
Assim que um módulo de função está pronto e ativado, ele pode ser testado no
Function Builder. Um modelo de entrada permite especificar os parâmetros IMPORT.
O resultado é transferido para os parâmetros EXPORT e exibido. O sistema
memoriza a exceção ativada, caso ocorra um erro.
O tempo de execução do módulo de função é exibido em microssegundos. Esses

valores estão sujeitos às mesmas condições que a transação de análise de tempo
de execução. Portanto, o usuário deve repetir o teste diversas vezes com os
mesmos dados. Os dados do teste podem ser gravados em um diretório de dados
de teste. A função de teste do Function Builder pode ser utilizada para testar
módulos de função com parâmetros de tabela. É possível criar seqüências de teste.

FIGURA063 – Teste de módulos de Função – I

FIGURA064 – Teste de módulos de Função – II
FIGURA065 – Teste de módulos de Função – III

É possível chamar qualquer versão ativa de um módulo de função existente no

repository do R/3 a partir de um programa. Para isso, basta utilizar um modelo de
declaração do ABAP Editor (botão 'Modelo') e entrar o nome do módulo de função.
Em seguida, o sistema gera uma declaração ABAP CALL FUNCTION '<nome do
módulo de função>', que inclui a interface do módulo, e insere essa declaração no
programa, na posição atual do cursor.
Preencher os parâmetros atuais e, se necessário, escrever as declarações que

processarão qualquer exceção destacada. Os valores dos parâmetros de interface
são atribuídos explicitamente pelo nome do parâmetro atual. Não é necessário
atribuir um parâmetro atual a um opcional. Nesse caso, o usuário pode eliminar a
linha que contém o parâmetro opcional. Assegurar que, durante a atribuição de
parâmetros, o parâmetro do módulo de função esteja sempre à esquerda e o atual à
direita.
Os módulos de função podem ser iniciados tanto no modo assíncrono quanto

paralelo. É possível fazer o encapsulamento dos diálogos de usuário. O usuário
pode criar módulos de função que podem ser iniciados pela Chamada de função
remota. As seguintes opções de acesso remoto estão disponíveis:
• A partir da World Wide Web, para permitir o acesso a um sistema R/3

• A partir de outro sistema R/3
• A partir de seus próprios programas (por exemplo: Visual Basic, JAVA ou
C++).

BAPI
Definição
A BAPI (Business Application Programming Interface) é a interface que provê acesso
aos processos e dados nas aplicações de negócios de sistemas como o R/3.
BAPIs são definidas como métodos API dos objetos de negócio SAP. Esses Objetos
de Negócio e suas BAPIs são descritas e armazenadas no BOR (Business Object
Repository).
A BAPI é implementada, no entanto como um módulo de função que é armazenada

no Function Builder.
.
Integração
BAPIs podem ser chamadas no R/3 por aplicações externas e outros programas. BAPIs
são padrões de comunicação para aplicações de negócios. A interface de tecnologia BAPI
formam a base para os seguintes desenvolvimentos.
• R/3 satellite systems
• Componentes isolados dentro do sistema R/3 em contexto com o Business

framework.
• Cenários distribuídos R/3 usando ALE (Application Link Enabling)
• Conexão do Sistema R/3 à internet utilizando IACs (Internet Application

Components).
• Programas Visual Basic sendo utilizados como front ends do R/3.grams as frontends
to R/3
• Aplicações Workflow
• Conexão com softwares Não-SAP.
• Conexão com sistemas legados.
O gráfico seguinte mostra como a interface BAPI habilita diferentes tipos de aplicação a
serem ligados como um todo.

BAPIs – Interface com o Sistema R/3
BOR
Definição
O Business Object Repository (BOR) é o repositório de objetos orientados do R/3.
Ele contém, entre outros objetos, Objetos de Negócio SAP e seus métodos.
No BOR, uma Business Application Programming Interface (BAPI) é definida como

um método API de um Objeto de Negócio. Portanto definida, a BAPI se torna standard com
garantia total bem como seu conteúdo e interface.
Utilização
Com relação aos objetos de negócio SAP e suas BAPIs, a BOR têm as seguintes
funções:
• Provê uma visão orientada a objetos dos dados e processos do Sistema R/3.
• Funções de aplicação do R/3 são acessadas utilizando métodos (BAPI). A

implementação de informação é encapsulada, somente a interface de funcionalidade
do método é visível ao usuário.
• Arranja as diferentes interfaces de acordo com a hierarquia de componentes,

habilitando funções a serem encontradas e recuperadas de forma rápida e fácil.
• Gerencia o processo de Update das BAPIs.

Integração
Uma BAPI é definida na BOR como um método de um objeto de negócio SAP. Uma
BAPI é implementada, no entanto, como um módulo de função, a qual é armazenada no
Function Builder. Você somente deve definir uma BAPI como um objeto de negócio SAP
na BOR se este módulo de função estiver completamente implementado.
A figura abaixo mostra o relacionamento entre um objeto de negócios SAP e seus

relacionamentos no módulo de função.

BAPI Browser
Você pode mostrar mais informações nos objetos de negócios e as BAPIs que
pertencem a eles utilizando o BAPI Explorer. A tela é composta por duas partes: a área
hierárquica e a janela de detalhes.
A área hierárquica mostra os componentes hierarquicamente. Você pode expandir

um componente de aplicação para procurar quais aplicações o objeto pertence. Se você
expandir um simples objeto de negócio, o sistema mostra uma sub-árvore, exibindo quais
são as chaves de atributos e métodos API que pertencem a ele.

Se você expandir uma sub-árvore para um objeto de negócios no BAPI Explorer, o

sistema mostrará o seguinte:
• Atributo Chave: o qual provê um único identificador para cada objeto de negócio.
• Métodos de instância específica: os quais referem-se às chaves identificadas pelos
atributos.
• Métodos de instância não-específica: os quais podem ser chamados por todas as
instâncias de um tipo de objeto.

Se você expandir uma subestrutura para um método, o sistema retornará os nomes

de seus parâmetros de import e export. Você pode obter mais detalhadas informações
escolhendo a pasta “ferramentas”.
BAPIs usualmente tem um parâmetro de export chamado RETURN. Isto pode ser
uma estrutura ou tabela interna. O parâmetro de retorno contëm informações de erros que
podem ocorrer durante o processamento da BAPI. Não há parâmetros de EXCEPTIONS
para BAPIs.

Para visualizar informações completas de um tipo de objeto de negócio, use o

BUSINESS OBJECT BUILDER. O sistema mostrará uma árvore com os tipos de objeto,
incluindo os métodos API não-SAP.
BAPIs Standard
As BAPIs com nomenclatura standard contém métodos standard, os três mais

importantes são listados abaixo:
• GetList – Retorna o conteúdo dos campos-chave para o objeto que foi escolhido.
• GetDetail – Retorna informações detalhadas (atributos) para os objetos requeridos.
• CreateFromData – Cria um novo objeto no R/3 e retorna informações sobreele.

BAPIs implementadas como Módulos de Função
Na versão 4.6 as BAPIs têm sido implementadas utilizando Módulos de Função. É

possível visualizar o módulo de função para a BAPI que você escolheu através do BAPI
Explorer através dos seguintes passos:
• Selecione a BAPI na área hierárquica.

• Na janela de informações detalhadas (direita) escolha a tab “ferramentas”.
• Escolha “function builder”. O sistema mostrará o nome do módulo de função.
Para implementação da função, deverá ser criado um programa que utilizará a

BAPI através do comando: CALL FUNCTION.
Ex.
CALL FUNCTION ‘BAPI_PO_CREATE’
OBS. Os parâmetros deverão seguir estritamente a regra da função.

Exercícios
instrutor.

Capítulo 8
Dialog Programming – On-Line
Os principais componentes de um programa On-line

Development environment
ABAP/4 Screen Menu

ABAP/4
Dictionary Painter Painter
Runtime environment
Dialog processor ABAP/4 processor
• É necessária a utilização do Screen Painter e do Menu Painter para a criação

dos templates e dos programas controladores das telas.
• O fluxo lógico do processamento da tela é definido no programa ABAP (Module
pool)
• Os campos definidos nas telas devem ser obtidos através de estruturas e/ou
tabelas definidas no dicionário de dados.

Screen Painter - ABAP
S c re e n P a in te r – A B A P /4
S c re e n
P a in te r
S c re e n S c re e n F ie ld
a ttrib u te s la y o u t a ttrib u te
t es F lo w lo g ic
S c re e n n o . 100 PROCESS BEFORE OUTPUT.
NUMBER
S h o rt te x t T est N u m b e r: MODULE INIT.
CHAR
S c re e n ty p e N o rm a l
1 0 c h a ra c te rs
N e x t s c re e n 200
In p u t x PROCESS AFTER INPUT.
...
... MODULE READ.
A B A P /4
G lo b a l d a ta P B O m o d u le s P A I m o d u le s
DATA: NUMBER(10) MODULE INIT OUTPUT. MODULE READ INPUT.
TYPE C. CLEAR NUMBER. SELECT ...
. ENDMODULE. .
.
. . .
ENDMODULE.
. . .
. .
.
 SAP AG
• Para criação de uma tela, devem ser seguidos os seguintes passos:

• Defina os componentes básicos da tela (screen attributes).
• Desenhe o layout da tela utilizando o fullscreen editor.
• Defina os os atributos dos campos (field list).
• Escreva o fluxo lógico da tela. (flow logic).
• Os mais importantes componentes do programa ABAP são encontrados nos
seguintes objetos:
• Global data ou Estruturas do dicionário no TOP include (declaração de dados)
• Module PBO (Process Before Output)
• Module PAI (Process After Input)
• Subrotinas (se necessário)

Comunicação entre os módulos
Communication: Screen – ABAP/4 Module Pool

Screen PROCESS
PROCESS BEFORE
BEFORE OUTPUT.
OUTPUT. PROGRAM
PROGRAM SAPMTALA
SAPMTALA MESSAGE-ID
MESSAGE-ID AT.
AT. ABAP/4
Painter 1 TABLES
TABLES SPFLI.
SPFLI.
MODULE
MODULE INITIALIZE.
INITIALIZE.
MODULE
MODULE INITIALIZE
INITIALIZE OUTPUT.
OUTPUT.
2 CLEAR
CLEAR SPFLI.
SPFLI.
ENDMODULE.
ENDMODULE.
MODULE
MODULE READ_SPFLI
READ_SPFLI INPUT.
INPUT.
PROCESS
PROCESS AFTER
AFTER INPUT.
INPUT. 1 SELECT
SELECT SINGLE
SINGLE ** FROM
FROM SPFLI
SPFLI
MODULE
MODULE READ_SPFLI.
READ_SPFLI. WHERE ...
WHERE ...
..
MODULE
MODULE ...
... 2 ..
..
.. ENDMODULE.
.. ENDMODULE.
1 Control passes from the dialog processor to the ABAP/4 processor

2 Control passes from the ABAP/4 processor to the dialog processor
Screen
Screen work area Module pool work area ABAP/4
Painter
SPFLI-CARRID TABLES: SPFLI.
LH LH 0400
PBO
SPFLI-CONNID CARRID CONNID
0400 DATA: OK-CODE (4).
PAI
OK-CODE
II D
DEEN
N TT II C
CAA LL N
NAAM
MEES
S

• O Fluxo lógico é dividido em dois eventos para cada tela:

• O PROCESS BEFORE OUTPUT evento (PBO), é executado antes da tela
ser apresentada.
• O PROCESS AFTER INPUT evento (PAI), é executado após o usuário ter
acionado algum botão ou disparado algum evento na tela anteriormente
apresentada.
• O sistema processa os módulos em um evento sequencialmente.
• Em cada módulo, o controle é passado do processador de diálogos (tela) para o
processador do programa ABAP, e após o processamento, o controle é
retornado ao processador de diálogos (tela).
• Quando todos os módulos do PBO terminarem a execução, os conteúdos dos
campos na Work Area do ABAP são copiados para a Work Area da tela em
nomes idênticos.
• Antes do PAI ser processado, os conteúdos dos campos na Work Area da tela
são copiados para a Work Area do ABAP em nomes idênticos.

Overview: Criando um Dialog Program
Overview: Criando um Dialog Program
Airline carrier LH
Flight number 0400
...
Planned flight
From FRANKFURT
To NEW YORK
Time 08:24:00
...
• A seguir nós criaremos um Dialog Program que mostrará dados do Flight

Connection, por exemplo. Na primeira tela, o usuário entrará com a chave da
tabela, e na segunda tela, será mostrado o conteúdo dos campos referentes à
tabela SPFLI.

Criando Programas
Criando Programas
Development class Edit
Program
Functional area
Local private objects
$TMP Local objects of the user
Create
Programs
..
.
Choose
Program SAPMTALA
with TOP Include
• Crie o seu programa (ABAP Module Pool) no Development Workbench seguindo

a regra de nomenclatura abaixo:
• O nome deverá iniciar com as letras SAP.
• A quarta posição do nome do programa deverá ser sempre M (Module Pool).
• A quinta posição, no caso de programas customizáveis deverá ser Z ou Y,
(como nos programas reports, iniciados obrigatoriamente com essas letras).
• Escolha a opção TOP Include, pois desta forma, será criado o include que será
utilizado para a declaração dos dados globais.
• Se você utilizar os includes, o sistema automaticamente sugerirá os nomes para
eles, seguindo uma regra particular, de acordo com o nome do programa
principal (module pool) e com um determinado sufixo, o qual facilitará a sua
identificação dentro do programa.
Exemplo: O nome do TOP Include para um programa Module Pool cujo nome é
SAPMTALA será MTALATOP.

Atributos do Programa
Atributos do Programa
Title
Test
Type M
Application S
Save
Nos atributos do programa, você define o Título, o tipo do programa e a aplicação.

Para programas Module Pool, escolha o tipo de programa M.

Definindo Telas
Definindo Telas
$TMP User's local objects
programs
SAPMTALA
Create ..
.
screens
..
.
Choose Program SAPMTALA

Screen no. 100
Continue Screen Attributes

Short description Test
Screen type
Normal
..
.
Next screen 200

• Crie as telas necessárias para o seu programa Module Pool á partir da lista de
objetos.
• Após você ter digitado o número da tela, o sistema abre uma nova tela com
dados daquela tela.
• Digite uma pequena descrição para a tela.
• Escolha a opção NORMAL, e especifique o número da próxima tela (se
necessário, no momento da execução, o sistema desviará para o número da tela
indicado nesse campo, caso esteja preenchido).

Utilizando Campos do dicionário ABAP
Utilizando campos do dicionário ABAP

ABAPABAPtionary Fields
Fullscreen Dict/ProgFields
Dict/ProgFields
Get from Dict.

Table/field name
Get from program
Field Format Length Shrt text Template
Key word
- short
- medium
- long
- header
Copy
• Geralmente, você define campos utilizando os campos préviamente definidos no

dicionário ABAP.
• Podem ser utilizados também campos já definidos no módule pool, bastando
para isso que exista uma geração prévia deste module pool.
• Podem ser feitas cópias dos campos de saída e dos templates (telas)
individualmente ou juntas.

Definindo Elementos Gráficos (Graphical Screen Painter)
Lay out da tela (Graphical Screen Painter)
Field
Fieldattr.
attr. Dict./prog.fields
Dict./prog.fields Field
Field list
list
Text
Text
Entry
Entry
Check
Check
Airline carrier
Radio
Radio
Connection number
Box
Box
• Para desenhar telas, utilize o Screen Painter.

• A interface do Screen Painter Gráfico contém funções easy-to-use para definição
de diversos elementos da tela (ex: campos de entrada/saída, labels, boxes,
botões, etc). Você escolhe cada elemento e os posiciona na tela utilizando o
mouse.
• Para deletar elementos da tela, é necessário selecionar cada elemento com o
mouse (foco) e pressionar delete.
• É possível também mover os elementos gráficos pela tela, somente clicando e
arrastando o mesmo.

Definindo o Fluxo Lógico (Flow Logic)
Definindo o Flow Control
Screen
Painter
PROCESS BEFORE OUTPUT.
MODULE INITIALIZE.
PROCESS AFTER INPUT.

MODULE READ_SPFLI.
• Nos Flow Logics não são permitidos palavras reservadas (IF, PERFORM, WHILE
etc) da mesma forma em que são permitidos nos programas. O Flow Logic,
embora se pareça muito com o programa (o editor é o mesmo), não tem o
mesmo comportamento. Ele é usado basicamente para ordenar o
processamento da tela, e para isso são criados os MODULES, que têm uma
funcão análoga à do PERFORM.
• Para criarmos um MODULE, escreva o seu nome no flow logic no lugar desejado
e efetue um double-click. O sistema criará uma subrotina iniciando com
MODULE <nome> e terminando com ENDMODULE no include apropriado. Isto
pode ser facilmente observado efetuando uma navegação pelo include.
• Se não existirem includes, o sistema poderá criar um (se você permitir) ou
poderá incluir a subrotina no programa principal (o que aliás, não é
recomendado).

Criando uma sequência de telas
Criando uma sequência de telas

Screen 100 Copy Screen 200
Screen 200
Attributes Flow control

..
. PROCESS BEFORE
OUTPUT.
Next screen PROCESS AFTER
INPUT.
Screen Field list

SPFLI-CARRID
SPFLI-CARRID ___ SPFLI-CONNID
SPFLI-CONNID ____
SPFLI-CITYFROM
SPFLI-CITYFROM ______ SPFLI-CITYTO
..
SPFLI-CITYTO ______ .
• Para telas com estrutura similar, você pode copiar uma tela existente e, se
necessário, modificá-la.
• Para fazer isto, você utiliza o Development Workbench posicionando o cursor na
tela que você deseja copiar e escolha a opção COPY.
• Quando terminar o processo com sucesso, o sistema mostrará a tela como um
novo sub-objeto do module pool e você poderá editá-lo.
Importante: Sempre que você copiar uma tela o flow logic também será copiado, e o
Module que aparece declarado nos flow logics é somente a “chamada” desse
módule, esteja ciente que as subrotinas (modules) podem ser compartilhadas por
várias telas, e que a modificação de uma subrotina com esse nível de amarração
deve ser feita com muita atenção.

Definindo Campos no Module Pool
Definindo campos no Module Pool

Top include
MTALATOP
ABAP/4
PROGRAM SAPMTALA.
TABLES: SPFLI.
DATA: ... .
OR
Global data
ABAP/4
DATA: ... .
• No processamento do diálogo, os dados são passados entre as telas e

programas ABAP durante a execução. O sistema efetua a comunicação
automaticamente, mas é necessário que seja utilizado o nome idêntico dos
campos nas telas e no module pool.
• Defina os dados globais no TOP include. Para que todas as telas possam
“enxergá-lo”.

Criando Modules ABAP
Criando Modules ABAP

programs
SAPMTALA
Create Create
.. ..
. .
PBO modules PAI modules
.. ..
. .
Choose Choose
PBO module INITIALIZE PAI module READ_SPFLI

in include prog. MTALAO01 in include prog. MTALAI01
• Durante o processo de criação dos módulos PAI e/ou PBO, você pode associá-
los aos includes desejados ou deixar que o sistema automaticamente faça isto
por você. Neste caso os módulos no PBO serão criados nos includes com o
sufixo O01 (xxxxxI01), e os do PAI, nos includes com sufixo I01 (xxxxxO01).

O processamento no the Module Pool
O Processamento do Module Pool
ABAP/4
MODULE INITIALIZE OUTPUT.
CLEAR SPFLI.
ENDMODULE.
ABAP/4
MODULE READ_SPFLI INPUT.
SELECT SINGLE * FROM SPFLI
WHERE CARRID = SPFLI-CARRID
AND CONNID = SPFLI-CONNID.
.
.
.
ENDMODULE.
• As subrotinas provenientes dos módulos do PBO têm a adição OUTPUT, e as

provenientes do PAI têm a adição INPUT.

Chamadas via transação
Definindo chamadas via transação
Programs
SAPMTALA
Create ..
.
Transactions
..
.
Choose Transaction code TALA

Transaction type
Dialog transaction
..
.
Continue Transaction code TALA

Transaction text TEST
Program SAPMTALA
Screen number 100
• Para executar um programa ABAP Module Pool, é necessária a criação de uma

transação.
• Transações customizadas devem iniciar com Z ou Y.
• O sistema armazena suas especficações de transações na tabela TSTC.

Sequência de Ações
Sequência de Ações
Screen Action sequence
PROCESS BEFORE OUTPUT. Painter
MODULE A. Execute module A

MODULE B. Data transport from
ABAP/4 to screen
work area
Send screen
ENTER
Data transport from

screen to ABAP/4
work area
Execute module B
• Quando todos os módulos do PBO terminarem a execução, os conteúdos dos

campos na Work Area do ABAP são copiados para a Work Area da tela em
nomes idênticos.
• Antes do PAI ser processado, os conteúdos dos campos na Work Area da tela
são copiados para a Work Area do ABAP em nomes idênticos.

Input Checks no Module Pool
Input Checking no Module Pool
Screen
Painter ABAP/4
PROCESS AFTER INPUT. MODULE <module> INPUT.
FIELD <screen field> .
.
MODULE <module>. .
MESSAGE E ... .
ENDMODULE.
1 1
E... message
1 Pronto para nova checagem
• Se for necessária a checagem dos campos de entrada no module pool e incluir

um tratamento de mensagem de erro, deverá ser utilizado o comando FIELD,
associado ao campo que desejamos checar. Se for necessário o tratamento mais
apurado, pode ser associado um module específico a esse comando.

Comando FIELD e transporte de dados
Comando FIELD e transporte de dados

A ENTER
Screen
PROCESS AFTER INPUT. Painter c
Data transport for all
MODULE A. t fields other than X, Y
FIELD X MODULE B.
FIELD Y MODULE C. i from the screen to the
ABAP/4 work area
MODULE D. o
n
Execute module A
s Data transport for X

e
q Execute module B
u
Data transport for Y
e
n Execute module C
c
e Execute module D

• No módulo PAI, campos da tela são transportados com nomes idênticos para
Work areas do programa ABAP.
• Campos não associados a comandos FIELD são transportados primeiro. Todos
os outros campos são copiados somente quando todos os FIELD tiverem sido
executados.

Alterando a sequência de telas dinamicamente
Alterando a sequência de telas dinamicamente

Screen Screen
Painter Painter
Screen attributes Screen attributes
screen number 100 screen number 200

. .
. .
. .
next screen 100 next screen 200
Screen Screen
Painter Painter
PROCESS
PROCESS AFTER
AFTER INPUT.
INPUT. PROCESS
PROCESS BEFORE
BEFORE OUTPUT
OUTPUT
MODULE ..
MODULE OK_CODE.
OK_CODE. ..
..
ABAP/4
MODULE OK_CODE INPUT.
.
. PROCESS
PROCESS AFTER
AFTER INPUT.
INPUT.
. ..
SET SCREEN 200 . ..
..
LEAVE SCREEN.
• Se as funções do seu dialog program requererem um controle de processamento

diferenciado, pode ser feito o controle da sequência das telas dinamicamente,
usando o comando SET SCREEN.
• O comando SET SCREEN nnn temporariamente sobrepõe o controle feito nos
atributos da tela no campo next screen.
• A tela nnn deve ser uma tela do mesmo module pool.
• Quando a tela corrente termina seu processamento, o sistema desvia o controle
para a tela definida no campo next screen. Se você quiser cancelar a tela
corrente, pode ser usado o comando LEAVE SCREEN.
• Pode ser usado o comando CALL SCREEN para controle da sequência da tela
dinamicamente. Aqui, você pode inserir a sequência de telas a após retornar
para a tela original que originou a chamada.

Interpretando Function Codes no programa
Interpretando Function Codes no Programa

Screen
Painter
.
.
.
Screen
MODULE USER_COMMAND.
Painter
Display
ABAP/4
DATA: OKCODE(4),
SAVE_OKCODE(4).
MODULE USER_COMMAND INPUT.

SAVE_OKCODE = OKCODE.
Screen
Painter CLEAR OKCODE.
Field list CASE SAVE_OKCODE.
Field name Lg Form FctCode WHEN ‘MORE’.
.
.
PUSH_100 MORE .
ENDMODULE.
OKCODE 5 OK
• Quando é definido um Pushbutton para possibilitar ao usuário escolher funções

específicas, quando o botão é pressionado, o evento PAI é disparado.
• Pode-se criar um Function Code para cada Pushbutton.
• Existe um formato (dicionário) pré definido para function codes, é o OK, com
tamanho de 4 bytes.
• Para permitir a execução correta de uma função associada a um pushbutton, é
necessária a criação de um campo chamado exatamente de OKCODE. Este
campo contëm o valor do function code após os dados serem transportados da
tela para o programa.

Menu Painter: Overview
Menu Painter: Overview
Object List GUI title

Development object Edit Goto .... SET TITLEBAR code.
SY-TITLE: Title text
Markers
ENTER GUI status

F1 Help SET PF-STATUS status.
F2 Choose SY-PFKEY: Status
F3 .
.
.
Title bar
Menu bar
Standard toolbar
Application toolbar
• Usa-se o Menu Painter para definir funções na tela em um status particular e

associá-los a um apropriado menu, a saber: menu bar, standard toolbar e
application toolbar.
• Pode-se também definir um título para a tela.
• Em geral, define-se um menu bar para cada dialog program e associa-se esse
menu bar a um status. Para cada status, define-se qual função estará
ativa/inativa.
• Cada alteração nos status (menus) deve ser seguida de uma re-geração da tela
completa.
• Para associar um status e um título a uma tela, isto deve ser feito no seu PBO,
usando o comando SET PF-STATUS e SET TITLEBAR, respectivamente.

Definindo Interfaces I
Definindo Interfaces I
Menu bar
- Hide standards
<Object> Edit Goto
Func Name
< .. > Other <object>
< .. > Create
F key assignment
+ Extended F key assignment
WINDOWS MOTIF APPLE ...
• Quando necessário, o sistema propõe valores default para o menu bar e também
teclas de função, porém, podem ser modificadas.

Definindo Interfaces II
Definindo Interfaces II
Standard toolbar
...
Application toolbar
...
Recommended function key settings

F2 < .. > Choose
F9 < .. > Select
...
Freely assigned function keys

F5
F6
...
• As funções mais utilizadas podem ser associadas também ao application toolbar.

Antes de fazer esse procedimento, um function code deve ser associado ao
pushbutton respectivo.
• As funções standard são automaticamente associadas.

Exercícios
instrutor.

Capítulo 09
Modificação Dinâmica em telas
Modificações Dinâmicas em Telas
Change <-> Display Change <-> Display
A A
B B
output field input and

output field
• Podem ser feitas mudanças temporárias em certos atributos de campos. Ex.:

Fazer com que um campo com atributo de display somente, seja alterado para
receber entrada de digitação etc.
• Esta facilidade faz com que possam ser utilizadas as mesmas telas, somente
com a alteração dos atributos dos seus campos, desta forma a quantidade de
telas é reduzida consideravelmente.

Atributos modificábeis da tabela SCREEN

SCREEN-NAME Field name
SCREEN-GROUP1 Modification group 1
SCREEN-REQUIRED Required field
SCREEN-INPUT Input field
SCREEN-OUTPUT Output field
SCREEN-INTENSIFIED Highlighted field
SCREEN-INVISIBLE Invisible field
SCREEN-LENGTH Field length
SCREEN-ACTIVE Active field
SCREEN-DISPLAY_3D 3-dimensional field
SCREEN-VALUE_HELP Field with value help
SCREEN-REQUEST Input exists (PAI only)


• Os campos da tela e seus respectivos atributos são armazenados

automaticamente em uma tebela interna (do sistema) chamada SCREEN.
• A tabela SCREEN é inicializada com os campos definidos no Screen Painter e
tem seus campos reinicializados a cada execução do PBO.
• Para determinar o campo que você deve alterar um ou mais atributos, você
precisa ler o campo SCREEN-NAME e os campos SCREEN-GROUP1 até
SCREEN-GROUP4, através de um Loop na tabela SCREEN.

Atributos do campo – Grupos de Modificação
Screen
Painter
Field list: Modification groups
Field name Gr1 Gr2 Gr3 Gr4 ...
SPFLI_ITAB-CONNID SEL
SPFLI_ITAB-CITYFROM SEL
SPFLI_ITAB-CITYTO SEL
...
• Você pode associar um campo a quatro diferentes grupos. Os nomes dos grupos
podem ter até 3 caracteres e podem ser definidos livremente.

Modificações Dinâmicas em Telas - Programa

Screen
.
.
.
MODULE MODIFY_SCREEN.
.
.
.
ABAP/4
MODULE MODIFY_SCREEN OUTPUT.
...
LOOP AT SCREEN.
IF SCREEN-GROUP1 = 'SEL'.
SCREEN-INPUT = 1.
ENDIF.
IF SCREEN-NAME = ' SFLIGHT-CARRID '.
SCREEN-ACTIVE = 0.
ENDIF.
MODIFY SCREEN.
ENDLOOP.
ENDMODULE.
• O código (programa) para alterar dinamicamente os atributos dos campos devem

ser executados no evento PBO.
• As mudanças devem ser feitas dentro de um Loop na tabela SCREEN, e
somente desta forma.(Não é possível o acesso via READ TABLE...).
• As mudanças feitas são realmente ativadas após o comando MODIFY SCREEN.

Exercícios
instrutor.

Capítulo 10
Table Control
ABAP/4 Table Control (Function Scope)

Modify column width
Select and transpose
column(s) Store table settings
Depart from Connection to Depart Arrive
Select
line(s)
Automatic horizontal
Fixed lead column(s) and vertical scrolling

• É possível mostrar ou permitir entrada em linhas simples com a facilidade do

table control.
• As características são as seguintes:
• O grid pode ser redimensionado para display ou edição dos dados.
• Largura da coluna pode ser redimensionada, inclusive a modificação da
posição das mesmas.
• A seleção da coluna fica em modo high-light.
• Cabeçalhos de colunas são mostradas como pushbuttons para seleção de
colunas.
• Scrolling Horizontal e Vertical.
• Atributos da célula pode ser alterado dinamicamente.

Preenchimento das tabelas de controle
Database table Internal table Table control

("buffer")
1
2
1
3
2
4
3
Database 4
table 5 next page
6
7 5
8
6
9 7
. 8
.
.
• Por questões de performance, você lê os dados para o table control somente

uma vez e as armazena em uma tabela interna.
• O controle das linhas é obtido da leitura desta tabela interna.

Princípios de Aplicação do Table Control
Screen 1 Screen 2 (with table control)

Screen Screen
PBO Painter PBO Painter
LOOP ...
read in internal table line by

line
ENDLOOP.
PAI PAI
LOOP ...
Read lines from the database
into an internal table update internal table line by
line
ENDLOOP.
• Há somente uma Work Area para edição de linhas no table control. Por esta
razão, você precisa um LOOP...ENDLOOP para cada table control em ambos os
eventos PBO e PAI no respectivo flow logic.
• No PBO, uma linha do table control deve ser preenchida com uma linha da
tabela interna a cada passo do loop.
• Similarmente, o mesmo processo é feito no PAI.

Transporte de campos no PBO

LOOP start
Screen
Painter
MODULE OUTPUT_1
PROCESS BEFORE OUTPUT.
Transport ABAP/4
LOOP ...
table control fields
to screen fields
MODULE OUTPUT_1 .
LOOP end ENDLOOP.
MODULE OUTPUT_2 .
MODULE OUTPUT_2
Transport remaining
ABAP/4 fields to
screen fields
• Em telas contendo table controls, a sequência de transporte dos campos muda.

• No PBO, campos são transportados do module pool para a tela a cada vez que o
loop é precessado no flow logic. Os demais campos são transportados
normalmente.

Transporte dos Campo no PAI

Transport all fields from
the screen to ABAP/4
fields, except table
control fields and F1 Screen
Painter
MODULE INPUT_1 PROCESS AFTER INPUT.
LOOP start MODULE INPUT_1 .
Transport table control LOOP ...

fields from the screen to MODULE INPUT_2 .
ABAP/4 fields ENDLOOP.
FIELD F1
MODULE INPUT_2 MODULE INPUT_3 .
...
LOOP end
Transport F1 from the

screen to ABAP/4 fields
MODULE INPUT_3
• No PAI todos os campos de tela que não pertencem ao table control e não estão
especificados em qualquer comando FIELD são transportados aos respectivos
work fields do módule pool.
• O conteúdo do table control é transportado linha a linha aos respectivos work
fields do module pool a cada passo do loop.

Criando Table Controls
Attributes
Attributes Dict./prog.fields
Dict./prog.fields Field
Fieldlist
list
Text
Text
Entry
Entry
.
. Flight From To
.
Table
Table
.
.
.
• No Editor gráfico, você escolhe TABLE para criar o table control e usa o botão
esquerdo do mouse para posicioná-lo na tela.
• Então após esse procedimento, defina os campos para o table control através do
dicionário ABAP.

Definindo Table Controls no Module Pool

ABAP/4
Reference screen
CONTROLS ctrl TYPE TABLEVIEW USING SCREEN scr . for initializing the
table control
The type TABLEVIEW corresponds to the structure type CXTAB_CONTROL
with the single types:
FIXED_COLS TYPE I Number of fixed columns

LINES TYPE I Number of lines for vertical scrolling
TOP_LINE TYPE I First line in next PBO
CURRENT_LINE TYPE I Current line (within LOOP ...ENDLOOP)
LEFT_COL TYPE I First movable displayed column
LINE_SEL_MODE TYPE I Line selection (none:0, single: 1, multiple: 2)
COL_SEL_MODE TYPE I Column selection (none:0, single: 1, multiple: 2)
LINE_SELECTOR Indicator: Display line selection
V_SCROLL Indicator: Vertical scrollbar
H_GRID Indicator: Horizontal grid line
V_GRID Indicator: Vertical grid line
COLS TYPE CXTAB_COLUMN OCCURS 10
The type CXTAB_COLUMN consists of the single types:

SCREEN LIKE SCREEN Attributes of the structure SCREEN
INDEX TYPE I Column position (display sequence)
SELECTED Indicator "Column selected"
VISLENGTH LIKE ICON-OLENG Visible width of column
INVISIBLE Indicator "Column invisible"

• O comando CONTROLS define o objeto de dados do tipo TABLEVIEW, que

corresponde ao tipo CXTAB_CONTROL, definido no dicionário ABAP.
• Os valores iniciais são colocados através do Screen Painter. Com a cláusula
USING SCREEN, você determina a tela a qual será referenciada com os valores
iniciais do table control.

Table Controls no Flow Logic 1

Opção 1 : Lendo a tabela interna no flow logic, Tabela interna na tela
Screen
LOOP AT SPFLI_ITAB
WITH CONTROL CONNECTIONS
CURSOR CONNECTIONS -CURRENT_LINE .
ABAP/4
ENDLOOP.
MODULE MODIFY_SPFLI_ITAB INPUT.
LOOP AT SPFLI_ITAB . MODIFY SPFLI_ITAB
FIELD SPFLI_ITAB-MARK INDEX
MODULE MODIFY_SPFLI_ITAB CONNECTIONS -CURRENT_LINE .
ON REQUEST.
ENDLOOP. ENDMODULE.
• No flow logic, você pode ler tabelas internas usando o comando LOOP. Você
define a referencia dos respectivos table controls especificando WITH CONTROL
<ctrl>.
• Você determina qual tabela de entrada vai ser lida especificando CURSOR
<CTRL> - CURRENT LINE. O sistema calcula a linha corrente através do
TOP_LINE + SY-STEPL.
• O sistema calcula o TOP_LINE automaticamente sempre que há alteração na
posição do scroll-bar.

Table Controls no Flow Logic 2

Opção 2 : Lendo a tabela interna no module pool ABAP/4
Dicionário de dados na tela MODULE SFLIGHT_ITAB_READ OUTPUT.
READ TABLE SFLIGHT_ITAB
INDEX FLIGHTS -CURRENT_LINE .
IF SY-SUBRC EQ 0.
MOVE-CORRESPONDING SFLIGHT_ITAB
Screen TO SFLIGHT.
PROCESS BEFORE OUTPUT. Painter ELSE.
LOOP WITH CONTROL FLIGHTS. EXIT FROM STEP-LOOP .
ENDIF.
MODULE SFLIGHT_ITAB_READ . ENDMODULE.
ENDLOOP. ABAP/4
PROCESS AFTER INPUT. MODULE MODIFY_SFLIGHT_ITAB INPUT.

LOOP WITH CONTROL FLIGHTS . MOVE-CORRESPONDING SFLIGHT
FIELD SFLIGHT-PRICE TO SFLIGHT_ITAB.
MODULE MODIFY_SFLIGHT_ITAB MODIFY SFLIGHT_ITAB
ON REQUEST. INDEX FLIGHTS -CURRENT_LINE .
ENDLOOP. ENDMODULE.
• Se você usa o comando LOOP sem uma tabela interna no flow logic, você
precisa ler os dados no PBO o qual é chamado a cada passo do loop.
• Desta forma o sistema não pode determinar o número de entradas desta tabela,
você precisa então do comando EXIT FROM STEP-LOOP para garantir que
linhas em branco não serão preenchidas no table control.
• Você precisa também determinar o número de linhas para o scrolling vertical.

Modificando Table Controls
Screen
Painter
PROCESS BEFORE OUTPUT. Change attributes
of the entire table 1
MODULE CTRL_MODIFY_1 . control
LOOP...
MODULE MODIFY_SCREEN .
Change
Changeattributes
attributes
ENDLOOP.
of
of fields
fields in inthe
the
table 2
tablecontrol
control
PROCESS AFTER INPUT. temporarily
temporarily
LOOP...
...
ENDLOOP. Change attributes
of the entire table 1
MODULE CTRL_MODIFY_2 . control
• Você pode mudar os atributos do table control através dos atributos dos campos.
• Para modificar os atributos de uma célula individual você altera a tabela
SCREEN, normalmente.

Paginação do Table Control (Exemplo)

ABAP/4
DATA: LOOPLINES LIKE SY-LOOPC .
...
MODULE GET_LOOPLINES OUTPUT.
Screen
Painter LOOPLINES = SY-LOOPC.
PROCESS BEFORE OUTPUT. ENDMODULE.
LOOP... . MODULE USER_COMMAND_0200 INPUT.

MODULE GET_LOOPLINES ...
ENDLOOP. WHEN ' F21 '.
FLIGHTS-TOP_LINE = 1.
PROCESS AFTER INPUT. WHEN ' F22 '.
FLIGHTS-TOP_LINE =
LOOP... . FLIGHTS-TOP_LINE - LOOPLINES.
... IF FLIGHTS-TOP_LINE < 1.
ENDLOOP. FLIGHTS-TOP_LINE = 1.
...
MODULE USER_COMMAND_0200 WHEN ' F24 '.
FLIGHTS-TOP_LINE =
FLIGHTS_ITAB_LINES
- LOOPLINES + 1.
ENDMODULE.
• Para implementar a paginação é necessário calcular usando o atributo do table

control TOP_LINE.
• Para isso (no PAI), você precisa saber qual o número de linhas corrente na
tabela respectiva do table control.
• No PBO, a variável de sistema SY-LOOPC contém o corrente número de linhas
do table control. No PAI, ela contém o número de linhas correntemente
carregadas.
• SŸ-LOOPC somente contém o valor entre LOOP e ENDLOOP porque ela conta
o número de passos do loop.

Exercícios
instrutor.

Capítulo 11
Tabstrip
A técnica de utilização de TABSTRIPS possibilita de uma forma fácil a apresentação de

diferentes componentes de uma aplicação em uma simples tela e permitindo a navegação
entre os mesmos.
Basicamente é utilizado quando em uma tela com diferentes tipos de dados “poluem”
demasiadamente uma tela. Neste caso são criadas várias “pastas” (tabstrips) que são
facilmente acessadas.
Em cada tela do Tabstrip é criada uma Subtela, que é onde os componentes da mesma são
posicionados. Esses elementos basicamente podem ser:
• Campos
• Step-loops
• Table-controls
• Botões
A seguir veremos passo a passo como um tabstrip é criado:

1 – Criação do Programa On-line (Module Pool)
Na transação SE80 (Object Navigator), crie um programa On-Line (Module Pool) que deverá
ser utilizado para servir de base das telas a serem criadas no Screen Painter.

2 – Criação das Telas – Screen Painter
Após a criação do Programa On-Line, efetuar a criação das telas, as quais conterão os
tabstrips.

3 – Desenhar a tela com os tabstrips desejados.
Nesta etapa, para o desenho dos tabstrips, deve-se escolher a opção indicada acima.

4 – Definir os atributos do tabstrip
Definir um nome para a tela principal do Tabstrip e criar tantas pastas quanto necessário,
através do campo indicado.

5 – Definição da Subtela.
Definir uma área onde os campos serão mostrados. Esta área é definida como subtela
(conforme indicado).

6 – Associação das pastas com a(s) Subtelas(s).
Podem ser criadas tantas subtelas quanto pastas a serem utilizadas, porém, para minimizar
os controles e por conseguinte a complexidade do programa, sugerimos que seja criada uma
subtela somente (este procedimento somente é possível pois as pastas compartilham uma
área idêntica – mesmo tamanho, caso contrário isso não seria possível).
Nas telas de atributos de todas as pastas, associar as subtelas na janela de atributos.

7 – Definição de mais pastas
Caso haja necessidade de criação de novas pastas, aumente o campo indicado com
o valor desejado.

8 – Criação da tela com os campos de dados.
Nesta etapa, deverá ser criada uma ou mais telas (de acordo com o necessário) para que os
campos sejam armazenados.
Esta tela deverá ser montada dinamicamente no espaço reservado na subtela dos tabstrips.

9 – Definição do Lay-out dos campos das telas.
Efetuar a criação dos campos da forma em que deverão aparecer na tela pronta.
Este procedimento é idêntico ao desenvolvimento das telas de um programa on-line
normal.

10 – Definição dos controles do tabstrip.
No Programa Include xxxxTOP, deverá ser inserido o código abaixo:

11 – Chamando a execução do Tabstrip.
O comando Call Subscreen… é responsável pela “montagem dinâmica” da tela (subtela) na

tela principal do tabstrip.

12 – Navegação pelo Tabstrip
A navegação é conseguida através dos comandos acima, que devem ser declarados
no PBO da tela principal.
Ao utilizar seleção dinâmica de tela em um tabstrip control:
- Todas as páginas compartilham a mesma área de subtela.
- As telas de subtelas são chamadas no flow logic usando uma variável.

No bloco PBO, você deve chamar um módulo antes da chamada à subtela que copia o nome
da subtela que se deseja chamar na variável apropriada.
Deve ser colocado o código da função da página ativa na variável ACTIVETAB da tabstrip
control.

13 – Tabstrip pronto.
Após todos esses passos, é só criar a transação e a tela será mostrada conforme acima.

Exercícios
instrutor.

Capítulo 12
Sapscript
1 – O Que é SAPscript e quando utilizar
SAPscript é a ferramenta do SAP para criação de relatórios mais elaborados,

chamados de formulários. A opção pela utilização da ferramenta geralmente se dá pela
necessidade de alguns recursos que não podem ser obtidos através de código ABAP
comum, como nos chamados “reports”, tais como inserção de logotipos, fontes de tamanhos
ou tipos diferentes, et... Muitas vezes, também, dependendo da necessidade do relatório,
pode compensar mais utilizar o desenvolvimento de um relatório convencional sobre um
formulário pré-impresso, que já contenha o layout e logotipo desejados.
2 - Limitações e Problemas da Ferramenta
Embora seja a ferramenta de geração de formulários mais poderosa do SAP, o

SAPscript ainda apresenta uma série de limitações, principalmente no que diz respeito a
verificação de erros e análise de debug. Um comando escrito na grafia errada dentro do
formulário, jamais será detectado pelo mesmo. Somente a não funciopnalidade esperada do
comando poderá levar ao programador descobrir se próprio erro.
O modo debug no ambiente de SAPscript pode ser ativado na transação SE71
(Ferramentas -> Processamento de Texto -> Layout Set), através do menu Utilitátios -> Ativar
Debug. O método correto consiste em se preencher o nome do formulário e idioma nos
campos da tela, antes de percorrer o caminho do menu. Algumas vezes, no entanto,
principalmente para um processamento em backgroubd, o formulário não permite ser
debugado, embora percorrendo o caminho acima citado, nenhuma mensagem de
impossibilidade seja exibida. Simplesmente, nenhuma tentativa de debug funciona. Nesses
casos, o programador deve utilizar de artifícios como imprimir o conteúdo dos campos a
serem checados em pontos estratégicos do formulário, para observar seu comportamento.
O comportamento de um formulário SAPscript pode também ser muitas vezes irritante,
principalmente quando se desconhece alguns de seus detalhes. Um dos problemas mais
comuns do formulário SAPscript é quanto a utilização de logotipos nos relatórios gerados.
Sua filosofia pode parecer bastante simples e é,mas essa operação é bastant sensível, e
devem ser salientados alguns pontos:
1. O objeto com o logotipo deve ser gerado a partir de um programa ABAP, através
da transação SE38, chamado RX... . O modo como o arquivo com o logotipo é
tratado, deve ser cuidadosamente verificado, pois implicará no sucesso ou fracasso
da exibição do logotipo esperado. Inicialmente, deve ser ressaltado que o arquivo
deve estar no foramto .TIF . Observado esse ponto, assegurar que o arquivo não
apresente mais do que 16 cores e por último o seu tamanho não apresenta uma
relação direta com o tamanho que será obtido dentro do formulário SAPscript. Até
onde se tem notícias, ninguém nunca descobriu uma relação correta e geral para o
tamanho de um logo em pixels e seu tamanho dentro do formulário. Geralmente essa
relação só é observada caso a caso, após algumas tentativas de erro e acero.
2. Nessa hora entra a segunda dificuldade de se trabalhar com logotipos em SAPscript.

Ao se executar o formulário, em uma visualização na tela, o usuário nunca irá
conseguir enxergar o logotipo. Esse somente irá aparecer na impressão em papel
(ainda que impressão do layout do formulário, e não seu conteúdo final – Utilitários ->
Imprimir Layout).
Essas duas características podem tomar algumas horas do programador, ainda que bem
experiente no trabalho com SAPscript.
É importante se observar também que os formulários são “client dependent”, o que
significa dizer que devem ser transportados a todos os clientes em que se deseja executa-lo,

independentemente de estar na mesma instância que já o tenha. Isso não pareceria ser
muito complicado se não fosse um trabalho a mais controlar a versão de todos no momento
que uma alteração feita. Pior do que eles, são os objetos gerados como os logotipos, que
além de dependentes do cliente, não estão vinculados a nenhuma request, não podendo
nem ser transportados de um cliente para outro.
Por falar em transporte, é sempre bom reforçar que no momento do transporte de um
formulário SAPscript, é necessário assegurar que todas as estruturas utilizadas por ele,
tenham sido transportadas anteriormente. O objetivo é assegurar que tudo que será utilizado
pelo formulário já esteja no cliente, no momento em que este for introduzido, para que não
haja erros. A ordem mais aconselhada para esses transportes seria:
1. Estrutura
2. Layout
3. Programa de povoamento
Também vale a pena chamar a atenção para que essas 3 classes de objetos estejam
em requests separadas no desenvolvimento de um projeto, o que pode evitar problemas
quando algum deles não estiver no desenvolvimento propriamente e necessitar ser reparado.
Programa de Povoamento de SAPscript
O programa de povoamento é o programa responsável pelo controle da impressão

do formulário. É através dele que o formulário é aberto, que os dados são enviados para as
janelas corretas, que é feito o controle de quebra de páginas, que é feito o fechamento do
formulário, etc..., é feita nele. O formulário é apenas um “dispositivo” para output dos dados.
A construção de um programa de povoamento deve ser a seguinte estrutura:
• Abertura de um formulário
• Inicialização de um formulário
• Seleção dos dados do formulário
• Impressão dos dados nas janelas do formulário
• Fechamento do formulário
Abertura de formulário
O primeiro passo para a impressão de um SAPscript através de um programa é a

abertura de um formulário para que se possa fazer o povoamento.
Para que se possa inicializar um formulário é necessário que este esteja aberto.
Portanto, é obrigatória a presença de um comando de abertura num programa de
povoamento.
A abertura de um formulário gera automaticamente a inicialização de um formulário.

O comando para a abertura de um formulário é a seguinte função:
Call function ‘OPEN_FORM’

exporting
* APPLICATION = ‘TX’
* ARCHIVE_INDEX = ‘ ‘
* ARCHIVE_PARAMS = ‘ ‘
DEVICE = ‘PRINTER’
* DIALOG = ‘X’
FORM = (nome do formulário)
LANGUAGE = (idioma do formulário)
* OPTIONS = ITCPO
* importing
* language =
* new_archive_params =
* result =
exceptions
canceled = 1
device = 2
form = 3
options = 4
unclosed = 5
others = 6.
Os parâmetros mais importantes a serem passados para a função são:

DEVICE - Dispositivo onde será gerado o formulário (geralmente PRINTER)
FORM - Nome do formulário a ser aberto
LANGUAGE - Idioma a ser utilizado
Dois outros parâmetros também muitas vezes utilizados são o dialog e o options.
No primeiro, indica-se se a caixa de diálogo para confirmação da impressão deve ou
não ser apresentado. Caso este deva ser omitido, os dados para impressão serão tomados
de uma estrutura a ser colocada no segundo parâmetro. Nessa estrutura são passados os
dados tais como número de cópias e nome da impressora. A opção de não exibição da caixa
de diálogo está diretamente ligada a utilização do segundo parâmetro. Se a exibição estiver
desabilitada (DIALOG=’ ‘), mas a estrutura ITCPO não estiver preenchida, a caixa de
diálogo será exibida.
Alguns dos campos mais importantes e que normalmente são utilizados na estrutura
ITCPO são:
TDCOPIES - Número de cópias
TDDEST - Dispositivo de saída
TDPREVIEW - Print Preview
TDIMMED - Saída imediata

Exemplo de abertura do formulário ZSCR_CURSO.

Call function ‘OPEN_FORM’
exporting
* APPLICATION = ‘TX’
* ARCHIVE_PARAMS = ‘ ‘
DEVICE = ‘PRINTER’
DIALOG =‘’
FORM = ‘ZSCR_CURSO’
LANGUAGE = ‘P’
OPTIONS = ITCPO
* importing
* language =
* new_archive_params =
* result =
exceptions
canceled = 1
device = 2
form = 3
options = 4
unclosed = 5
others = 6.
Neste exemplo, o formulário ZSCR_CURSO no idioma português está aberto, sem a

exibição da caixa de diálogo de impressão, utilizando a impressora IMP1 e executando a
impressão imediata de 2 cópias.
Inicialização de um formulário
A abertura de um formulário automaticamente gera a inicialização do mesmo.

Mas, imagine por exemplo que estejamos gerando relatórios para uma empresa de
computadores onde, para cada novo computador vendido, deve ser gerado um novo
relatório, e esse relatório deve conter todos os componentes presentes no computador em
questão.
A abertura de um formulário inicia o primeiro, mas para cada novo computador
vendido um novo formulário deve ser gerado.
Para isso utilizados o comando de inicialização. Este comando permite que, numa
mesma impressão, sejam gerados vários formulários diferentes, como se estivéssemos
abrindo um novo para cada computador vendido.
Este comando não é obrigatório e pode não ser utilizado caso não haja necessidade
da quebra e criação de vários formulários para uma só seleção de dados.

O comando para inicialização de um formulário é a seguinte função:

Call function ‘START_FORM’
exporting
FORM = ‘ ’
LANGUAGE = ‘ ’
* STARTPAGE = ‘ ‘
* PROGRAM = ‘ ‘
* importing
* language =
exceptions
form = 1
format = 2
unended = 3
unopened = 4
unused = 5
others = 6.
A função é muito similar á função OPEN_FORM, e novamente mais importante são o

nome (FORM) e o idioma (LANGUAGE) do formulário.
Para que se possa utilizar um comando START_FORM é obrigatório que um
comando de OPEN_FORM tenha sido executado.
Seleção dos dados
A seleção dos dados é feita normalmente com comando SELECT e demais

comandos ABAP, como já foi visto em tópicos anteriores.
Um ponto importante que deve ser observado é que não é possível utilizar tabelas
internas e variáveis do programa para a impressão dos dados SAPscript. Portanto, se
algum dado que deva ser impresso estiver numa tabela interna ou variável, este deve ser
copiado para uma estrutura para que possa ser enviado ao SAPscript.
Impressão dos dados nas janelas
A impressão dos dados nas janelas na maioria das vezes é feita simultaneamente
com a seleção dos dados, ou seja, a medida que os dados são selecionados, são enviados
imediatamente para o formulário.

O comando para impressão dos dados é a seguinte função:

Call function ‘WRITE_FORM’
exporting
ELEMENT = ‘ ‘
* FUNCTION = ‘SET‘
* TYPE = ‘BODY‘
WINDOW = ‘MAIN‘
* importing
* pending_lines =
exceptions
element = 1
function = 2
type = 3
unopened = 4
unstarted = 5
window = 6
others = 7.
Dois parâmetros são os mais importantes:

ELEMENT - Determina qual Data Element será utilizado dentro do SAPscript
WINDOW - janela na qual os dados devem ser impressos
Neste ponto fica evidente a diferenciação entre os tipos de janela MAIN e demais
janelas.
Para as janelas do tipo MAIN, cada comando de escrita (write_form) significa uma
nova linha no formulário e o valor a ser impresso é o valor que o campo armazena no
momento do comando de impressão.
Por exemplo, digamos que o campo MARA-MATNR tenha o valor ‘1234’ e que um
comando de impressão seja dado para a janela MAIN que irá imprimir este campo. Logo em
seguida uma nova seleção da tabela MARA é feita e o campo MATNR agora vale ‘5678’. Se
uma nova impressão na janela MAIN for executada o resultado será o seguinte:
1234
5678
Já as janelas que não forem do tipo MAIN imprimem os dados uma única vez, no
final da impressão do formulário ou na quebra de página, com os valores armazenados nos
campos no momento do encerramento ou no momento da quebra, e não no momento da
escrita (write_form), ou seja, se no exemplo anterior fosse utilizada uma janela não-MAIN, o
resultado final seria somente 5678.
Na realidade, a utilização de um comando WRITE_FORM numa janela não-MAIN é
utilizada para a escolha de qual elemento de texto será utilizado para a impressão dos
dados.
Exemplo:
Uma janela HEADER não-MAIN contém dois elementos de texto chamados FRASE1
e FRASE2 da seguinte forma:
/E FRASE1
&MARA-MATNR& Teste de Frase 1
/E FRASE2
&MARA-MATNR& Teste de Frase 2

Se um comando WRITE_FORM for executado para a janela HEADER utilizando o

elemento de texto FRASE1,
Call function ‘WRITE_FORM’
exporting
ELEMENT = ‘FRASE1‘
* FUNCTION = ‘SET‘
* TYPE = ‘BODY‘
WINDOW = ‘HEADER‘
...
estará sendo indicado ao programa que, ao se escrever o formulário, deve ser impresso o
elemento de texto FRASE1 para a janela HEADER (somente um elemento de texto é
utilizado para cada janela não-MAIN).
No caso do exemplo, se o campo MATNR for igual a ‘1234’ no encerramento do formulário,
seria impressa a seguinte frase:
1234 Teste de Frase 1

O elemento de texto a ser impresso será sempre o último a ser selecionado antes do
final ou da quebra de página.
Se nenhum for selecionado, ao encerrar o formulário ou mudar de página serão
impressos os dados que não pertençam a nenhum elemento de texto. Portanto, no caso de
um campo que deva ser impresso sempre em todas as páginas, como número de página por
exemplo, basta coloca-lo fora de qualquer elemento de texto e não selecionar nenhum
elemento de texto para a janela que, automaticamente, este dado será impresso em todas as
páginas.
3 - O Formulário
Trabalhar com um formulário SAPscript não é complicado, desde que se entenda
seus componentes da maneira correta. Um layout é composto por vários componentes,
dentre os quais podemos citar:
3.1. Header
Informações gerais do formulário, como formato e orientação da página em que será
utilizado, parágrafo e fontes default do mesmo (quando não for especificado nenhuma dentro
do form). Nesse tópico aparece também o título do formulário, a classe de desenvolvimento
do mesmo e os idiomas do formulário original e o corrente.
3.2. Parágrafos
São elementos que podem ser criados pelo usuário e apresentam informações dos
textos de uma determinada janela. Nesses parágrafos são determinados tipos de fontes,
tabulações, negrito ou sublinhado, etc...
Para criar um parágrafo novo, utilizar o caminho do menu Processar -> Create
Element, lembrando que em um formulário standard, somente se pode alterar o layout no
idioma original.
3.3. Caracter String

São informações semelhantes às do parágrafo, no que diz respeito a formatação de
textos, no entanto podem ser aplicados a trechos e não necessariamente a linhas do
formulário.

Sua sintaxe de utilização se assemelha a programação HTNL, conforme exemplo a

seguir. Imagine um Caracter string definido com o nome B, cuja formatação de texto seja o
incremento do modelo negrito a uma determinada fonte. Sua utilização seria:
Texto</>
E o resultado seria:
Texto
3.4. Janelas
As janelas são a base da construção do layout. As janelas podem ser criadas sem
limites e tem por finalidade dividir espacialmente as regiões de um formulário para operações
independentes.
Essas janelas podem ser criadas basicamente em 3 tipos distintos:
MAIN
Janelas do tipo MAIN são as mais importantes do relatório (janela pela qual o
formulário se guia). Somente é permitido um tipo de janela MAIN por formulário, e é a única
janela obrigatória em uma página. Pode-se criar mais de uma janela MAIN por página, no
entanto essas janelas, na verdade, só são divididas fisicamente, uma vez que seus
elementos e processamentos obedecem aos mesmos comandos, e não podem ter nomes
diferentes. A passagem de uma janela MAIN para outra pode ser automática ou forçada pelo
usuário. Quando o espaço físico de uma janela MAIN está tomado e necessita-se de mais
dados na mesma, o formulário automaticamente passa à próxima janela MAIN do formulário.
É através desse princípio que um relatório ganha número de páginas automaticamente
quando da execução de um relatório desse tipo, conforme os dados são preenchidos. Para
forçar a passagem de uma janela MAIN para outra, o usuário poderá utilizar o comando:
/: NEXT-WINDOW
A lógica de seqüência das janelas MAIN de um formulário segue a um critério.

Dentro de um a página a navegação de uma MAIN para outra segue de acordo com os
índices dessas janelas dentro do formulário, e quando uma nova página é gerada, a
contagem segue a mesma disposição, continuamente.
O exemplo abaixo, figura a situação de uma diagramação conforme uma página de
jornal. A seqüência de preenchimento dos dados na página através do povoamento segue:
Pág. 1
Pág. 2

VAR
Essa janela apresenta uma característica própria, que necessita de verificação
constante do formulário com seus dados, que podem variar durante a execução do relatório.
Esse tipo de janela deve ser utilizada quando se pretende trabalhar com textos que variam,
como exemplos de mensagens que podem mudar durante o decorrer da execução do
formulário.
CONST
São janelas que não merecem muita preocupação de processamento por parte do
formulário, uma vez que seus dados devem ser mantidos os mesmos desde seu primeiro
preenchimento até o fechamento do formulário. Geralmente nesse tipo de janela são
incluídos objetos e textos que permanecem os mesmos durante todo o relatório,
independente do número de páginas, como logo e rodapés.
Na atual versão do SAP, esta distinção de atenção de processamento do formulário é
só teórica, mas deve ser levada em conta, pois deve ser tratada por versões mais novas do
sistema.
3.5. Páginas
As páginas são elementos responsáveis pelo agrupamento das janelas durante
certos momentos do relatório. Geralmente só são definidas duas páginas, que acabam em
processo reflexivo, por formulário.
Geralmente uma página FIRST, que apresenta um layout de apresentação dos
documentos e outra NEXT, que contém os layouts das outras páginas subseqüentes do
documento. Isso acontece, por exemplo, quando se quer obter um relatório com o logotipo da
empresa na primeira página, mas as seguintes, devem ocupar a folha inteira com os dados
do relatório até o final. Cada uma das páginas criadas devem conter um nome (FIRST, NXT,
...) e pode conter um parágrafo default e um link para a próxima página. Esse link serve para
formar a seqüência em que as páginas do relatório devem ser geradas. Seguindo o exemplo
anterior, deveríamos informar:
FIRST -> NEXT
NEXT -> NEXT
Após a primeira página, seria chamada a segunda, com um layout diferente (sem o
logotipo). A partir dessa, todas apresentariam o mesmo tipo de layout (com dados do
relatório aproveitando a página inteira).
3.6. Page Windows

As page windows podem ser entendidas pelo nosso conceito de layout propriamente
dito. São os elementos responsáveis pelo aparecimento ou não das janelas dentro de uma
determinada página, bem como seus posicionamentos em relação à folha a ser impressa. É
também através das page windows que o programador terá acesso aos Text Elements de
cada uma das janelas, responsáveis pelo tratamento dos dados em tempo de execução do
formulário.
3.7. Text Elements

Corresponde à lógica de processamento e comportamento de uma janela durante a
execução do formulário. É responsável pelos valores que serão impressos no mesmo, bem
como seu posicionamento dentro da janela e seu tipo de caracter.
De dentro de uma Page Window, é possível selecionarmos qualquer uma das
janelas existentes em uma determinada página, simplesmente clicando o mouse sobre o seu
nome e apertando o botão selecionar, ou memso dando um “doublé-click” diretamente sobre

o nome da janela desejada. Uma vez selecionada a janela, se apertarmos o botão Text
Element, uma tela semelhante a do editor de ABAP/4 do SAP irá se abrir, com as linhas onde
a lógica da janela será introduzida.
Nesses elementos do SAPscript, o programador poderá utilizar alguns comandos
semelhantes ao do ABAP/4, com a indicação de que se trata de uma linha de comando para
o formulário (/:, à esquerda da linha). Abaixo, alguns dos comandos que podem ser utilizados
de dentro dos elementos de texto de uma janela em SAPscript:
IF...ELSE…ENDIF
CASE…WHEN
DEFINE
PERFORM…USING…CHANGING
BOX…FRAME
INCLUDE
O comando INCLUDE dentro de uma janela de um formulário SAPscript serve para

inserir um objeto no mesmo. Esse objeto pode ser desde um logo, até um texto com várias
linhas. A sintaxe é bastante simples, e somente deve-se ter um cuidado bastante especial
com o idioma que se trata esse objeto. Independentemente do idioma do formulário, deve-se
sempre utilizar o idioma em que o objeto foi criado.
4 - Manutenção de formulários
A maioria dos formulários é feita pela mesma transação citada anteriormente (SE71).
Nessa ela o nome do formulário e o idioma do mesmo são parâmetros obrigatórios. Nessa
tela são feitas praticamente todas as operações com os formulários do SAP.
4.1. Criar um formulário novo

Um formulário pode ser criado inteiramente a partir dessa transação. Preenchendo
um nome do formulário, que comece por Z ou Y, não diretamente seguidos por caracteres
especiais, como o ‘_’, o usuário poderá apertar o botão Criar ou ir ao menu Layout -> Criar.
O idioma preenchido será entendido como idioma original do formulário. A partir daí, outros
formulários poderão ser traduzidos a partir desse original, nas mais diferentes línguas, porém
todos manterão as características do formulário original. Ao mesmo tempo que uma
alteração desse original, implica na imediata alteração de todos os seus “filhos”.
4.2. Copiar formulários em outro idioma (Tradução)

Uma vez criado um formulário (conforme descrito acima), poderá ser copiado sobre
ele, as informações de um outro formulário do mesmo client, através do menu Layout ->
Copy form, já de dentro da primeira tela do formulário criado (Header).
Atenção que essa cópia é fiel ao formulário copiado, e não poupa nenhuma
informação que já existisse no formulário que recebe a cópia.

4.3. Copiar um formulário de outro cliente

Um formulário pode também ser copiado de um outro client na mesma instância,
através do menu Utilitários -> Copy from client, da primeira janela da transação SE71,
fora de qualquer formulário específico.
Essa opção irá abrir uma outra janela que recebe basicamente 3 informações.
Nome do formulário a ser copiado
Cliente em que se encontra o original
Nome da cópia no client corrente
Os outros dois campos de check Box geralmente não são alterados, pois tratam de
informações como cópia do formulário somente no idioma original e exibição ou não de um
log de erros ao final da execução da cópia.
Uma vez entrados os parâmetros, deve-se apertar o botão Executar e obter uma
cópia com sucesso em todos os idiomas existentes do formulário.
O cliente de origem do formulário, quando for cópia de forms standards, deve ser
mantido 000, uma vez que o repositório dos formulários originais do SAP encontram-se todos
no 000, e podem ser lidos de todos os outros.
5 - Inclusão de logos no formulário
Utilizar logotipos em formulários SAPscript, não é das tarefas mais simples que se
possa ter. Teoricamente falando, o processo é bastante simples e consiste em gerar no
sistema um objeto no formato hexadecimal, que possa ser interpretado pelo SAPscript,
originando a inclusão de uma imagem. No entanto, devido as limitações expostas no começo
deste documento, isso pode levar um certo tempo até reproduzir o resultado desejado.
Para gerarmos o objeto no client desejado (lembre-se que esse objeto não pode ser
transportado...), devemos executar o programa standard RSTXLDMC, com um arquivo no
formato .TIF.
(A figura não pode ter mais de 16 cores)
Preencher o primeiro campo (file name), com o path complexo do arquivo da imagem
do logotipo. Esse caminho pode ser no servidor ou local.
O segundo campo (type) determina se o logotipo deve ser gerado monocromático
(default) ou colorido.
O último parâmetro que exige ser preenchido é o Text Name, onde é feita a
atribuição do nome do objeto que será referenciado de dentro do formulário (padrão: ZHEX-
MACRO-...).
A geração desse logo está intimamente ligado ao formato do arquivo TIF. Isso quer dizer que
o seu tamanho obtido no formulário está relatório ao tamanho da imagem geradora do objeto.
Tomar cuidado com o número de cores da imagem (16 cores) e lembrar na hora de
fazer os testes, que o logotipo não aparece na tela, somente em impressões no papel.

6 - Alteração de Programas / Layout Standards

Na maioria das vezes o trabalho a ser realizado com SAPscript é alterar os originais
do SAP, pois estes raramente atendem às exigências do cliente.
O procedimento para alteração depende muito das características do programa de
povoamento standard e das características das funções do SAP que irão utilizar tal
SAPscript. No entanto, alguns procedimentos são padrão, e outros são utilizados na grande
maioria das alterações.
1. Fazer uma cópia do programa standard e dos includes (se existirem) que necessitam
de alteração
2. Fazer uma cópia do layout standard
3. Não DELETAR janelas, elementos de textos, etc. na cópia do, layoutset. Mesmo que
alguns (ou todos) os dados e janelas do standard não sejam utilizados, o programa
de povoamento continuará tentando executar escritas em janelas e elementos de
dados específicos, já que é uma cópia do standard. Os novos dados e janelas devem
ser apenas adicionados.
4. Encontrar as posições idéias para alterações no programa de povoamento. Quando
os novos dados devem ser impressos na MAIN, procurar por comandos
WRITE_FORM dentro do programa e colocar as alterações o mais próximo possível
do WRITE_FORM correto. Se devem ser impressos em outras janelas, procurar pelo
comando CLOSE_FORM / END_FORM e colocar as alterações imediatamente antes
destes comandos (sempre que possível)
5. Colocar todas as alterações juntas sempre que possível, identificando visivelmente,
através de comentários, o bloco de alterações. Isso facilita a manutenção e
visualização do código, além de facilitar a busca por possíveis erros, visto que, na
sua grande maioria, os programas standard da SAP são bastante complicados.

ABAP - Wagner

Enviado por

Direitos autorais:

Formatos disponíveis

ABAP - Wagner

Enviado por

Dados do documento

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

ABAP - Wagner

Enviado por

Direitos autorais:

Formatos disponíveis

Instruções para o Aluno

Autor: Wagner Eduardo Fernandes

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 2

NOVIDADES NO ABAP WORKBENCH ........................................................................................... 6

ABAP OPEN SQL ................................................................................................................................ 30

ESTRUTURAS DE PROGRAMAS E DADOS ................................................................................. 39

MODULARIZAÇÃO E ESTRUTURA DE PROGRAMAS ............................................................ 47

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 3

MÓDULOS DE FUNÇÃO ................................................................................................................... 85

DIALOG PROGRAMMING – ON-LINE........................................................................................ 106

MODIFICAÇÃO DINÂMICA EM TELAS..................................................................................... 130

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 4

CAPÍTULO 10 .................................................................................................................................... 135

TABLE CONTROL ........................................................................................................................... 135

TABSTRIP .......................................................................................................................................... 147

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 5

Right-Click para mostrar o menu de contexto

Tamanho da tela pode ser alterado

• O Object Navigator é dividido em duas áreas:

• Pode-se escolher funções a partir do menu de contexto em ambas as janelas

• Os objetos do repositório são organizados hierarquicamente:

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 6

• Cada componente de aplicação consiste de múltiplas classes de

• Pode-se entrar com o tipo de lista de objetos e o nome na parte superior da

• Efetuando-se um doublé-click em um sub-objeto na lista de objetos, expande-se a

Lista de objetos Prévia.

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 7

Próxima Lista de Objetos

Lista de Objetos de nível mais alto.

Lista de Favoritos, nela pode-se: Adicionar, Processar o objeto, Mostrar o tipo de

Efetuar o Refresh da Lista de Objetos.

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 8

• Efetuando-se um Right-click em um objeto existente, é possível executa-lo

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 9

Tipos de Dados Locais em Programas (Types)

As características técnicas dos campos são ainda definidas no domínio.

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 10

TYPES: <user_defned_type> TYPE <type>

Quando da definição de types ou variáveis, você pode referenciar types pré-definidos.

Os typos pré-definidos são:

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 11

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 12

Reports (Overview e Técnicas)

Output statements, WRITE... .

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 13

Formato de lista de saída

DEMO/CHAP 02.A WRITE 1

Date 17.10.2001 Time 14:46:10

O comando WRITE gera uma lista de saída.

Por default, a lista consiste em uma página contínua.

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 14

O comando WRITE gera a saída do conteúdo de um campo, ou uma constante, de acordo

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 15

Especificação de Posição e Tamanho

O aditivo ULINE produz uma linha sólida.

 COPYRIGHT ALLIANSYS CONSULTING – 2002 Pág. 16

Sintaxe do commando WRITE

WRITE <format> <value> <options>.

<format> WRITE AT <format> <value> <options>.