Conceito breve do SAP...3
Criação de Listas Básicas...57
Criação de Listas Complexas...62
Criando Tabelas Internas (Estruturas Complexas de Armazenagem Temporária)...73
CRIANDO PROGRAMAS...91
ATRIBUTOS DO PROGRAMA...91
UTILIZANDO CAMPOS DO DICIONARIO ABAP...92
DEFININDO O FLOW CONTROL...94
CRIANDO UMA SEQUENCIA DE TELAS...95
DEFININDO CAMPOS NO MODULE POOL...96
CRIANDO MODULES ABAP...96
O PROCESSAMENTO DO MODULE POOL...96
DEFININDO CHAMADAS VIA TRANSAÇÃO...97
Utilizando SAPSCRIPT...113 Header...114 Basic Setting ...115 Page...116 Windows...117 Page Windows...118 Parágrafo...122 Tabs...123 Text Elements...124 Criação de Bordas...125 Ativando SAPSCRIPT...126 Testando SAPSCRIPT...126 O Relatório...126
1- Overview ABAP/4 Conceito breve do SAP
O SAP é um sistema que trabalha com um número muito grande de tabelas interligadas, que armazenam e manipulam os valores de controle dos processos. Essas tabelas são responsáveis pelo armazenamento dos valores do sistema e são divididas em grupos que se interligam em um todo. Assim, existem tabelas responsáveis pelas informações de FI, outras pelas informações de SD, outras ainda por MM, mas todas elas apresentam campos chaves que permitem, pelos mais diferentes e complicados caminhos, a interligação e consistência de todo o sistema. Embora a ferramenta ABAP/4 dentro do SAP seja muito poderosa e praticamente capaz de permitir qualquer customização do sistema, é muito importante manter os conceitos originais sempre em mente, e nunca tentar forçar alguma coisa que deveria ter um comportamento natural. Por exemplo, nunca tente alterar um valor de uma tabela do SAP (embora perfeitamente possível, com o comando UPDATE), sem um minucioso estudo de suas implicações anteriormente. Isso pode comprometer a integridade dos dados do sistema, se não forem atualizados todos os valores de todas as tabelas relacionadas a essa alteração.
ABAP é a linguagem de programação que a SAP criou para desenvolver as
aplicações do R/3, é focada em tarefas comerciais específicas e é totalmente voltada para atender as necessidades dos usuários deste software, como: processamento de dados em massa, moeda especifica, múltiplos idiomas, etc.
O ambiente de desenvolvimento é muito eficiente no trabalho em equipe, os desenvolvedores não precisam se preocupar com quaisquer problemas de comunicação ou de distribuição entre os diferentes níveis (camadas) do software.
Falando em banco de dados o ABAP também tem suas particularidades, o desenvolvedor não necessita conhecer o banco no qual está rodando o R/3 ( trabalha com vários bancos relacionais), apenas cabe ao programador conhecer o Open SQL, que é uma definição especial de comando para acesso ao banco de dados.
A área de trabalho dos desenvolvedores é chamada de ABAP Workbench e todos os objetos de desenvolvimento criados com as ferramentas do ABAP Workbench são classificadas como objetos do repository. O Repository é uma parte do banco de dados central do R/3 e está organizado por aplicações e dentro das aplicações ainda encontramos uma outra subdivisão denominada Classes de
Desenvolvimento. Todo desenvolvimento do ABAP Workbench tem que estar
relacionado obrigatoriamente a uma aplicação e a uma Classe de Desenvolvimento.
1- Overview ABAP/4 Transações
Transação é um código alfanumérico de 20 caracteres, utilizado para iniciar um processo dentro do sistema SAP. Todo e qualquer processo ou parte dele deve ser executado dentro do sistema através de uma transação. Na customização de ABAP/4, sempre que um GAP do sistema é coberto, isso gera pelo menos uma transação, de modo que o usuário possa executar esse produto customizado de dentro do sistema.
Toda operação realizada através do menu do sistema, também corresponde a uma transação. Um método para conhecermos o código de uma transação cujo caminho pelo menu é sabido, é entrarmos na mesma, e na tela inicial desta transação, utilizarmos o menu Sistema Status, que informa o programa tela e transação executados.
No desenvolvimento de customizações ABAP/4, as principais transações utilizadas, são:
• ABAP Editor (SE38) – para escrita e edição de programas, mais utilizado
para desenvolvimentos de programas do tipo executável (Relatórios e Cargas).
• ABAP Dictionary (SE11) – para edição de objetos relacionados com o
banco de dados e objetos específicos da aplicação.
• Screen Painter (SE51) – para desenho de telas para diálogo de usuário, não
é utilizado para criação de telas de seleção.
• Function Builder (SE37) – para programação de módulos de funções
(sub-rotinas, com interface fixa que estão disponíveis em todo o sistema).
• Repository Browser (SE80) – integra todas as ferramentas do ABAP
Workbench, muito utilizado para criação de programas do tipo on-line ou module pool, pois, facilita e muito a visualização de todos os objetos em uma mesma tela. Todo objeto do ABAP Workbench pode ser editado nessa transação e de uma forma bem mais organizada.
O ambiente de trabalho do ABAP normalmente funciona da seguinte maneira:
• Ambiente de Desenvolvimento ( Client desenvolvimento ABAP e
Client de customizações funcionais/Testes ).
• Ambiente de Qualidade ( onde são feitos os testes de usuários para
aprovação final).
• Ambiente de Produção ( onde realmente os dados da empresa estão
sendo processados).
1- Overview ABAP/4
A área do desenvolvedor ABAP, isto é, o local onde ele irá criar seus objetos será no Ambiente de Desenvolvimento no client específico para isso, os objetos criados ali são amarrados a uma Classe de desenvolvimento e também a uma Change Request/Task (normalmente o gerente de projeto cria uma request onde serão amarradas as Tasks do projeto). No final do projeto cada desenvolvedor libera sua Task para ser transportada e o Gerente após todas as Tasks liberadas pode liberar a Request, nesse ponto entra em ação o pessoal de BASIS que executam o transporte dessa Request para o outro ambiente QA e após os testes feitos e aprovados transporta-se para a PRD.
Instância X Client
Também é muito importante o conceito do funcionamento do ambiente do sistema durante a evolução de um projeto. Inicialmente devemos entender os conceitos de client e instância:
Client – é definido como sendo uma unidade independente do R/3, em termos
comerciais, organizacionais e técnicos. Isso significa que possuem sua própria configuração, dados de aplicação e dados cadastrais (master data).
Instância – é definida como um ambiente do R/3 que agrupa um ou mais
clients, onde se executa um determinado trabalho.
dessa divisão é que se possa trabalhar somando valores, sem que haja conflitos de interesse. Por exemplo, durante um projeto, o client para desenvolvimento das customizações de ABAP deve ser diferente dos outros, pois trabalha muito com testes e alterações constantes, o que inviabiliza outros tipos de serviços.
Se essa divisão muitas vezes ajuda, algumas vezes atrapalha. Geralmente as massas de dados são diferentes nos clients, e o comportamento principalmente nos testes dos produtos customizados pode ser diferente. O recomendado pela própria SAP é que exista um client só para testes, com massa de dados completa que permita “recarga” sempre que necessário, o que permitiria que as condições de teste pudessem ser repetidas. No dia a dia de um projeto isso é muito difícil, pois a manutenção desses clients pelo time de basis geralmente não é muito bem vista.
As instâncias variam também ao longo de um projeto. A medida que o sistema vai sendo refinado, geralmente se inicia uma nova instância livre dos vícios e restos de testes da anterior. Pelo menos 3 instâncias sempre existem durante o período de um projeto. A instância de desenvolvimento,
a de pré-produção e finalmente a de produção. Cada vez que o sistema é migrado de uma instância para a outra, somente deve ser aproveitado o que está comprovadamente funcionando na instância anterior, de modo a diminuir os erros a cada migração.
1- Overview ABAP/4 Client dependent/independent
Esse conceito de objeto client dependent e client independent é necessário estar bem claro, como a base de desenvolvimento normalmente é dividida em client ou mandante alguns objetos quando desenvolvidos em um determinado client somente são enxergados ali (para esses casos é necessário fazer transporte entre clients) e outros são enxergados em todos os clients do ambiente, abaixo está uma relação de objetos para facilitar:
• Código fonte de programas – Independent
• Telas, Menus e Funções - Independent
• Estrutura de tabela, elemento de dados e domínios – Independent
• Registro de dados da tabela – Dependent
• Objetos de Textos, Formulário SapScript - Dependent
Particularidades.
Os programas e outros objetos do repositório criados pelo cliente devem estar no namespace de cliente, ou seja, seus nomes devem começar com as letras Z ou Y (com exceção dos campos em append structures, que devem começar por ZZ ou
quando expressamente orientados pela SAP a fazê-lo (por exemplo, para aplicar notas de correção). A SAP garante que os programas desenvolvidos pelos clientes que observarem as especificações de namespace não serão afetados quando houver uma atualização do sistema, como uma aplicação de Support Package. No entanto, caso seja alterado um programa standard da SAP, não há garantias de que o programa alterado permanecerá como tal após qualquer modificação no sistema. Para agregar funcionalidades a programas da SAP, existe o recurso das User Exits.
2 – Request Ordens (Change Requests): Recurso através do qual um conjunto de
objetos C.D. ou C.I. que podem ser transferidos de um client para outro ou de uma instância para outra.
Utilizam-se ordens para segurança na alteração de objetos já existentes, sejam eles standards do SAP ou customizados, e para efetuar controle de versões destes objetos.
A nomenclatura das ordens é controlada pelo próprio SAP, que promove a criação do código do transporte, no momento em que a manutenção de objetos específicos exige que o mesmo seja associado a uma ordem.
AF1K900109
Objeto SAP (Interno SAP)
Número do transporte
Instância
Tipos de Objetos: Locais ou Transportáveis
Ordens e Tarefas (Tasks): Cada ordem pode possuir uma ou mais Tasks. Cada Task possui os objetos agrupados de acordo com seu tipo e ordem na qual deverão ser criados no Cliente de destino.
Padronização ABAP Factory :
Ordem: 1 programa + objetos associados OU
1 alteração de programa + objetos associados Descrição da ordem:
nome_da_tarefa ou nome_do_produto - Geração Inicial nome_da_tarefa ou nome_do_produto - 1a Correção …
2 – Request Controlando e Administrando Transportes
Uma ordem criada por um determinado usuário garante que os objetos a ele associados ficam “reservados” para tal usuário e somente serão liberados no momento que a ordem for encerrada.
Quando uma ordem ainda permanece associado a um usuário, dizemos que ele está com o status de Modifiable.
Quando uma ordem é encerrada, deixa de estar associado a um usuário e passa a ter o status de Released (liberada), ou seja, os objetos a ela associados são liberados para alteração por outros usuários.
Enquanto uma ordem possui o status Modifiable, pode-se manipular seus objetos livrevente, mudar o usuário responsável transferindo a responsabilidade, ou simplesmente eliminar a ordem, liberando assim seus objetos, ao passo que uma ordem liberada é algo imutável.
Transação SE01 Permite verificar o conteúdo das ordens (objetos) e sua Log
Transação SE09 Permite verificar as ordens de objetos Client Independent
(Workbench Organizer) criados por um determinado usuário, bem como efetuar o Release de tasks e da ordem em si.
Transação SE10 Permite verificar os transportes de objetos Client Dependent e
Client Independent (Customizing Organizer) criados por um determinado usuário, bem como efetuar o Release de tasks e do transporte em si.
Tais transações fornecem informações para que criemos a planilha de controle das ordens criadas e transportadas dentro de um projeto, permitindo assim, conhecermos o histórico da criação e transporte dos objetos entre as várias instâncias.
2 – Request Workbench Organizer
Esta transação permite controlar as ordens (requests) geradas através das alterações feitas nos objetos ABAP.
As alterações são sempre registradas em ordens do tipo local e transportável.
Ordem tranportável: Alterações transportáveis para objetos do ABAP/4
Development Workbench são gravados em ordens transportáveis. Isto permite que as ordens possam ser enviadas ao demais ambientes do SAP, cada ordem gerada para um objeto ABAP/4 consiste em uma nova versão para este objeto, permitindo assim comparar, verificar e consolidar as alterações entre os ambientes de desenvolvimento e produção.
Ordem Local: Alterações não transportáveis para objetos do ABAP/4 Development
Workbench são gravados em ordens locais. Isto garante que as ordens estão sujeitas ao mesmo tipo de controle aplicado aos objetos transportáveis. Da mesma forma, quando uma ordem local é liberada são criadas versões para o objeto.
Nesta opção podemos acompanhar o transporte de todas as requests que foram liberadas
2 – Request
Clicando no botão de transportes podemos acompanhar todas as requests do tipo Desenvolvimento/Correção.
Toda alteração em objetos standard é feita em request’s do tipo Reparação.
2 – Request
Acessando pelo menu Ordem/tarefa Procurar Ordens, podemos efetuar pesquisas nas request do sistema.
Clicando no botão de seleção de valores na seção Tipo de Ordem podemos selecionar os tipos de change request que serão pesquisados.
3 - Dicionário de Dados - Introdução Conceitos de Bancos de Dados Relacionais
Modelo Entidade-Relacionamento
Modelo desenvolvido para facilitar o projeto de banco de dados, permitindo a especificação de um esquema que represente a estrutura lógica global de um banco de dados.
Entidade: É um objeto que existe e é distinguível de outros objetos, ou seja,
identifica o agrupamento de objetos do mesmo tipo. Exemplos: Clientes, Bancos, Agências, Contas-Corrente.
Atributos: São os qualificadores de uma entidade, isto é, representam no modelo
o que uma entidade pretende ser. Exemplos: Nome, RG, CPF, Endereço, Nro Conta, Nro Agência, Nro Banco
Domínio: Conjunto de valores permissíveis para um atributo. Exemplo: Estado
Civil, Sexo, Cor, Meses do Ano.
Relacionamento: É a associação entre duas entidades, ou seja, representa a
maneira como duas entidades estão relacionadas ou ligadas. Exemplos: Conta-Corrente de um Cliente, Agências de um Banco, Contas-Conta-Corrente de uma Agência.
Restrições de Mapeamento: Representam o modo como as diferentes entidades
de um modelo se relacionam. Determinadas pela cardinalidade dos relacionamentos entre as entidades.
Um-para-Um: Uma ocorrência da Entidade A está relacionada com uma e apenas
uma ocorrência da Entidade B.
Um-para-N: Uma ocorrência da Entidade A está relacionada com uma ou várias
ocorrências da Entidade B.
N-para-Um : Várias ocorrências da Entidade A estão relacionadas com apenas uma
ocorrência da Entidade B.
N-para-N: Várias ocorrências da Entidade A está relacionada com várias ocorrências da Entidade B.Modelo Relacional
3 - Dicionário de Dados - Introdução
Um banco de Dados Relacional é a implementação física do Modelo Entidade-Relacionamento e traduz concretamente o que o modelo conceitual procura representar. Consiste em uma coleção de tabelas cada uma das quais associada a
um nome único e que possuem relacionamentos entre si. Tabelas representam fisicamente as Entidades.
Cada tabela possui uma estrutura similar àquilo que pretende a representar, isto é, tabelas são formadas de linhas que por sua vez são formadas por colunas. Colunas representam fisicamente os Atributos.
A cada linha da tabela chamamos de Ocorrência e o conjunto de ocorrências pode ou não estar relacionado com ocorrências de outras tabelas.
Como distinguir as ocorrências umas das outras? Utilizando o conceito de Chave Primária!!
Chave Primária: Conjunto de atributos que garante a unicidade de cada ocorrência
da tabela. Exemplos: RG, CPF, Nro Chassis.
Normalização: Processo de reconhecimento da chave primária
Como representar os relacionamentos entre tabelas? Transferindo a chave primária de uma tabela para a outra!!
Chave Estrangeira: Quando a chave primária de uma tabela é um atributo em
outra(s) tabela(s).
3 - Dicionário de Dados - Introdução
pelo usuário para uso posterior, além de vários itens auxiliares ao desenvolvimento de programas (p.ex. search helps).
Podem ser definidas tabelas e visões dentro do dicionário. O R/3 se encarrega, durante a ativação desses elementos, de criá-los no banco de dados. O dicionário permite, ainda, a criação de índices, que agilizam as buscas. A definição de índices apropriados é de suma importância para o bom desempenho do sistema. Cabe lembrar que uma busca sem índice realizada em uma tabela extensa pode ter pesado custo em termos de performance.
As definições de tipos de dados dentro do R/3 incluem os elementos de
dados, que definem um tipo elementar descrevendo o tipo básico de dados, o
comprimento e, eventualmente, as casas decimais; as estruturas, que podem receber elementos de vários tipos (semelhante à representação de um registro numa tabela); e os table types, que seriam “campos” em formato de tabela. Por exemplo, uma estrutura do registro de uma estrutura de usuário que tivesse um campo para números de telefone poderia usar um table type e permitir colocar vários números num mesmo campo.
Além dessas definições, o dicionário ABAP permite criar os search helps, que são tabelas de busca auxiliares aos campos de tela – são as buscas e tabelas que aparecem quando se tecla F4 dentro de um campo em qualquer tela do R/3. Criando documentação para o elemento de dados dentro do dicionário, automaticamente está disponível a ajuda do campo, que pode ser invocada usando-se a tecla F1 dentro dos campos de tela. Pode-se, ainda, definir
verificações de entrada automaticamente, bastando definir uma relação de foreign key.
No dicionário também são criados os objetos de lock, que permitem definir o travamento de dados dentro do R/3. Por exemplo, podem-se definir objetos de lock para impedir que dois usuários editem a mesma informação ao mesmo tempo no sistema.
O dicionário é integrado às ferramentas de desenvolvimento e execução do R/3, permitindo o acesso das ferramentas às definições nele contidas. Por exemplo, é possível navegar de um programa que esteja sendo criado no editor ABAP para definições de campos, elementos e tabelas usadas no programa.
3 - Dicionário de Dados - Tipos de Dados 1. Dados elementares pré-definidos
Detalhes básicos dos tipos mais utilizados e exemplos de utilização:
• I - campos numéricos sem decimais, contadores, etc.
• P – campos numéricos com decimais, quantidade e moeda. Tomar cuidado com cálculos feitos entre campos com número de casas decimais diferentes.
• C – campo alfa, mais utilizado para conter textos, pode conter números e até efetuar cálculos, mas não é usual.
• N – campo alfa, utilizado para conter números sem decimais e preenchidos com zero a esquerda.
• D – campo data, é armazenado no banco de dados no formato AAAAMMDD, é mostrado em tela de acordo com a customização de cada usuário, permite-se fazer contas do tipo “20041201 + 31 = 20050101”.
• T - campo hora, é armazenado no banco de dados no formato HHMMSS, é mostrado em tela de acordo com a customização de cada usuário.
3 - Dicionário de Dados - Tipos de Dados 2. Dados definidos no programa
Entre as formas de tipos de dados mostrados acima, as mais usadas no desenvolvimento de programas ABAP/4 são:
• 1 - Estrutura: consiste em vários campos com tipos de dados elementares e tem tamanho fixo. (array)
• 3 – Tabela Interna: é uma estrutura que pode variar em tamanho, no que diz respeito a linhas. (matriz)
• Os outros tipos acima, são variações dos dois já explicados e muito pouco utilizados nos programas.
Exemplos:
TYPES: number TYPE i,
length TYPE p DECIMAL 2, code(3) TYPE c.
TYPES: BEGIN OF <estrutura>, <campos>…..
END OF <estrutura>.
3 - Dicionário de Dados - Tipos de Dados 3. Tipo de dados do Dicionário de Dados ABAP.
• Elemento de Dados: é a definição semântica para um campo individual, nele
colocamos os textos do campo e amarramos a um domínio.
• Domínio: e a definição técnica do campo, onde colocamos o tipo de dados, o
tamanho do campo e tabela de valores possíveis.
• Estrutura: São conjuntos de campos elementares ou do próprio tipo
estrutura e são utilizadas para referências em tela ou no programa.
• Tabela Transparente (database table): São as tabelas que possuem uma
estrutura criada no dicionário de dados e que são refletidas no banco de dados, são elas que contém os dados necessários para o sistema, através de instruções do ABAP OPEN SQL conseguimos obter essas informações.
• Visões: São agrupamentos de <n> tabelas transparentes que possuem
ligações entre si, funciona como se fosse um INNER JOIN só que já está pré-criado no dicionário de dados, pode ser utilizada no SELECT como se fosse uma tabela normal.
3 - Dicionário de Dados – Definições Transação – SE11
Uma tabela consiste de colunas (campos) e linhas (registros). Cada tabela possui um nome e atributos, como por exemplo, a classe de desenvolvimento e a autorização para manutenção. Cada campo deve ter um nome único dentro da tabela, e pode fazer parte de uma chave. Cada tabela deve ter uma chave
primária, que é composta por campos cujos valores identificam unicamente os
registros de uma tabela. As tabelas definidas no dicionário de dados do R/3 são criadas no banco de dados assim que ativadas.
Durante a ativação, a descrição da tabela dentro do dicionário é traduzida para a definição de tabela correspondente na linguagem do banco de dados que estiver sendo usado. A ordem dos campos no banco de dados não precisa seguir a ordem estabelecida no dicionário de dados (com exceção dos campos de chave primária), o que permite a extensão das tabelas standard do R/3 através e append
structures, que são definições de campos adicionais definíveis pelo usuário sem
haver a necessidade de alteração da definição normal da tabela Standard. Os includes são estruturas definidas separadamente que podem ser inseridas em outras tabelas.
3 - Dicionário de Dados – Definições Entendendo melhor: Elemento de Dados e Domínio
Basicamente, as tabelas dentro do R/3 são compostas de campos, cada um usando um determinado elemento de dados, que por sua vez usam domínios. O domínio define o tipo básico de dados, seu comprimento e o intervalo de valores permitido; o elemento de dados descreve o significado de um domínio dentro de um determinado cenário. Por exemplo, um campo de código de aeroporto de destino deve estar ligado a um elemento de dados “aeroporto de destino”, que por sua vez usa um domínio “código de aeroporto”, que está definido como três posições de caractere, apenas com letras.
As características técnicas das tabelas do R/3
Quando uma tabela é definida no dicionário de dados do R/3, devem ser definidas as características técnicas (technical settings) para a tabela. Essas características são usadas para otimizar o acesso e a armazenagem da tabela individualmente.
As características técnicas podem ser usadas para definir como a tabela deve ser manipulada quando for criada no banco de dados, se ela deve ser incluída em
buffer e de que forma, e se as mudanças nela realizadas devem ser registradas em log.
Para definir a armazenagem da tabela, deve-se indicar uma classe de dados. Essa classe de dados determina de que forma o banco de dados deve armazená-la. As classes principais são master data, transaction data, organizational data e
system data. Os dados mestres devem ser classificados como master data, os
dados transacionais como transaction data, a configuração funcional como organizational data e os dados de sistema como system data. Geralmente, dentro de um projeto, são criadas tabelas dos tipos master e transaction somente. De posse dessa informação, o R/3 separa as tabelas em diferentes arquivos do banco de dados de forma a otimizar a performance.
A categoria de tamanho das tabelas permite ao R/3 alocar espaço no banco de dados de acordo com o tamanho projetado para a tabela, de modo a evitar fragmentação dos dados.
Pode-se definir que uma determinada tabela será armazenada em buffer de memória. Com isso, o acesso à tabela é otimizado, mas deve-se usar de bom senso para colocar tabelas em buffer. Por exemplo, tabelas candidatas a entrar no buffer são dados mestres com muita utilização e raramente atualizadas. Tabelas de dados transacionais não devem ser colocadas em buffer, pois cada registro dentro delas é menos freqüentemente acessado que nas tabelas de dados mestres, e estão sujeitos a atualizações. A atualização de uma tabela que esteja no buffer provoca seu re-carregamento com conseqüente impacto no desempenho dos programas.
O buffer pode ser definido nos modos full, no qual a tabela inteira é colocada no buffer, single-record, onde apenas os registros eventualmente acessados são colocados no buffer, e generic, no qual são colocados no buffer registros que tenham determinados valores na chave. Os dados não são automaticamente colocados no buffer assim que o sistema entra no ar; isso só acontecerá no primeiro acesso a um registro que esteja em um intervalo de buffer.
Caso seja necessário, pode-se definir o registro em log das alterações feitas numa tabela. Porém, deve-se ter em mente que isso pode criar um impacto na performance do sistema.
3 - Dicionário de Dados – Visibilidade e Referência Visibilidade dos Tipos de Dados
Conceito “LIKE”
Eu utilizo o comando LIKE na criação de um tipo de dados dentro do programa ABAP para referenciar diretamente o objeto a um tipo de dados do Dicionário de Dados ABAP, isto é muito utilizado, pois, se eu estou trabalhando com um campo que é reflexo de um campo que já existe em uma tabela transparente eu não preciso descobrir o tipo e tamanho do campo para defini-lo no programa basta eu referenciá-lo utilizando LIKE.
Exemplos:
Type: <t> LIKE <obj>.
Exemplo Criação de Tabela, Manutenção e criação de transação
Criando uma tabela transparente customizada (tcode SE11). Por exemplo ZCONTROLE.
Definir as características da tabela transparente.
Definir as opções técnicas e <Salvar>.
Ao final ativar a nova tabela criada.
3 - Dicionário de Dados – Definições
Atribuir as opções técnicas.
Agora vamos definir a manutenção da tabela transparente. Para acessar o “Gerador de atualização de tabela”, selecionar no menu Utilitários conforme descrito abaixo.
Definir os parâmetros de manipulação da tabela transparente.
Definir o Grupo de Função a ser utilizado pelo Repository Object (tcode SE80).
3 - Dicionário de Dados – Definições
Selecionar o objeto.
Definir as características do objeto Grupo de Função.
Selecionar a “Classe de Desenvolvimento” a ser utilizado e <Salvar>. Criar uma nova Request e Avançar <Enter>.
O grupo de função definido será criado na classe de desenvolvimento.
3 - Dicionário de Dados – Definições
Criar novo objeto.
O novo Grupo de Função foi definido.
Para que o usuário tenha acesso a manutenção da tabela customizada, utilizar o caminho apresentado abaixo.
3 - Dicionário de Dados – Definições
Pode ser utilizado telas de atualização de duas categorias:
apenas um nível (apresenta a síntese da tabela e a alteração da entrada de dados é
efetuada nesta tela mesmo); 2 níveis: um nível de tela de síntese e uma tela seguinte somente para alterar a entrada de dados.
Nesta tela de visão de tabelas é possível efetuar a atualização de dados.
Esta tela de atualização é a “tela de síntese” (o 1º nível de acesso definido na geração de manutenção).
3 - Dicionário de Dados – Definições
Permite o cadastramento de dados novos na tabela.
Esta tela de atualização é a “tela individual” (o 2º nível de acesso definido na geração de manutenção).
A seguir é apresentado a entrada efetuada na tabela pela tela de atualização individual.
PARA ACESSAR A MANUTENÇÃO DA TABELA VIA TRANSAÇÃO CUSTOMIZADA.
Criar uma nova transação pelo Repository Object (tcode SE80).
Selecionar a opção de “transação c/parâmetros”.
Definir as características da transação.
Definir também a tabela a ser acessada.
Selecionar a “Classe de Desenvolvimento” a ser utilizado e <Salvar>. Criar uma nova Request e Avançar <Enter>.
4- Editor ABAP Utilizar a transação para “Atualização de tabela ampliada”. Definir os parâmetros da tabela a ser atualizada .
Editor ABAP/4
O editor de programação ABAP/4 do SAP pode ser encontrado através do caminho :
Menu SAP Ferramentas ABAP Workbench Desenvolvimento Editor Abap
4- Editor ABAP
ou pela transação SE38.
Uma tela para a entrada do nome do programa é aberta, como exemplificada abaixo. Para criar um programa novo, utilize um nome ainda não existente no repositório, e apertar o botão Criar. Para editar ou exibir um programa já existente, entrar com o nome do programa e apertar os botões respectivos.
Existe um padrão de nomenclatura que deve ser seguido, não só para nome de programas, mas para todos os desenvolvimentos no SAP R/3. Esses padrões podem variar de projeto a projeto e principalmente com a versão do SAP com a qual se está trabalhando. Em todos os casos os nomes dos desenvolvimentos começam sempre com Z ou Y.
Antes de iniciarmos o estudo dos Reports, devemos entender primeiro o conceito de Report dentro do SAP. Apesar do nome indicar que são relatórios, Report tem uma abrangência maior do que isso. Devemos entendê-los como programas, que são capazes de fazer muito mais coisas do que exibir relatórios.
4- Editor ABAP
No editor ABAP, além de digitar o código fonte do programa, é possível também efetuar outras tarefas e adicionar outros objetos inerentes à sua execução.
Na janela de “Objetos parciais” há 5 opções básicas de objetos associados a um programa ABAP:
Texto fonte: Através desta opção acionamos o editor de programas ABAP.
Variantes: Definem-se os valores pré-definidos para os parâmetros de execução de
um programa ABAP. Os parâmetros de um programa são definidos pelos comandos Parameters e Select-options do ABAP.
Atributos: Definem-se os atributos de programa, como classe de desenvolvimento,
título, categoria, status, aplicação, etc.
Documentação: Texto com uma descrição breve do que o programa executa e as
suas condições necessárias para execução.
Elementos de texto: Definem-se os textos que serão relacionados às mensagens,
rótulos de parâmetros do programa e títulos e nome de colunas para o relatório gerado pelo programa.
Criando um programa passo-a-passo.
Entrar no editor ABAP na transação SE38, preencher o nome do programa começando com “Z”, clicar em create.
Entra do código fonte
Para editar variantes de execução do programa Editar os atributos do Programa
4- Editor ABAP
Logo após entrar com os atributos do programa, entrar com a Classe de Desenvolvimento/Package (perguntar para o gerente qual classe de desenvolvimento se não estiver na especificação)
Quando a escolha for SAVE/SALVAR, deve-se entrar com a REQUEST/TASK. Aplicação: Você entra com o
módulo ou a aplicação que o programa faz parte
Clicar em SAVE
Entrar com a Classe de Desenvolvimento
SAVE – para amarrar a uma
Request/Task Objeto Local – quando não vou
transportar – somente teste
4- Editor ABAP
Para evitar maiores problemas crie um habito de salvar – verificar – ativar.
Verificação de sintaxe é muito importante ir verificando a sintaxe sempre, pois, isso facilita para encontrar os erros, caso dê algum erro na verificação de sintaxe aparecerá da seguinte forma.
Clicar aqui ou tecla F4, para escolher uma Request já criada
Clicar em Criar – quando for amarrar em uma nova request
OK – após escolher Req.
Prestar atenção no Status, sempre deixar active, se for feita uma alteração e salva, mas não ativa, o depurador considera a última ativa. 1º - Salvar 2º - Verificar, faz a verificação de sintaxe. 3º - Ativar, ativa a versão atual Testar – para execução do programa direto do código fonte
Caso ocorra algum erro na verificação de sintaxe, aparecerá assim. O(s) erro(s) logo abaixo do código fonte.
Para ir direto na linha que está acusando erro clicar aqui
4- Editor ABAP Criando telas de Seleção:
SELECTION-SCREEN: comando utilizado para definir a tela de seleção, com ele
pode se criar blocos dentro de uma mesma tela, incluir frames com textos explicativos, etc.
PARAMETER: è utilizado para criação de um campo único de seleção, obter as
suas variações de sintaxe através do help (F1).
SELECTION-SCREEN BEGIN OF BLOCK bloco3 WITH FRAME TITLE text-003. PARAMETER: p_num1 TYPE i,
p_sin(1) TYPE c, p_num2 TYPE i.
PARAMETER: P_MATNR LIKE MARA-MATNR. SELECTION-SCREEN end of BLOCK bloco3.
OBS: TEXT-003 é uma forma de se incluir textos de uma forma dinâmica, para criar
esses objetos digite text-003, dê dois clicks e se não existir o editor vai perguntar se você deseja criar. Você entra com o texto na linguagem e depois faz a tradução para as outras linguagens na transação SE63.
• TYPE: está definindo o tipo da variável de tela de seleção, deve-se entrar
com o tamanho e o tipo do dado a ser armazenado.
• LIKE: está definindo o tipo da variável de tela de seleção por referência,
dizendo que a variável terá o mesmo tipo e tamanho da variável MATNR da tabela MARA que estão no Dicionário ABAP.
• Utilização no SELECT: para utilização no comando select, usa-se o
comparativo = ou EQ caso o campo esteja em branco ele busca todos os
registros que tenham conteúdo igual a branco.
SELECT-OPTIONS: è utilizado para criação de um campo de/até de seleção com
várias opções de comparações, obter as suas variações de sintaxe através do help (F1).
TABLES: MARA.
SELECTION-SCREEN BEGIN OF BLOCK bloco4 WITH FRAME TITLE text-004. SELECT-OPTIONS: S_MATNR FOR MARA-MATNR.
SELECTION-SCREEN end of BLOCK bloco4.
• FOR: Para a opção Select-options utilizasse FOR no lugar do LIKE.
• TABLES: O Comando tables, disponibiliza a estrutura da tabela do banco de
dados, para ser utilizada dentro do programa, é obrigatória essa disponibilização quando a tabela vai ser utilizada no FOR.
• TABELA DO SELECT-OPTIONS:
• Utilização no SELECT: para utilização no comando select, usa-se o
comparativo IN e automaticamente ele já entende o tipo de comparação a fazer, caso o campo esteja em branco ele busca todos os registros.
Where MATNR IN S_MATNR.
• Para alterar os textos que aparecem na tela de seleção:
SIGN OPTION LOW HIGH
I EQ MATERIAL
I BT 100 200
Clicando aqui, você pode definir várias comparações a serem feitas na seleção
4- Editor ABAP Alguns Comandos:
• DATA: é utilizado para definir uma variável de qualquer tipo (simples, estrutura
ou tabela interna). DATA: V_num TYPE i.
DATA: v_matnr LIKE mara-matnr. DATA: s_mara LIKE mara.
DATA: begin of t_mara occurs 0, matnr LIKE mara-matnr,
end of t_mara.
• IF e CASE: são utilizados como comparativos na lógica do ABAP.
IF p_sin = '+'. Ou
v_num = p_num1 + p_num2. ELSEIF p_sin = '-'.
v_num = p_num1 + p_num2. ELSE.
ENDIF.
Detalhes:
o No término de toda instrução ABAP, deve ter um ponto final, para evitar repetições pode-se utilizar “:” após o comando e “,” separando as instruções, mas, deve terminar com ‘.’
o Quando me referencio a uma string utilizo “ ‘ “ aspas simples.
• MOVE ou “ = “: esses são os comandos de atribuição de valores.
MOVE: 2 to v_num, 'MATERIAL to v_matnr. ou v_num = 2. v_matnr = ‘MATERIAL’.
• WRITE e WRITE ... TO ... : Utilizado para imprimir em tela, pode se também
mover o resultado dessa impressão para dentro de outra variável. Quando se executa o comando write o ABAP faz todas as traduções necessárias de acordo com a configuração do usuário (moeda, quantidade). Ver variações com o F1.
write: / v_num. Ou write; v_num to v_aux. CASE p_sin.
WHEN '+'.
v_num = p_num1 + p_num2. WHEN '-'.
v_num = p_num1 + p_num2. WHEN OTHERS.
ENDCASE. Na SE38 – Escolher
opções Elemento de textos e <Modificar>
4- Editor ABAP Executando Programa: Alguns Exemplos EXEMPLO 1 REPORT ZEXP0001. WRITE: '111111'. WRITE: '222222', '333333'. WRITE: /'111111'. WRITE: 15 '333333'. WRITE: / TEXT-001. ULINE. ULINE 8(6). SKIP. SKIP 2. WRITE : 8 SY-LANGU.
WRITE : / SY-DATUM UNDER SY-LANGU.
Existem alguns tipos de variáveis chamadas de variáveis do sistema. Elas possuem informações e dados do processamento, como o idioma de acesso (sy-langu), a data (sy-datum), a hora (sy-uzeit), etc.. Essas informações estão contidas na estrutura SYST (Campos de sistema ABAP, que pode ser abreviada para SY) e podem ser acessadas conforme o exemplo acima, o nome da estrutura mais o campo que se deseja.
EXEMPLO 2
REPORT ZEXC0002 NO STANDARD PAGE HEADING. WRITE 'PAG 1'.
NEW-PAGE. WRITE 'PAG 2'. TOP-OF-PAGE.
WRITE : 'EXEMPLO 2 - CURSO ABAP/4', 80 'Page',
SY-PAGNO. ULINE.
Na SE38 – é só clicar aqui ou tecla F8 aqui ou dentro do código fonte
4- Editor ABAP EXEMPLO 3
REPORT ZEXP0003. WRITE : 'NORMAL'.
FORMAT INTENSIFIED OFF. WRITE : 'NEGRITO '.
FORMAT COLOR 1. WRITE : 'FUNDO AZUL'. FORMAT COLOR OFF. FORMAT INTENSIFIED ON. WRITE : 'NORMAL'.
EXEMPLO 4
REPORT ZEXP0004.
DATA: NOME(20) TYPE C, RG(10) TYPE I,
DATA LIKE BKPF-BUDAT, HORA(8) VALUE '14:05:45'. MOVE 'Solution Center' TO NOME. RG = 42159818. DATA = '19973005'. SKIP 2. WRITE: 'Nome:', NOME, / 'RG:', RG UNDER NOME, / 'Data:', DATA, / 'Hora:', HORA.
4- Editor ABAP EXEMPLO 5
REPORT ZEXP0005.
PARAMETER: P_NOME1(15) TYPE C,
P_NOME2(15) TYPE C DEFAULT 'Abap Factory', P_BOTAO1 RADIOBUTTON GROUP G1,
P_BOTAO2 RADIOBUTTON GROUP G1. WRITE P_NOME1.
IF P_NOME2 NE 'ABAP FACTORY'. WRITE P_NOME2.
ENDIF.
IF P_BOTAO1 = 'X'.
WRITE / 'BOTÃO 1 ACIONADO'. ELSE.
WRITE / 'BOTÃO 2 ACIONADO'. ENDIF.
5- Open SQL
O ABAP oferece um conjunto de comandos que permite realizar operações com os dados armazenados no banco, o Open SQL. A idéia central do Open SQL é prover uma linguagem de acesso ao banco independente de plataforma. Os comandos Open SQL têm de passar pelo interpretador ABAP, que os traduz para os comandos SQL do banco de dados que esteja sendo utilizado.
Comandos
Dentro do Open SQL, podem-se utilizar os seguintes comandos:
• SELECT: permite a leitura de dados do banco de dados.
• INSERT: insere dados no banco.
• UPDATE: atualiza dados.
• MODIFY: atualiza dados existentes ou os acrescenta caso não existam no banco.
• DELETE: apaga registros do banco de dados.
• OPEN CURSOR, FETCH, CLOSE CURSOR: respectivamente cria, lê e fecha
um cursor dentro do banco de dados.
Campos de sistema
Os dois principais campos de sistema envolvidos em operações do Open SQL são o SY-SUBRC, que retorna zero caso a operação tenha sido bem-sucedida, e o SY-DBCNT, que retorna o número de registros afetados pelo comando.
Trabalhando com os Mandantes
Num comando Open-SQL não é necessário especificar o mandante nas cláusulas discriminadoras dos comandos. Automaticamente, o interpretador ABAP definirá o mandante como o mandante atual, a não ser que seja especificada a opção CLIENT SPECIFIED.
5- Open SQL SELECT
O comando SELECT retorna um conjunto de dados (registros) que atendam a um determinado critério. As cláusulas do comando SELECT são as seguintes:
• SELECT <lista de campos>: Pode-se selecionar uma lista de campos a
serem retornados, separados por espaços, ou o caractere * para retornar todos os campos disponíveis. A opção SINGLE retorna somente um registro que atenda às restrições impostas. Caso a tabela tenha sido declarada através de TABLES, é automaticamente criado um registro na memória com o mesmo nome para manipulá-la; caso o SELECT traga campos de mais de uma tabela, não é possível utilizar esse artifício. Nesse caso, as tabelas não precisam ser declaradas em TABLES, mas a seleção dos campos deve separar o nome da tabela e o campo com um til (~). Exemplo:
TABLES: SFLIGHT.
DATA: T_SFLIGHT LIKE SFLIGHT.
SELECT CARRID CONNID FLDATE SEATSOCC FROM SFLIGHT INTO TABLE T_SFLIGHT.
• INTO [<lista de campos>| TABLE <tabela interna>]: Permite armazenar o
retorno numa tabela interna ou em campos definidos com o comando
DATA. O uso de SELECT sem especificar SINGLE ou INTO TABLE
exige o uso de ENDSELECT.
• FROM <tabela> [[INNER|LEFT OUTER] JOIN <tabela>, ..]: Especifica a
origem dos dados.
• FOR ALL ENTRIES Usado quando selecionamos dados de uma
tabela e precisamos de dados de outra tabela para compôr as condições do where.
SELECT * FROM dtab FOR ALL ENTRIES in itab where…
EXEMPLO:
SELECT * FROM BSEG FOR ALL ENTRIES IN T_BKPF WHERE BUKRS = T_BKPF-BUKRS
AND BELNR = T_BKPF-BELNR AND BELNR = T_BKPF-BELNR.
5- Open SQL NOTA: se itab estiver vazia, esse comando selecionará todo o conteúdo da tabela,
pois nenhuma restrição está sendo colocada. Uma maneira de fazer essa verificação é a seguinte:
IF NOT itab[] IS INITIAL. “ se itab não está vazia SELECT * FROM dtab FOR ALL ENTRIES in itab where campo = itab-campo …
ENDIF. “ fim do: se itab não está vazia
• WHERE <condições>: A cláusula WHERE especifica as condições de busca.
Por exemplo, WHERE CARRID = ‘AA’ faz com que apenas os registros em que o campo CARRID tenha conteúdo igual a ‘AA’ sejam retornados.
Maiores detalhes sobre o comando SELECT podem ser encontrados no Help On-Line do R/3.
TESTE – SELECT: Para saber se o select encontrou algum registro ou não,
utilizamos uma variável de sistema SY-SUBRC, se o conteúdo dessa variável for 0 encontrou, caso contrário não encontrou nenhum registro. E isso vale para também para todos os comandos ABAP, quando executado com sucesso SY-SUBRC é igual a zero.
Se sy-subrc = 4 : nenhum dado foi lido
INSERT: O comando INSERT insere um novo registro no banco de dados, a partir de uma área de dados especificada em TABLES ou uma área declarada com DATA. Para usar INSERT, devem-se colocar os dados desejados na área
intermediária e, em seguida, chamar o comando INSERT. Caso a área não seja especificada em TABLES, deve ser usada a opção FROM:
UPDATE: O comando UPDATE funciona como o comando INSERT, podendo alterar dados no banco a partir de uma área ou tabela interna. No caso da tabela interna, não é necessário especificar a cláusula WHERE: serão alterados os registros correspondentes de acordo com as chaves.
MODIFY: O comando MODIFY opera da mesma forma que o comando UPDATE, mas insere um novo registro caso o registro especificado não exista.
DELETE: O comando DELETE elimina registros do banco. Ele opera da mesma forma que o comando INSERT.
5- Open SQL LUW – COMMIT e ROLLBACK: Quando trabalhamos com alteração nos dados do
banco, é bom sabermos que todas as alterações que estamos fazendo ainda não aconteceram efetivamente no banco, isso só ocorre quando encontra-se o primeiro comit, automaticamente quando acaba a execução de um programa já é executado um commit: Exemplo: INSERT <tabela1>. IF SY-SUBRC = 0. INSERT <tabela2>. IF SY-SUBRC = 0. COMMIT WORK. ELSE. ROLLBACK WORK. ENDIF. ENDIF.
Considerações sobre os diferentes tipos de select (PERFORMANCE)
1 - SELECT * FROM …<tabela>
(Quando não se impõe nenhum tipo de restrição, ocorre uma varredura sequencial dos registros da tabela. Quando se utiliza grandes tabelas, isso obviamente afeta o runtime.
Performance: Select * - seleciona todas as colunas de uma tabela. É melhor sempre especificar as colunas, pois em caso de tabelas com muitas colunas, prejudicará a performance).
2 - SELECT * FROM <tabela> WHERE <campo> eq <conteúdo>.
(Lê todos os registros da tabela especificada onde o campo é igual ao conteúdo especificado)
Performance: Select * Where - seleciona todas as colunas de uma tabela de acordo com a condição de where. É melhor sempre especificar as colunas, pois em caso de tabelas com muitas colunas, prejudicará a performance.
3 - SELECT * FROM <table> WHERE <table field> BETWEEN <field1> and <field2>.
Ex.: field1 = 100 e field2 = 500. Pega inclusive 100 e 500. Você trabalha com o range.
4 - SELECT * FROM <table> WHERE <table field> LIKE ….’_R%’. _ = a primeira letra não importa o que virá
a segunda deverá ser R (eu defini)
% = não importa a sequência de caracteres que virá.
5- Open SQL
5 - SELECT * FROM <table> WHERE <table field> IN (…….,…….).
Exemplo: select * from <table> where campo1 in (123,1000) - podem ser valores ou literais
É como perguntar se campo1 é 123 ou 1000.
6 - SELECT * FROM <table> WHERE <table field> IN <internal table>. Exemplo:
DATA : begin of ITAB occurs 10,
sign(1), option(2), low like sflight-price, high like sflight-price, end of ITAB.
* RANGES: ITAB for sflight-table
Move: ’I’ to itab-sign, ‘bt’to itab-option, ‘500’ to itab-low, ‘1000’ to itab-high. Append itab. Move: ’I’ to itab-sign, ‘bt’to itab-option, ‘440’ to itab-low. Append itab.
7 - SELECT * FROM <table> ORDER BY <field1> <field2> … PRIMARY KEY. Obs.: Classifica a tabela interna numa área auxiliar, sem afetar a tabela original. Evitar o uso de sorts dentro de um select. Consome mais tempo que descarregar os dados em uma tabela interna e classificá-los.
8 - SELECT * FROM <table> BYPASSING BUFFER.
(Usado para ler diretamente da tabela original, e não do buffer).
OBS.: Select single * sempre com chave completa especificada. Particularidade do Abap/4
Select * - procurar evitar. Informar as colunas que serão necessárias, apenas.
Uso de comando extract (insert header, details) – para relatórios
9 - SELECT * FROM <table> APPENDING TABLE <internal table>. (Lê os registros e os inclui - não sobrepõe - em um internal table).
10 - SELECT …FROM <table> INTO TABLE <INTERNAL TABLE> .
(A estrutura da tabela interna deve corresponder à estrutura da tabela que está sendo acessada. O sistema lê os registros em conjunto, não individualmente, e os coloca dentro de uma internal table. Este processo é mais rápido que ler
5- Open SQL
11 - SELECT …. INTO CORRESPONDING FIELDS OF TABLE <itab>.
(Neste caso a estrutura da tabela interna não precisa corresponder à estrutura da tabela que está sendo acessada. <itab> é o nome da internal table. Movimentará os registros para as colunas definidas na internal table que possuam nome igual ao da tabela acessada).
Obs.: corresponding ou appending corresponding não exigem o endselect. 12 - SELECT ….. APPENDING CORRESPONDING FIELDS OF TABLE <itab>. ( Lê e grava (não sobrepõe) os dados em uma internal table que possua nomes idênticos aos nomes da tabela que está sendo lida).
13 - SELECT SINGLE * FROM SPFLI WHERE …..<campo>….. EQ … <conteúdo> (Toda vez que se usa select single * a chave primária completa deve ser
especificada. Se a chave especificada não é qualificada, você receberá uma mensagem de warning e a performance ficará prejudicada).
No caso de haver a necessidade de acessar um único registro via select, as opções são: select * ….. seguido de comando exit OU select * … up to 1 row.
Neste caso não é necessário especificar a chave completa.
14 - SELECT <a1> <a2> … INTO (<f1>, <f2>, … ) FROM ….<tabela> WHERE …… .
Lê as colunas especificada (a1, a2). Após INTO deverão ser especificadas as áreas de trabalho auxiliares (f1, f2). O número de colunas lidas deverá ser igual ao
número de work-areas especificadas.
15 - SELECT MAX(campo) MIN(campo) AVG(campo)
COUNT(*) FROM <table> INTO (…..,……,…..,….) WHERE ………… .
AVG e SUM: somente para campos numéricos. Não se usa endselect.
Mais rápido fazer uma rotina “à mão” que utilizar este comando.
5- Open SQL
17 - SELECT * FROM (<table>) INTO <work area>. Exemplo: data: begin of WA,
line(100), end of WA.
Parameters: tabname(10) default ‘SPFLI’. *** especificando o nome da tabela em tempo dinamicamente no select statement sempre consome mais tempo de CPU que especificando estaticamente no programa ***
Select * from (tabname) into WA Write ….
Endselect.
18-SELECT * FROM <table> FOR ALL ENTRIES IN <internal table> WHERE campo1 = <conteúdo> and
campo2 = <conteúdo>
Defino uma tabela interna. Alimento os campos desta tabela interna. (move e append).
No meu select campo1 e campo2 serão os campos definidos e alimentados na tabela interna.
19 - SELECT carrid MIN( price ) max (price ) INTO (carrid, minimum, maximum) FROM sflight GROUP BY carrid.
(Todos os campos que eu quero que apareçam na minha lista eu preciso especificar após a cláusula GROUP BY)
(carrid, maximum e minimum são campos auxiliares).
(Se o nome do database não é conhecido até runtime não se pode especificar a cláusula GROUP BY).
5- Open SQL EXEMPLO 6
REPORT ZEXP0006 message-id za. PARAMETER: P_PAIS LIKE T005S-LAND1. TABLES T005H.
SELECT * FROM T005H WHERE LAND1 = P_PAIS ORDER BY CITYC. WRITE: / T005H-Bezei, T005H-LAND1. ENDSELECT. IF SY-SUBRC NE 0. MESSAGE I000. ENDIF.
5- Open SQL EXEMPLO 8
REPORT ZEXP0008 MESSAGE-ID ZA. TABLES: BKPF.
PARAMETER: P_BELNR LIKE BKPF-BELNR DEFAULT '5000000041', P_ANO LIKE BKPF-GJAHR DEFAULT ' 2001'. DATA: ARQ LIKE RLGRAP-FILENAME VALUE 'C:\TEMP\curso.txt'. DATA: BEGIN OF T_ZCURSO OCCURS 0,
ZDATA LIKE BKPF-BUDAT, SPACE1 TYPE C VALUE ' ', ZBELNR LIKE BKPF-BELNR, SPACE2 TYPE C VALUE ' ', ZGJAHR LIKE BKPF-GJAHR. DATA: END OF T_ZCURSO.
SELECT * FROM BKPF WHERE BELNR = P_BELNR AND GJAHR = P_ANO. T_ZCURSO-ZDATA = BKPF-BUDAT. T_ZCURSO-ZBELNR = BKPF-BELNR. T_ZCURSO-ZGJAHR = BKPF-GJAHR. APPEND T_ZCURSO. ENDSELECT. IF SY-SUBRC = 0.
CALL FUNCTION 'WS_DOWNLOAD' EXPORTING * bin_filesize = ' ' * codepage = ' ' FILENAME = ARQ * filetype = ' ' * mode = ' ' * wk1_n_format = ' ' * WK1_N_SIZE = ' ' * WK1_T_FORMAT = ' ' * WK1_T_SIZE = ' ' * col_select = ' ' * col_selectmask = ' ' * importing * filelength = TABLES DATA_TAB = T_ZCURSO * fieldnames = EXCEPTIONS FILE_OPEN_ERROR = 1 FILE_WRITE_ERROR = 2 INVALID_FILESIZE = 3 INVALID_TABLE_WIDTH = 4 INVALID_TYPE = 5 NO_BATCH = 6 UNKNOWN_ERROR = 7 OTHERS = 8. MESSAGE E007. ELSE. MESSAGE E008. ENDIF
6- Modularização
Todo programa ABAP é estruturado e desenvolvido para ser processado em bloco:
• Blocos de processamentos que são chamados pelo sistema: o Blocos de Eventos
o Módulos de Diálogo
• Blocos de processamentos que são chamados pelo programa. o Sub-rotinas
o Módulos de função o Métodos
INCLUDE
Programa do tipo include, pode se modularizar um programa utilizando códigos fontes não executáveis chamados includes e chama-se esses códigos de dentro do programa principal. É comumente usado para declarações de variáveis em programas muito extensos.
6- Modularização Processamento de Mensagens
MESSAGE <tipo>+<numero>+(<classe mensagens>) Exemlo: MESSAGE I368(00) with ‘Erro XXXXX’.
Tipos de Mensagem
Sub-rotina - FORM
Para estruturar nossos programas, utilizamos os blocos de processamentos controlados pelo nosso pr[oprio programa os FORMs, delimitamos as rotinas de processamentos em pequenos grupos, o que facilita a manutenção de nosso código. Podemos passar e receber valores para essas rotinas, tanto por parâmetro como por valor.
START...
PERFORM TESTE123. END....
FORM TESTE123.
<código fonte com a rotina desejada> ENDFORM.
6- Modularização Módulos de Funções
São rotinas de processamento externas e independentes de programa, ficam amarradas a um grupo de funções e tem o seu código desenvolvidos em includes,podem ser chamadas por <n> programas diferentes, também trabalham com passagem de parâmetros e de tabelas, e com exceções (erros no processamento). Praticamente pouco se cria em matéria de funções, o que mais fazemos é utilizar as funções prontas disponibilizadas pela SAP.
Sempre que chamamos uma função, é aconselhável utilizar os modelos do editor ABAP, e também tomar cuidado com os tipos dos parâmetros que estamos passando, pois, se passamos um campo com tipo diferente pode dar um short dump, para evitar isso entrar dentro da função, consultar o tipo do parâmetro e criar igual.
6- Modularização Blocos de Eventos.
Os blocos de eventos são controlados pelo sistema e só valem para programas do tipo executável. Abaixo vemos os principais:
REPORT...
INICIALIZATION.
Primeiro passo a ser executado no programa, antes da tela de seleção e antes da lógica de processamento.
AT SELECTION-SCREEN.
Executa logo após sair da tela de seleção, utilizado para fazer tratamentos de obrigatoriedade de campos e similares.
TOP-OF-PAGE.
Executa quando é encontrado o primeiro comando WRITE dentro da lógica principal, utilizado para colocar cabeçalho, textos que devem sair em todas as páginas.
END-OF-PAGE.
Informações que apareçam no rodapé do relatório
OBS: essas informações só aparecerão se o tamanho da página estiver definido no comando REPORT e somente qdo houver quebra de página. Caso contrário, não aparecerá
START-OF-SELECTION.
Entre o START-OF-SELECTION e o END-OF-SELECTION, se encontra a lógica principal do programa, quando programamos de uma forma estruturada colocamos aqui apenas chamadas de sub-rotinas, para evitar poluição de código.
Ex: PERFORM seleciona_dados. PERFORM tratamento_interno. PERFORM impressao_dados. PERFORM gera_arquivos. END-OF-SELECTION. AT LINE-SELECTION.
Somente é executado se o usuário der um duplo click em uma linha mostrada no relatório, ou marcar a linha e pedir para ver detalhe, utilizada para listas interativas, drill-down.
AT USER-COMMAND.
Somente é executado se o usuário der um click em algum objeto do menu, utilizado para listas com botões de interação.
6- Modularização Processo Geral de Programação
Nome e Descrição do Programa Declaração de Variáveis Montagem da Tela de Input Montagem e Impressão do Relatório ou outra lógica
7- Report/Listas Criação de Listas Básicas
Criando uma lista simples
A sintaxe básica do comando é a seguinte:
WRITE [:] [/] [<campo>|<literal>] [, <campo>|<literal>] [, ...] [opções]. A sintaxe completa do comando pode ser encontrada no Help do R/3. Existem opções para alterar a cor dos elementos da tela, criação de molduras e inserção de ícones na lista. Observe o código a seguir:
REPORT ZSELECT00 . TABLES: SPFLI, SFLIGHT. SELECT * FROM SPFLI.
WRITE: / SPFLI-CARRID, SPFLI-CONNID, SPFLI-CITYFROM, SPFLI-AIRPFROM, SPFLI-CITYTO, SPFLI-AIRPTO. ENDSELECT.
7- Report/Listas
Com esse trecho de código apenas, o R/3 gera uma lista simples do conteúdo de alguns campos da tabela SPFLI:
Cabeçalhos e rodapés
Existem alguns comandos e opções que permitem melhorar o aspecto e a funcionalidade de uma lista. No exemplo, a lista ainda não tem cabeçalho. Para criá-los, pode-se editar diretamente o cabeçalho usando a opção Saltar Elementos de Texto Títulos de Lista. Nesse caso, deve-se saber previamente em que posição deve ficar o texto no cabeçalho. Por outro lado, utilizando-se a opção Sistema Lista Título da Lista é possível editar o título no momento da exibição da lista, facilitando muito o posicionamento dos textos. Também é possível suprimir a geração do título básico, substituindo-o por um título composto pelo programa ABAP. Para tanto, deve-se colocar na declaração REPORT do início do programa a opção NO STANDARD PAGE HEADING e implementar no programa o evento TOP-OF-PAGE. Caso também queira um rodapé para cada página, use o evento END-OF-PAGE para escrevê-lo.
7- Report/Listas Mudando a apresentação dos campos
Para melhorar a apresentação da lista, podemos modificar a forma como os campos são exibidos. Por exemplo, podemos mudar a cor com a opção COLOR do comando WRITE; podemos mudar a intensidade da cor com a opção INTENSIFIED {ON|OFF}, transformar o campo num HOTSPOT para uso em listas com drill-down, e mudar o posicionamento dos campos com WRITE AT. A opção COLOR admite qualquer uma das cores padrão do R/3, disponíveis na transação LIBS:
Por exemplo, para modificar um campo de forma a usar a cor COL_KEY menos intensa, como hotspot, centralizado, escreveríamos o código como segue:
WRITE: / SPFLI-CARRID COLOR COL_KEY INTENSIFIED OFF HOTSPOT CENTERED. A opção HOTSPOT faz com que, ao se apontar o campo com o cursor, o mesmo fique no formato de uma “mãozinha”, como num hyperlink da Internet, permitindo a seleção do registro com um único clique do mouse. Essa característica é muito útil no processamento de listas em vários níveis.
7- Report/Listas Modificando o formato de exibição standard
As opções dentro do comando WRITE têm efeito apenas no campo a que se referem. Caso se necessite mudar todos os campos a partir de um determinado ponto do programa, pode-se usar o comando FORMAT, com as mesmas opções de formatação vistas para o comando WRITE. Com isso, todos os campos a seguir serão exibidos com as opções especificadas pelo comando FORMAT, até que seja encontrado um novo comando FORMAT. Pode-se continuar usando os modificadores no WRITE, mas os mesmos irão basear-se no novo padrão estabelecido no comando WRITE. Por exemplo, caso seja colocado o comando.
FORMAT COLOR COL_KEY INTENSIFIED ON CENTERED
todos os campos a seguir passarão a ser exibidos na cor COL_KEY INTENSIFIED, e serão apresentados centralizados. Caso tenhamos em seguida o comando
WRITE: / SPFLI-CARRID INTENSIFIED OFF, SPFLI-CONNID.
a cor exibida para o campo SPFLI-CARRID será COL_KEY INTENSIFIED OFF, e não a cor padrão sem INTENSIFIED. O campo SPFLI-CONNID aparecerá da forma estipulada no comando FORMAT.
O formato pode retornar ao formato standard usando o comando FORMAT RESET.
Posicionando os campos
Pode-se alterar o posicionamento dos campos dentro de uma linha colocando o número da coluna na qual queremos que o campo comece na frente do campo. Pode-se também especificar a largura do campo colocando a mesma em seguida, entre parênteses (sem essa opção, o tamanho do campo utilizado será o tamanho dele no dicionário de dados). Por exemplo, para posicionarmos o mesmo campo que modificamos anteriormente na décima coluna, estabelecendo um tamanho de cinco caracteres, usamos o comando.
7- Report/Listas Especificando unidades de medida e moedas
Para formatar automaticamente na lista campos numa determinada unidade de medida e valores monetários, pode-se utilizar as opções UNIT e CURRENCY, seguidas do campo que contém a chave da unidade, após o campo que se quer formatar. Com isso, o campo será formatado de acordo com a definição nas tabelas standard de unidades e de moedas do R/3. Veja o exemplo a seguir:
WRITE: /20(6) SFLIGHT-FLDATE,
SFLIGHT-CURRENCY,
'Sem CURRENCY:', (12) SFLIGHT-PAYMENTSUM, 'Com CURRENCY:', (12) SFLIGHT-PAYMENTSUM
CURRENCY SFLIGHT-CURRENCY.
Um trecho do report seria:
150420 ITL Sem CURRENCY: 683.231,44 Com CURRENCY: 68.323.144 130520 ITL Sem CURRENCY: 318.202,60 Com CURRENCY: 31.820.260
Sem o uso da opção CURRENCY, o valor é apresentado no formato genérico do usuário; com o CURRENCY, mesmo caso tenhamos moedas diferentes em cada registro, cada uma será exibida no formato correto.
Símbolos de Texto
O ABAP permite a criação de símbolos de texto, que são elementos do repositório que permitem a criação de tabelas de texto para uso nos programas ABAP. Os símbolos de texto são criados dentro de classes de mensagem, que servem para separar logicamente os símbolos de texto relacionados. Dentro da classe de mensagem, cada texto deve ser identificado por um número de três posições. Cada símbolo de texto pode ser criado em várias linguagens.
Suponha que exista o seguinte trecho de código: WRITE: /10 'Assentos ocupados:', SFLIGHT-SEATSOCC. Utilizando símbolos de texto, o comando ficaria WRITE: /10 TEXT-001(ZCLMENS), SFLIGHT-SEATSOCC.
Toda vez que o interpretador ABAP encontra um campo que começa com TEXT, coloca naquela posição um símbolo de texto correspondente ao número após o hífen na classe entre parênteses. Caso seja usada a opção MESSAGE-ID <classe> na declaração REPORT, não é necessário especificar a classe de mensagem junto ao símbolo de texto. O uso de símbolos de texto pode simplificar a manutenção de programas complexos ao agrupar todas as mensagens de texto em um só local.
Para editar os símbolos de texto, use, na janela do editor ABAP, a opção Saltar Elementos de Texto Símbolos de Texto.
