Academia ABAP – 2006 – PROCWORK Software.
Material de apoio – Conceitos resumidos - Instrutor: Luís Fernando Aguiar da Rocha.
ÍNDICE:
INTRODUÇÃO:... 3
SOBREESSAAPOSTILA:... 6
DIAMANTE:... 6
R3COMOUMSISTEMAABERTOÀCOMUNICAÇÃO:... 6
ARQUITETURA:... 7
OMIDDLEWAREBASIS:... 9
SAPONLINESERVICESYSTEM:... 10
CONCEITODEMANDANTE:... 10
CHANGEREQUEST:... 11
UNIDADESLÓGICASCOMSEUSMANDANTES->DESENHO.... 12
OBJETOS‘Z’E‘Y’:... 13
CLASSEDEDESENVOLVIMENTOOUPACOTE:... 13
PROGRAMASSTANDARDDOSAP:... 13
FIELDEXITS... 13
SCREENEXIT... 17
USER-EXIT... 17
TRANSAÇÕESIMPORTANTESAODESENVOLVIMENTO:... 18
ENTRADASPOSSÍVEISNOCAMPODECOMANDO:... 18
TELASDESELEÇÃO:... 19
PARAMETER:... 20
DECLARAÇÃODEVARIÁVEIS:... 22
CATEGORIA SIGNIFICADO ADEQUADO PARA... 23
MENSAGENS:... 24 TRANSAÇÃO:... 25 DEBUGGER:... 26 TIPOSDETABELAS:... 27 DICIONÁRIO(DDIC).... 28 ATUALIZADORDETABELA.... 30 TABELAINTERNA.... 32 HEADERLINE... 32 MODULARIZAÇÃO:... 36 COMANDOWRITE:... 37 TABELASYST:... 37
COMMITWORK/ROOLBACKWORK:... 38
LOOP–ENDLOOP:... 40
IF,ELSE,ENDIF:... 41
CASE:... 42
INSERT.... 42
SORT.... 43
DELETE.... 44 CLEAR:... 44 INCLUDE:... 45 UPDATE:... 47 CONCATENATE:... 47 WS_UPLOAD E WS_DOWNLOAD:... 48 WORKÁREA:... 49 SELECT:... 50
SELECT<RESULT>FROM<TABLES>INTO<TARGET>WHERE<CONDITION>.... 50
SELECTSINGLE– LEITURA DE UM ÚNICO REGISTRO.... 50
SELECT....ENDSELECT– LEITURA DE MÚLTIPLAS LINHAS;... 50
SELECT....FROM...INTO....FORALLENTRIESIN<ITAB>...WHERE....<F1>EQ<ITAB >-<FX>.... 51
SELECT...UP TO <N>ROWS... 51
SELECT<T1>~<F1><T2>~<F1>FROM<T1>INNERJOIN<T2>ON<T1>~<F3>EQ <T2>~<FX>INTO...WHERE...... 51 SUBMIT:... 53 EXPORTIMPORT:... 53 READTABLE:... 54 MODULEPOOL:... 55 CALLSCREEN:... 56 LEAVE:... 56 TABLECONTROL:... 57 COLUNADEMARCAÇÃO:... 58
CRIAÇÃODEBOTÔESEMTELA:... 59
TABSTRIP:... 59
CARGASEMBANCODEDADOS:... 62
1-DIRECT INPUT... 62
2-BATCH INPUT... 62
3–CALL TRANSACTION... 63
4–BAPI... 65
INTRODUÇÃO:
O que é SAP ???
Os passos iniciais para que o SAP viesse ao mundo começaram a ser dados em 1972, na cidade de Waldorf, na Alemanha, quando cinco engenheiros, funcionários de uma multinacional , decidiram criar sua própria empresa de desenvolvimento de sistemas: a SAP AG. Isso mesmo, SAP não é apenas o nome do pacote de gestão mais falado no mundo, é também o nome da empresa que o desenvolveu.
O nome da empresa era na verdade uma acrossemia (nome formado pelas iniciais de uma série de palavras). As iniciais SAP significam Systeme, Anwendung und Programme (Sistemas, Aplicações e Produtos). O AG era a abreviação de Agentur, um termo em alemão que quer dizer Sociedade Anônima.
O primeiro produto importante da nova empresa foi o SAP R/2 (Realtime System Version 2), um conjunto de módulos de software destinado a mainframes, que em 1995 ainda era utilizado por mais de 2000 empresas.
A medida que novos conceitos iam surgindo no campo da informática, a SAP ia atualizando seu produto, até que em 1989, as primeiras aplicações do SAP R/3 foram apresentadas numa conferência em Hanover, Alemanha.
R/2 e R/3 não representam versões de um mesmo sistema, tratam-se na verdade de produtos diferentes. O R/2 era um conjunto de módulos de software destinado a mainframes, enquanto o R/3 foi desenvolvido para o ambiente cliente/servidor (ambiente em que algumas estações solicitam serviços, os clientes, e outras, os servidores, atendem, realizando determinados tipos de processamento ou compartilhando recursos como impressoras, arquivos e bancos de dados).
Os Principais Módulos do SAP R/3 (Copyright by SAP AG).
O SAP R/3 é um sistema que oferece um conjunto de módulos com diversas aplicações de negócio. Os módulos são integrados e contém a maior parte das funcionalidades necessárias às grandes corporações , incluindo manufatura, finanças, vendas e distribuição e recursos humanos. Cada módulo é responsável por mais de 1000 processos de negócio, cada um deles baseado em práticas consagradas no mundo dos negócios. A configurabilidade do sistema é tornada possível por 8000 tabelas que administram desde a estrutura corporativa até a política de desconto
oferecida aos clientes. O sistema oferece o processamento de informações em verdadeiro tempo real ao longo da empresa onde estiver implementado. Não é a toa que o sistema é um best-seller. como provam os números a seguir. Em 1995, a SAP AG tinha mais de 6600 colaboradores ao redor do mundo. Neste mesmo ano, a SAP liderava o mercado de softwares para ambiente cliente/servidor. Além disso a SAP ocupava a quinta posição no ranking das empresas de software. Hoje mais de 4000 empresas possuem o produto da SAP implementado. Um dos motivos do sucesso da SAP é o montante investido em pesquisa e desenvolvimento e as alianças estratégicas que forma com outros desenvolvedores de sistemas. Estes parceiros criam add-ons (programas complementares) que suprem algumas deficiências do R/3. Este tipo de união permite que a SAP foque seus esforços no seu principal produto.
Em 1995 o SAP chegou ao Brasil, mas para que pudesse ser utilizado no nosso pais ele passou por um processo chamado de customização, que nada mais é que a alteração do sistema de modo a atender a legislação fiscal brasileira .
Quando o SAP chegou ao Brasil com força total em 1991 as empresas de consultoria já sabiam que esta ferramenta seria um ótimo instrumento para aumentar suas receitas. Sendo assim, um ano antes elas começaram a montar a infraestrutura necessária para implementar o pacote no Brasil. Gerentes mais experientes eram enviados ao exterior para saber como os departamentos dedicados a implementação do SAP eram estruturados fora do país. Outro objetivo destas viagens era conhecer a metodologia de implementação e as ferramentas utilizadas em locais onde a experiência com o sistema fosse maior. Além disso os escolhidos para estas tarefas passavam por cursos onde eram introduzidos ao pacote de gestão que estava para invadir o mundo corporativo brasileiro.
Mas os preparativos para a chegada do SAP ao Brasil não envolviam apenas os gerentes das chamadas "Big Six", havia um enorme trabalho de bastidores, deixado a cargo dos sócios destas empresas. O resultado seria a formação de um sistema de parceria entre a SAP e as empresas de consultoria segundo o qual o foco da SAP seria a venda do sistema, deixando a implementação na mão de seus parceiros.
Com as práticas de SAP devidamente estruturadas, do ponto de vista organizacional , restava apenas uma questão: quem iria por a mão na massa e implementar realmente o sistema nos clientes, uma vez que a princípio apenas uns poucos gerentes haviam tido treinamento formal nos assuntos relativos ao SAP e como todos sabemos nunca foi atribuição de um gerente sentar na frente de uma de micro-computador e configurar um pacote de gestão, tendo em mente que seu papel em projetos é muito mais estratégico do que prático.
A resposta a esta questão era relativamente simples: as grandes consultorias possuiam um contingente de especialistas em outros pacotes de gestão como por exemplo MMX (Suprimentos e Manufatura) ou Interquadram (Financeiro). Estes consultores podiam não conhecer muito de SAP, mas dominavam a metodologia de implementação de sistemas e conheciam processos de negócio a fundo.
Estas pessoas foram então enviadas para os Estados Unidos, para tomar parte na tão falada academia de SAP. O que era a Academia de SAP ? Era um curso de 5 semanas onde os profissionais aprendiam como configurar o sistema e como executar uma série de transações. Os especialistas em Interquadram faziam, em sua maioria, o curso do módulo FI/CO. Os entendidos em MMX faziam academia de MM ou PP. Ao fim das cinco semanas de curso os participantes deviam fazer um estudo de caso e uma prova. Para receber o certificado de implementador, o aluno deveria ter aproveitamento de 70%. Ao voltar da academia os profissionais eram imediatamente alocados em projetos.
Para enfrentar os problemas mais complexos de configuração as consultorias traziam especialistas estrangeiros. Às vezes muitos brasileiros que trabalhavam no exterior com SAP há algum tempo eram contratados a peso de ouro pelas grandes empresas.
Como a demanda por especialistas era maior que a oferta, as consultorias iniciaram grandes processos de contratação. Avalanches de curriculum chegavam aos escritórios. Entre os remetentes havia até mesmo enfermeiros . Os envelopes eram distribuídos em 4 pilhas:
- Pessoas com experiência em SAP,
- Pessoas com experiência em implementação de pacotes, - Pessoas com conhecimento de Inglês e
- Demais
As consultorias realmente não exigiam experiência com SAP, pois o processo de formação dos contratados seria financiado por elas mesmas. Cabe ressaltar que apenas empregados de empresas de consultoria podiam tomar parte na academia. Em resumo os participantes eram escritos no curso por seus empregadores.
Ao término da academia os formandos eram disputados imediatamente por todas as consultorias num processo não muito ético. Para moralizar a situação as consultorias fizeram um acordo de cavalheiros segundo o qual elas não poderiam roubar profissionais umas das outras.
E assim o mercado do SAP foi crescendo. À medida que mais e mais empresas utilizavam o sistema, eram formados mais profissionais de implementação de SAP. Muitos funcionários de empresas que passaram por implementações acabaram indo para o mercado de consultoria.
SOBRE ESSA APOSTILA:
Essa é uma apostila não oficial da SAP do módulo de ABAP 4 (linguagem de programação do SAP/R3) que se destina a pessoas com experiência em programação linear, análise estruturada e estrutura de dados.
O objetivo dessa apostila é mostrar de forma simples alguns do vários comandos, sintaxes e técnica de programação utilizando ABAP 4. Vale ressaltar que o material foi feito utilizando a língua portuguesa e não apresenta todo o conteúdo de sintaxes e técnicas de programação, se tornando assim apenas referência para o auto-estudo e gestão de uma academia ABAP 4.
A utilização das apostilas oficiais da SAP se torna, como sempre foi, material fundamental para o estudo e aprendizagem da linguagem bem como para a prova de certificação da SAP.
DIAMANTE:
SAP/R3 é um sistema que pode agregar diversos módulos que por sua vez possuem diversas funcionalidades, todas integradas seguindo o conceito de tabelas relacionais.
O R/3 segue o princípio administrativo conhecido como DIAMANTE onde diversos módulos separados entre si podem ser acoplados dentro de um mesmo conceito definido por sistema, onde todos esses módulos podem enxergar e conversar entre si, garantindo integridade e integração entre todos os módulos.
R3 COMO UM SISTEMA ABERTO À COMUNICAÇÃO:
O R/3 utiliza protocolos Standard da indústria para garantir integração com outras aplicações:
• TCP/IP: é o protocolo de comunicação difundido mundialmenmte.
• EDI: Eletronic Data Interchange , é o mecanismo utilizado para trocar informações de negócio com diferentes sistemas; muito utilizados por bancos.
• OLE: Object Linking and Embendding: integra aplicações PC com o R/3 (padrão Microsoft).
• Open Interfaces: Arquivamento ótico, dispositivo de código de barras, etc.
Além dos protocolos Standard da indústria o R/3 também utiliza:
• RFC: Remote Function Call, que utiliza o protocolo copiado do CPI-C da IBM para comunicação e processamento das aplicações e tasks dentro do sistema R/3 ou com o sistema R/2 ou outros sistemas.
• ALE: Application Link Enabling permite o processamento distribuído dentro do R/3. Na prática está associado a distribuição de informações a partir de um modelo de divulgação pré-estabelecido.
ARQUITETURA:
O R/3 possui uma arquitetura modular de software seguindo o princípio da arquitetura
cliente/servidor com enfoque na distribuição da força de processamento entre as várias pataformas envolvidas.
Esta arquitetura permite que se separe a lógica da aplicação da base de dados e da camada de apresentação. Esta configuração permite ainda otimizar os custos e distribuir a carga através de configurações variadas de hardware. Com isto é possível dimensionar os servidores de acordo com a carga, permitindo a fácil escalabilidade do ambiente.
Os ganhos nesta arquitetura na implementação R/3 são muitos:
• Simples instalação de novos servidores para eliminar eventuais gargalos de processamento;
• Servidores trabalham em paralelo, com carga homogênea e execução local dos programas;
• Baixo tráfego de rede com a localização dos buffers de dados e programas;
• Balanceamento de carga, seja para o processamento online (logon) seja para o processamento batch.
Ou seja, o ponto alto da arquitetura é a facilidade para escalar e aumentar o poder de
processamento.
Princípios cliente/servidor
Na implementação R/3, a arquitetura client/server é orientada para o software, e não para o
hardware como estamos acostumados a ver. Desta forma, Client é quem requisita e utiliza o serviço.
Um servidor de aplicação por exemplo é server de alguns serviços das estações clients, porém é client dos serviços fornecidos pelo servidor de banco de dados. Ou seja, o conceito do papel de quem é o cliente e de quem é o servidor é o que prevalece não importando quem tem mais hardware ou quem normalmente executa a atividade.
R/3 System Client/Server Configurations
Os serviços (ou camadas) fundamentais de uma aplicação são três: Presentation, Application e Database services e existem várias formas de se implementar um sistema R/3, a saber :
Central, onde todos os componentes estão implementados em um mesmo
host. Esta implementação corresponde a clássica implementação mainframe e não é comum de ser implementada;
Two-tier, onde uma camada normalmente executa as funções de
presentation usualmente um PC) e a outra camada executa os serviços de application e database. Uma outra implementação two-tier poderia ser uma camada executando os serviços de database e a outra composta por PCs mais potentes que executariam as funções de presentation e application. A primeira implementação é comum em ambientes pequenos e com pouca disponibilidade de hardware para os servidores. A última implementação é normalmente utilizada em simulações ou desenvolvimento de software.
Three-tier, onde cada serviço tem o seu próprio host. Nesta configuração é
possível ainda assegurar uma divisão de carga na camada de aplicação, garantindo que determinados hosts fiquem dedicados para aplicações específicas. Por exemplo dedicar um host para servidor de aplicação dos usuários de MM, ganhando com isto performance na distribuição dos serviços. A configuração three-tier é a mais recomendada em R/3 por garantir a melhor distribuição de carga e escalabilidade nos grandes sistemas.
Um sistema R/3 agrupa todos os componentes que estão associados com um banco de dados. Se utilizamos uma implementação em 3 camadas, os componentes do R/3 estarão presentes em todas as camadas da hierarquia:
Database Server, é instalado em um host central, onde todos os serviços de
Um ou mais Application Servers conectados ao servidos de banco de dados. Nestes servidores estarão sendo processados a lógica da aplicação, ou seja, os programas.
Vários Presentation Servers conectados aos servidores de aplicação. Estas máquinas são também chamadas de frontends ou workstations. Nestas máquinas os usuários irão interagir com o sistema R/3 utilizando uma interface que proverá os serviços de presentation.
O MIDDLEWARE BASIS:
O software Basis do R/3 (também chamado de middleware) roda em diferentes plataformas e também pode ser adaptado para atender as necessidades individuais das empresas. São vários os papel de BASIS:
· Provê o ambiente de runtime para as aplicações R/3 · Cuida da perfeita interação das aplicações com o sistema · Define uma arquitetura estável para as melhorias do sistema
· Contém todas as ferramentas necessárias para a administração do ambiente
· Permite a distribuição eqüitativa dos recursos e componentes do sistema · Provê as interfaces necessárias para os sistemas descentralizados e os produtos externos ao R/3
As principais características da tecnologia Basis são:
· É uma arquitetura voltada para a configuração client/server · Trabalha com bancos de dados relacionais
· Possui interface gráfica com o usuário (GUI)
Basis é o responsável ainda pela integração dos aplicativos e do ABAP workbench com o software
O profissional BASIS é em geral o ‘gerente’ do sistema, sendo responsável ainda pelo transporte de requests, controle das rotinas de backup, coordenação da manutenção do sistema (como aplicação de notas e hot packages).
SAP ON LINE SERVICE SYSTEM:
OSS é um service 24 x 7 disponibilizado pela SAP que permite acesso ao banco de dados de Notas, que provêm soluções para problemas no sistema R/3. Através do OSS os clientes abrem chamados ao suporte relatando problemas que são analisados pela equipe da SAP.
Atualmente a SAP já disponibiliza esse serviço pela Internet. O OSS está disponibilizado no site http://service.sap.comque faz parte do chamado market place da SAP.
Como a grande maioria (quase totalidade) dos grandes sistemas o SAP/R3 também é passível de erros. Erros esses que podem e devem ser corrigidos com a aplicação de notas.
Notas são comunicados/documentos emitidos pela SAP que relatam e tentam corrigir erros em programas dos diversos módulos do SAP.
Através do portal SAPnet na WEB podemos procurar uma nota que pode ser aplicada ao erro encontrado. Não existindo uma nota específica para o problema devemos abrir uma OSS que é uma comunicação à SAP de um possível problema no R3. Essa OSS então é analisada pelos profissionais da SAP que nos informam qual o possível problema, qual a solução e se realmente não existir uma nota específica a SAP trata de providenciar uma (cria uma nova nota e a divulga).
CONCEITO DE MANDANTE:
O R/3 é um sistema voltado para clients. Com este conceito é possível controlar várias empresas em um único sistema, separando-os por client (ou mandante). As chaves para se logar no sistema também são separadas por client. Para efetuar um logon é preciso ter chave no client específico. Além disso o sistema exige um password e por ser multilingüe , deve-se ainda especificar a língua desejada no momento do logon.
Um client pode ser visto como uma entidade organizacional separada dentro do R/3, com seus próprios dados e parâmetros específicos de customização. Apesar dos dados serem armazenados em tabelas únicas, os dados dos diferentes clients coexistem separados pela diferenciação do campo MANDT que faz parte da chave da maioria das tabelas (client dependents). A única exceção é a tabela T000 (definição dos clients do sistema) que é independent apesar de ter como primeiro o campo MANDT.
Mandantes são como unidades independentes dentro de uma mesma unidade lógica.
Geralmente temos a seguinte configuração de mandantes: Ambientes de desenvolvimento e parametrizações funcionais em uma unidade lógica, ambiente de qualidade e testes em outra unidade lógica e o ambiente de produção em outra unidade lógica (esse representado por um mandante apenas).
CHANGE REQUEST:
As alterações no software R/3 podem ser divididas em cinco categorias: · Customizing: é a configuração dos processos de negócio e funções de menu através do IMG
· Personalization: são as mudanças globais das características das telas e definição de valores default para determinados campos (SM3)
· Modification: são mudanças efetuadas pelo cliente no repositório de
objetos do R/3 (os SAP objects). estas alterações precisam ser cuidadosamente
avaliadas quando do upgrade de versões do sistema. A partir do release 4.5A a SAP introduziu o Modification Assistent para auxiliar a gerenciar e automatizar estas mudanças
· Enhancement: criação pelo cliente de objetos no repositório que são referenciados pelos objetos standard do R/3 através de user exits. Estes desenvolvimentos são os ideais por reduzirem as necessidades de modification adjustments durante o processo de upgrade · Customer Development: criação pelo cliente de objetos no repositório através do ABAP Workbench (programas, etc.)
Uma change request é um “pacote” contendo os objetos que serão transportados de um sistema R/3 para outro. Por exemplo, no caso de um abap será encapsulado o source, no caso de uma configuração será encapsulado as entradas nas tabela e sua respectiva ação (cria/deleta/altera). Uma change request pode ser atribuida a vários usuários através do conceito de tarefa. Apesar do nome tarefa ela não representa o que vai ser feito, ela representa a associação da change request com o usuário e a respectiva documentação (que não é obrigatoria) do que foi feito.
Todas as alterações efetuadas nos objetos do repositório são criadas e mantidas através do ABAP Workbench e gravadas em change requests. As demais alterações de customizing e personalizations são criadas e mantidas pelas ferramentas de business engineer e também gravadas em change requests. Estes
mecanismos permitem que estas alterações sejam posteriormente propagadas pelo landscape para consistência do ambiente.
O workbench organizer oferece mecanismos que permite que os change requests sejam documentados através de uma descrição do seu propósito. Os change requests devem ser criados por gerentes de projeto que associam os
objetos do repositório que serão trabalhados, onde permanecem lockados com
acesso permitido apenas aos desenvolvedores que foram autorizados ao change. As alterações nos objetos do repositório são criadas como tasks associadas ao change request e quando liberadas são transferidas como um todo através das rotas que definem o landscape, já que a unidade de transporte é o change request. A liberação de um change request faz com que uma nova versão dos objetos nele contidos seja gravado no database de versões (somente no sistema R/3 que foi utilizado para o desenvolvimento).
UNIDADES LÓGICAS COM SEUS MANDANTES -> DESENHO.
QUALIDADE PRODUÇÃO
REQUEST REQUEST
OBJETOS ‘Z’ E ‘Y’:
Todos os objetos não Standard do SAP começam com a letra Z ou Y, portanto quando criamos um programa, transação ou tabela dentro do SAP obedecemos essa nomenclatura de criação de nomes.
CLASSE DE DESENVOLVIMENTO OU PACOTE:
CADA MÓDULO POSSUI O SEU.
O conceito de classe de desenvolvimento ou pacote se refere a uma divisão lógica criada por BASIS para instanciar diferentes módulos de aplicação do R/3, proporcionando por exemplo que cada classe de desenvolvimento ou pacote tenha uma rota de transporte específica.
Assim temos diversas classes de desenvolvimento dentro do R/3 que permitem o transporte de change requests entre os diversos mandantes e unidades lógicas. Temos inclusive uma classe de desenvolvimento local, que não gera change requests e portanto não possui uma rota de transporte, sendo muito utilizada para testes locais num determinado ambiente.
PROGRAMAS STANDARD DO SAP:
Não podem ser alterados. Caso haja essa necessidade a SAP disponibiliza EXITS para codificação ABAP. Os programas STANDARD são “fechados”.
O que são exits?
Espaços ou “brechas” em que a SAP permite que coloquemos codificação. Temos então:
FIELD EXITS – Que são exits criadas para determinado campo. Ao
trabalharmos com esses campos o SAP desvia a codificação para um espaço em que podemos acrescentar código ABAP. As field exits são criadas conforme as necessidades encontradas no ambiente de programação/regra de negócio.
A Field exit, permite que seja feita alguma seleção ou checagem de um determinado campo no programa e tela desejados.
Para isso, se faz necessário, buscar o elemento de dados do campo que se deseja fazer a field exit.
Para versões do R/3 até 4.5:
Ir até a transação CMOD, clicar AMPLIAÇÕES TEXTO(menu), depois escolher Exits campo, aparecerão todas as fields existentes.
Para versões do R/3 após 4.5:
Rodar pela transação SE38 o relatório Standard RSMODPRF. Para se criar uma nova:
1) Exit campo (menu ou relatório, dependendo da versão) 2) Criar
3) Digitar o elemento de dados - Avançar 4) Digitar o código, como uma função
5) Depois clicar no botão Atribuir progr/tela, colocando o nome do programa e o número da tela, p/ pegar estas informações, clicar F1 e F9, no campo desejado
6) Visualiza ou modifica o conteúdo da field, no botão Processar MF, deve-se selecionar o elemento de dado desejado
7) Ativar a field exit
IMPORTANTE: Na field exit, você precisa pegar o valor digitado no campo
desejado, para isso existe a importação e a exportação, ou seja, as variáveis INPUT e OUTPUT, você precisa sempre colocar OUTPUT = INPUT, para que o valor possa voltar para tela origem.
Observação: A Field exit só funcionará, se a mesma estiver ativa. Exemplo: Campo AUART na transação VA01
Elemento de dados: AUART Programa: SAPMV45A Tela:0101 Código desenvolvido function field_exit_auart. *"--- *"*"Interface local: *" IMPORTING *" VALUE(INPUT) *" EXPORTING *" VALUE(OUTPUT) *"--- data: w_auart like vbak-auart. w_auart = input.
export w_auart to memory id 'w_auart'. output = input.
endfunction.
Exemplo da tela de ativação de field_exit:
Notar que temos uma listagem com:
• Elemento de dados.
• Status (ativo ou inativo).
• Programa (nome do programa específico ou global)
• Tela (número da tela do programa na qual a exit estará ativa)
• Numeração para quando tivermos a exit ativa para mias de uma tela ou programa.
• Descrição herdada do elemento de dados.
Também é importante destacar que para cada função que for criada para a field exit específica deveremos associar um grupo de funções. A dica é criar um grupo de funções para cada field exit criada.
SCREEN EXIT – São locais em telas de transações Standard do SAP onde
podemos criar campos adicionais ou qualquer outro objeto em tela. As menu exits são pré-definidas em determinadas telas de transações e criadas pela própria SAP como uma maneira de inclusão de funcionalidades.
USER-EXIT – São espaços vazios que algumas transações e seus
programas possuem e são apresentadas como uma Include vazia dentro desses programas onde nos dá a possibilidade de incluir codificação ABAP e alterar com
isso diversos procedimentos de programação executados pela
transação/programa Standard.
As User Exits foram desenvolvidas originalmente para o Módulo SD, com o propósito de permitir ao usuário modificar o sistema sem, no entanto, modificar o código fonte.
Consistem basicamente de sub-rotinas (rotinas FORM) em includes especiais, criados em um Pool de Módulo ou Grupo de Função, onde chamará essas sub-rotinas nos pontos do programa no qual será permitida alteração pelo usuário.
Essas sub-rotinas devem satisfazer a nomenclatura: USEREXIT_<nome>.
A SAP nunca altera os includes.
Se novas User Exits são adicionadas em uma nova versão, elas são colocadas em um novo programa include.
A chamada da sub-rotina já está implementada nos programas dos módulos Standard (SD, MM, FI, etc.).
Normalmente, sub-rotinas desse tipo só trabalham com variáveis globais. Obs: Como exemplo, podemos verificar os includes MV45AFZB e
MV45AFZZ, referente ao programa SAPMV45A.
Para encontrarmos User Exits em um determinado programa, podemos utilizar a transação SE38, em “Utilitários”, na opção “Encontrar na Fonte”, e “userexit_” como texto de procura. O resultado será uma lista de todas as User Exits do programa, e onde elas foram chamadas em todas as telas do Pool de Módulo.
Há ainda a visão de tabelas chamada INFO_MODS nas quais podemos visualizar todas as possibilidades de exits existentes em um programa específico. Deveremos então indicar o nome do programa que queremos buscar por exits no campo MEMBER e o campo TYP significa qual o tipo da exit como abaixo:
TRANSAÇÕES IMPORTANTES AO DESENVOLVIMENTO:
SE38 – EDITOR ABAP
SE80 – OBJECT BROWSER (pode ser usada para chamarmos diversas outras transações).
SE11 – DICIONÁRIO SE16 – DATA BROWSER
SE71 – FORM PAINTER (EDITOR DE SAPSCRIPT) SE10 – TRANSPORT ORGANIZER
SM30 – ATUALIZADOR DE VISÃO DE TABELAS ST22 – ABAP ANÁLISE DE DUMP.
ST05 – TRACE REQUESTS (análise de performance).
ENTRADAS POSSÍVEIS NO CAMPO DE COMANDO:
Chamar uma transação:
- no mesmo modo (janela) Entrar: /nxxxx (xxxx = código de transação).
- no mesmo modo (janela), a primeira tela é ignorada. Entrar: /*xxxx (xxxx = código de transação).
- em um modo adicional Entrar: /oxxxx (xxxx = código de transação).
Entrar: /n.
Atenção: modificações não gravadas são perdidas sem aviso
Eliminar o modo atual:
Entrar: /i.
Gerar uma lista de modos:
Entrar: /o.
Encerrar a transação atual e voltar ao menu inicial :
Entrar: /ns000. Logoff do sistema: Entrar: /nend.
Logoff do sistema sem consulta de segurança: Entrar: /nex.
Atenção: modificações não gravadas são perdidas sem aviso.
TELAS DE SELEÇÃO:
Chama-se telas de seleção as telas especiais usadas para a informação de valores nos programas Abap: em vez de usar o Screen Painter, podem ser criadas por meio de instruções Abap na lógica de processamento do programa. A lógica de fluxo de tela é fornecida pelo sistema e permanece invisível ao usuário como, o programador da aplicação.
Definem-se as telas de seleção na parte da declaração de um programa Abap por meio das instruções de declaração especiais (PARAMETERS, SELECT-OPTIONS e SELECTION-SCREEN). Tais instruções declaram e formatam os campos de entrada de todas as telas de seleção.
Os elementos mais importantes de uma tela de seleção são os campos de entrada para valores individuais e para tabelas de seleção. Estas permitem a entrada de critérios de seleção mais complicados e são fáceis de usar no sistema Abap por serem processadas no próprio sistema. Como acontece no caso de outras telas. O sistema fornece ajuda de campos e os possíveis valores para os campos de entrada que fazem referencia a um campo do Abap Dictionary. O
sistema fornece conjuntos pré-configurados de valores de entrada para telas de seleção denominados variantes. Quando é usada a instrução CALL SELECTION-SCREEN, o sistema permite chamar uma tela de seleção de um programa Abap. Caso se trate de um programa executável (relatório) de categoria 1, um programa do sistema automaticamente chama a tela de seleção definida na parte de declaração do programa. As telas de seleção acionam eventos e podem, assim, chamar blocos de evento em programas Abap.
Posto que as telas de seleção contem principalmente campos de entrada, os diálogos da tela de seleção são mais orientados por entradas do que as telas definidas a partir do Screen Painter. As telas de dialogo podem conter campos de entrada e de saída. As telas de seleção, entretanto, mostram-se apropriadas quando o programa requer dados do usuário antes que possa continuar o processamento.
Por exemplo, a tela de seleção poderia ser usada antes de acessar o banco de dados, para restringir o volume de dados lidos.
PARAMETER: OBLIGATORY DEFAULT AS CHECKBOX RADIOBUTTON GROUP B1 Exercício.
Criar um REPORT utilizando todas as opções acima com PARAMETERS. Combinar com os já apresentados
SELECT-OPTIONS:
A declaração SELECT-OPTIONS <nome> FOR <objeto de dados> insere dois campos de entrada na tela de seleção, com o mesmo tipo definido na referencia. Com isso, os usuários podem entrar um intervalo de valores ou seleções mais complexas
Os diversos valores ou intervalos, entrados para uma opção de seleção, são inseridos na tabela interna quando o usuário selecionar ´Executar´.
Exemplo:
PARAMETERS: P_PEDIDO LIKE EKKO-EBELN. O que resultará na tela:
2 - Para exibirmos em tela um parâmetro composto de entrada de dados (possibilitando a digitação de um RANGE de dados):
SELECT-OPTIONS:
SO_PED FOR EKKO-EBELN. O que resultará na tela:
DECLARAÇÃO DE VARIÁVEIS:
É uma definição de objetos de dados.
A atribuição de categoria de objeto de dados é feita pela referencia do objeto a uma categoria abap, a uma categoria definida pelo usuário ou a um objeto do dictionary.
Sintaxe:
TYPE <ABAP-data-type> .
DATA: < varname> TYPE <user-definied.type>. LIKE <ABAP-dictionary-object>.
O sistema permite também referir o objeto a um outro objeto de dados existentes. Neste caso todos os atributos da categoria são herdados pelo novo objeto de dados.
Exemplo:
DATA: <varname> LIKE <data-object>.
- Categoria de dados 2 tipos: Predefinidos
Definidos pelo usuário - Predefinidos
No Abap existem 8 categorias de dados predefinidos:
• Numéricos:
Categoria Significado Adequado para
P numero compactado contadores, quantidade, índices, prazos
I numero inteiro moedas, comprimentos, pesos
F numero ponto flutuante calculo em um intervalo de valor muito grande. • Alfanuméricos: Categoria Significado N texto numérico C texto (caracter) D data T horário (time) X hexadecimal
Exemplo:
DATA: <varname> TYPE <ABAP-data-type>.
DATA: counter TYPE I,
name(18) TYPE C,
start_date TYPE D,
sum(3) TYPE P DECIMALS 2.
Numero de posições
Determina o numero de casa decimais a ser usado
• Regras para dar nome aos objetos de dados:
- Um nome pode Ter 30 caracteres no máximo.
- Os seguintes símbolos NÃO são permitidos: ( ) + . , : - SPACE é um campo obrigatório.
MENSAGENS:
É uma caixa de texto configurada para ser exibida ao usuário quando um determinado evento é disparado.
Todas as messages deverão ser executadas com textos padrões ou personalizados.
Exemplos:
- Texto padrão:
MESSAGE I027 (BCTRAIN).
- Texto personalizado:
MESSAGE W001(PC) WITH ‘Cuidado, operação pode gerar danos ao sistema!’. Chamada da message Tipo de message utilizada Nº da message na biblioteca Texto utilizado de uma biblioteca padrão
Tipos de mensagens: A – Abend W - Warning I - Information S – Status E – Erro.
X – Exit (termina com short dump).
Exercício.
01 – Criar um report em que os parameters de entrada sejam exibidos em mensagens (testar todos os tipos).
TRANSAÇÃO:
Conceito: Um processo lógico no sistema R/3.
Do ponto de vista do usuário, uma transação é uma unidade lógica (por exemplo, gerar uma lista de clientes, criar uma reserva para um vôo ou executar um programa).
Do ponto de vista do programador é um objeto complexo, que consiste num grupo de módulos e uma série de telas. As transações se iniciam usando um código de transação.
Depois de entrar no sistema R/3 existem 3 níveis: nível SAP, nível Work Área e nível de aplicação. Uma transação é um processo em nível de aplicação.
Para iniciar a transação, o usuário poderá usar os menus ou entrar com 4 caracteres para o código da transação na linha de comando.
Componentes de uma Transação:
• Programa ABAP
• Diálogos do usuário (Telas, listas e telas de seleção)
• GUI – Interface gráfica do usuário (Barra de Menus, Barra de ferramentas Standard e de aplicação e barra de títulos)
Etapas para criar uma nova transação:
Analisar o problema escrevendo uma especificação do programa. É importante também checar se existem soluções similares já existentes;
Baseado nessas análises, escolher os tipos de diálogos do usuário (telas, listas ou telas de seleção). As telas permitem criar diálogos amigáveis com
botões, controles de Tabstrip, Table Control e outros elementos gráficos. Vide PBO, PAI e seqüências de telas e comunicação entre tela e programa;
Iniciar uma transação usando o seu código correspondente. Esse código deve iniciar com Z ou Y e o sistema armazena código de transação na tabela TSTC;
Inserir na caixa de texto User Command o código de transação SE80;
Clicar no botão ‘Processar Objeto’;
Escolher a opção TRANSAÇÃO e escolher o nome da transação;
Clicar em criar;
Escolher o Tipo de Transação:
Transação Diálogo – Module Pool – Chamada de tela
Transação Reports – Para reports
Transação Variante
Menu de Área – Habilitar menu de área
Transação Parâmetros
Caso os passos acima tenham sido executados com sucesso a transação foi criada com êxito.
DEBUGGER:
É uma ferramenta de depuração de erros e análise de execução de comandos/instruções.
Ele é utilizado para procurar erros semânticos nos programas. Existem vários modos de iniciar o Depurador:
- No Repository Browser, selecionar Testar/Executar - No ABAP Editor, selecionar Depuração
- Na transação a ser testada, digitar /h no campo de comando - Em qualquer tela, selecionar Sistema => Utilitários => Depuração.
A tela Depurador tem duas áreas. A área superior exibe o código do programa. Na área inferior, o sistema exibe várias informações adicionais, dependendo da visão selecionada. Para alterar entre as várias visões, usam-se os botões da parte superior da tela.
Selecionar Campos na parte inferior da tela para exibir o seu conteúdo. Posicionar o cursor no nome do campo na área “código de programa” e selecionar F2 ou clicar duas vezes no nome do campo.
• Pontos de parada
Finalidade: quando é selecionado Avançar no Depurador, o sistema continua a processar até alcançar o próximo ponto de parada. Os pontos de parada podem ser definidos como abaixo:
no Depurador: através de um clique duplo;
no Editor: através da instrução ABAP BREAK-POINT.
TIPOS DE TABELAS:
• Tabela Transparente
Existe uma tabela física no banco de dados para uma tabela transparente. Todos os dados empresariais e dados de aplicação são arquivados em tabelas transparentes.
Exemplo:
Todas as nossas tabelas do PW.ce.
EKKO – Cabeçalho do documento de compras. EKPO - Item do documento de compras.
Nosso sistema PW.ce grava todas as informações em tabelas transparentes
•••• Tabela Cluster – é uma tabela no banco de dados que contém um campo
LONG RAW (como uma “linha comprida”). O campo long raw contém uma string concatenando várias informações. Essas tabelas existem para permitir a criação de tabelas com mais de 255 campos que de outra forma não seria possível por uma limitação do banco de dados.
Exemplo: Tabela BSEG.
Nosso sistema PW.ce NÃO utiliza tabelas cluster.
•••• Tabela Pool - Um pool de tabelas é uma tabela de banco de dados que
permite que os dados de múltiplas tabelas do R/3 sejam armazenados dentro dele. As tabelas de Pool são uma estrutura proprietária da SAP e são utilizadas para armazenar um grande número de tabelas muito pequenas.
Nosso sistema PW.ce NÃO utiliza tabelas pool.
•••• Visão ou view – Um conjunto de duas ou mais tabelas transparente
integradas de forma relacional de forma que possam fornecer os dados de forma integradas (fazendo um join). Muito utilizadas para melhoria de performance de leitura dos programas ABAP, evitando que sejam criadas leituras com condições de JOIN muito complexas e demoradas.
objetivo de que certos dados sejam visualizados sempre que for chamada uma view
associada a eles.
A maior utilidade deve-se ao fato de criar uma consulta default e toda vez que se quiser visualizar os dados não será necessário “reinventar a roda”, ou seja, montar todo o select novamente.
Imagine uma consulta que manipule 10 tabelas e 40 campos será que há necessidade de ficar refazendo toda vez? Claro que não, crie uma view e toda vez que haja necessidade faça uma chamada a ela!
Uma view não é utilizada apenas para visualização dos dados, caso se crie uma view de apenas uma tabela, tem-se a opção de efetuar alterações (update, insert e delete) na mesma replicando assim os dados para a tabela de onde a view foi gerada.
•••• Estruturas - São como tabelas que não armazenam dados, definem um
conjunto de campos e geralmente são utilizadas para definir os dados em interface e telas, assim como para atribuir o tipo aos parâmetros de módulos de função. Utilizado para alocar memória para um grupo de campos. Uma estrutura diferentemente de uma tabela não tem uma tabela de banco de dados associada a ela.
Nosso sistema PW.ce utiliza estruturas para a exibição/alteração de dados nas telas de nossos programas, porém esses dados NÃO estão gravados fisicamente nessa estrutura, no caso esse campo dessa estrutura não possui dados físicos. Os dados estão todos gravados em tabelas transparentes.
DICIONÁRIO (DDIC).
Funciona como uma interface com um banco de dados ou ainda como um mini gerenciador de banco de dados onde podemos definir e criar diversos objetos de dicionário como tabelas transparentes, visões, estruturas elemento de dados, domínios, ajudas de pesquisa e objetos de bloqueio.
SE11 – MOSTRAR.
Transação onde podemos criar, alterar, exibir eliminar objetos como:
Tabelas transparente, visões, estruturas, elementos de dados, domínios, ajudas de pesquisa e objetos de bloqueio.
APRESENTAR TABELA TRANSPARENTE -> Conceito tabela física no BD
MANDANTE -> SEMPRE CHAVE
TIPO DE CAMPO - CRIAR – DENOMINAÇÃO DOMÍNIO – CRIAR E EXIBIR AS CATEGORIAS MOSTRAR OPÇÕES TÉCNICAS.
MOSTRAR ATUALIZAÇÕES PERMITIDAS. POPULAR A TABELA.
Exercício:
1 - Criar as tabelas ZTALUNO, ZTCLASSE, ZTPROF.
CONCEITO DE CHAVE ESTRANGEIRA – Toda chave estrangeira é chave
primária em alguma outra tabela do DDIC.
Criar uma CE entre a tabela de classe e a tabela de professores: ZTCLASSE-CODPROF -> ZTPROF-CODPROF.
Exercício:
1 – Criar CE entre a tabela de alunos e a tabela de classe onde: ZTALUNO-CLASSE -> ZTCLASSE-CLASSE.
APRESENTAR ESTRUTURA – Utilizado para exibir dados em tela, passagem de
parâmetros entre programas e criação de SAPscript..
Não armazena dados -> Espaço reservado para trânsito de dados.
CRIAR UMA ESTRUTURA: ZFALUNO IDÊNTICA À TABELA ZTALUNO
Conceito de Tabelas de Verificação:
Uma verificação de valores é automaticamente executada, na tabela de verificação, caso um campo de tela faça referencia a um campo do Abap Dictionary com controle de chave externa.
O Sistema exibe uma mensagem de erro e disponibiliza o campo para nova entrada quando uma tabela de verificação do campo não contem a entrada realizada.
O botão (F4) exibe todas as entradas contidas na tabela de verificação de um campo.
Todos os valores entrados em uma tela que possui valores fixos são, automaticamente, comparados com esses valores fixos.
O sistema exibe uma mensagem de erro e disponibiliza o campo para nova entrada quando uma entrada não corresponde a qualquer um dos valores fixos da tela.
Exercício:
1 – Criar uma estrutura para cada tabela transparente criada (ZTALUNO, ZTCLASSE, ZTPROFESSOR)
ATUALIZADOR DE TABELA.
MOSTRAR SM30 – ATUALIZAÇÃO DE TABELAS.
Podemos criar uma interface própria para atualizarmos dados em tabelas transparentes. Essa interface se chama Visão de Atualização e é criada através da transação SM30.
Temos que criar primeiro o gerados de atualização de tabela através da transação SM11, opção do menu: utilitários -> Gerador de atualização de tabelas.
Logo após criado o gerador de atualização de tabelas devemos:
Entrar na transação SE93 -> Digitar um nome válido para a trasação e clicar em criar.
Na tela seguinte informar uma descrição para a transação e marcar a opção de Transação com parâmetros e confirmar:
Na tela seguinte informar: Uma descrição para o texto da transação. Na opção transação informar a SM30 na caixa de texto e marcar o flag “Omitir 1ª tela”
Na parte inferior da tela informar em valores propostos:
Nome do campo de tela Valor
VIEWNAME Nome da tabela transparente
TABELA INTERNA.
CONCEITOS:
1 - São espaços de memória criados por um programa ABAP que só podem ser utilizadas enquanto um programa está sendo utilizado.
2 - Armazenar dados temporariamente dentro de um prog. ABAP. As tabelas internas só existem enquanto o programa estiver rodando.
3 - Tabelas criadas e declaradas dentro de um programa abap que não existem fisicamente no BD.
4 - São alimentadas por seleção em tabelas ou inserção via comando do programa e servem para guardar momentaneamente esses dados.
HEADER LINE
As tabelas internas podem ser definidas com ou sem uma linha de cabeçalho. Uma tabela interna com linha de cabeçalho é composta por uma área de trabalho e o corpo real da tabela, ambos endereçados com o mesmo nome.
O usuário pode declarar uma tabela interna com uma linha de cabeçalho através do suplemento WITH HEADER LINE.
Para evitar erros, recomenda-se que o usuário crie tabelas internas sem linha de cabeçalho. Entretanto, nas tabelas internas com linhas de cabeçalho é quase sempre possível usar uma sintaxe reduzida para certas operações.
Uma tabela interna é uma seqüência de linhas do mesmo tipo.
Em geral as tabelas internas ( também denominada matriz) são usadas para arquivar os resultados de processamento ou os dados de origem.
Elas são usadas para:
• Armazenamento temporário de dados das tabelas de banco de dados para processamento posterior.
• Arquivamento de dados para exibição de listas.
• Arquivo de dados para comunicação com o computador de mesa, outros servidores de aplicação do sistema R/3 ou sistemas não SAP.
As tabelas internas são descritas através de vários atributos, um dos quais é o tipo de linha. O tipo de linha determina a estrutura dos registros de dados que podem ser armazenados em uma tabela interna.
CARRID CONNID DISTANCIA Tipo de Linha
AA 0017 2,572
LH 0400 6,162 Dados
Outro atributo das tabelas internas são as chaves, que ajudam a identificar as entradas da tabela. O importante na definição de uma chave é a seqüência de seus campos.
Por exemplo, a chave CARRID CONNID é diferente de CONNID CARRID.
Existem dois tipos diferentes de acesso aos dados no Abap: com índice e com chave.
Acesso com índice: Significa usar o índice do registro de dados que o sistema mantem para acessar os dados.
Acesso com chave: significa usar o termo de pesquisa, em geral uma chave da tabela ou uma chave da tabela genérica, para ter acesso aos dados.
- Categorias de Tabelas
As tabelas internas podem ser divididas em três categorias. De acordo com o modo de acesso aos dados:
• Tabelas Standard: mantém, internamente, um índice linear e podem ser acessadas atraves do seu índice ou de sua chaves.
• Tabelas Ordenadas: São ordenadas de acordo com a chave e gravadas. Aqui, também um índice linear é utilizado internamente. Este tipo de tabela também pode ser acessada através do seu índice ou de suas chaves.
• Tabelas Aleatórias de Prova: Não mantém índice linear interno e podem ser acessadas apenas através de suas chaves.
As seguintes operações podem ser executadas com tabelas internas em ABAP:
Comando Efeito
APPEND Anexa o conteúdo de uma área de trabalho ao final de uma tabela interna
INSERT Insere o conteúdo de uma área de trabalho em um determinado ponto ( N° linha).
MODIFY Sobrescreve uma linha especifica com o conteúdo de uma área de trabalho;
DELETE Apaga uma linha especifica de uma tabela interna. LOOP AT Insere as entradas de uma tabela interna. Linha por
linha em uma área de trabalho.
READ TABLE Insere exatamente uma entrada da tabela interna
em uma área de trabalho.
SORT Ordena uma tabela interna.
CLEAR Limpa (apaga) uma área de trabalho ou uma tabela interna.
- Preenchimento de Tabelas Internas
O sistema permite usar tabelas internas sempre que houver uma seqüência de entradas ou linhas de mesmo tipo. Isto ocorre quase sempre quando um programa precisa de uma copia interna de uma determinada tabela do banco de dados.
O usuário pode preencher uma tabela interna com registros de dados de uma tabela do banco de dados utilizando um loop SELECT para colocar registros individuais de dados na área de trabalho de uma tabela interna e, depois, anexando o conteúdo da área de trabalho à tabela interna no loop SELECT.
A instrução APPEND deve ser utilizada para preencher uma tabela interna. Ao declarar uma tabela standard, o usuário não precisa usar o suplemento STANDARD.
Exemplos de criação.
Debugar e mostrar vazia.
Passar os parameters para dentro da ITAB. Mostrar APPEND -> explicar header line.
Exercício:
Algumas sintaxes de criação: DATA: BEGIN OF itab_zprof OCCURS 0, codprof like zprofessor-codprof,
nomeprof like zprofessor-nomeprof, dtnasc like zprofessor-dtnasc, END of itab_zprof.
OU
DATA: itab_zprof like zprofessor occurs 0 with header line. DATA: BEGIN OF itab_zprofessor OCCURS 0.
include structure zprofessor. data: idade(02) type c. DATA: END OF itab_zprof. OU
data: itab_zprof like zprofessor occurs 0 with heaDER LINE.
Exercício:
01 – Criar dentro do programa teste a declaração de tabela interna e compilar.
02 – Debugar a o programa e exibir HEADER LINE -> explicar.
03 - Criar parameters para tabela ZPROFESSOR e mover para tabela interna.
04 – Criar SELECTION SCREEN com bloco e frame.
Adendo a respeito da declaração OCCURS N em tabelas internas: General Performance Notes for Internal Tables
OCCURS Value or INITIAL SIZE Specification
Internal tables are a dynamic data structure. Their memory requirements are met in blocks. The initial memory allocation (hereafter called the OCCURS area), can be controlled using the " OCCURS n" or "INITIAL SIZE n " addition in the table definition (see DATA, TYPES). Once the OCCURS area is full, the next block to be created is twice as big as the OCCURS area (as long as this is not greater than 8 KB). All further blocks are then created with a constant size of 12 KB.
You can leave it to the system to determine the size of the OCCURS area by specifying n = 0. In this case, the system allocates only a "small" portion of memory at the first INSERT or APPEND statement. "OCCURS 0" or "INITIAL SIZE 0" means that 16 <= n <= 100 (depending on the line width).
It only makes sense to specify a concrete value of n > 0 when you know exactly how many entries the table will have, and you want to set up the OCCURS area exactly. This can be particularly important if you want to nest internal tables (where an "outer" internal table contains one or more other internal tables in each line, and the "inner" tables only have a few entries (no more than 5, for example).
To avoid excessive memory requirements, the system handles large values of n as follows: The largest possible value of n is n_max = 8 KB divided by the line width. For larger values, n is set such that n multiplied by the line width is around 12 KB.
MODULARIZAÇÃO: CONCEITOS: Organização do programa: INITIALIZATION. START-OF-SELECTION. END-OF-SELECTION. TOP-OF-PAGE. Form – Perform.
A estrutura Form / Perform é muito utilizada com qualquer tipo de programa, com ela executasse a modularização do código fonte através de blocos de processamento.
Algumas vezes é comum ocorrerem confusões entre funções e a estrutura form/perform pela seguinte causa:
Na função são passados valores quaisquer para serem processados e é obtido um retorno “X” qualquer definido pelo programador, enquanto no form/perform valores são passados para serem processados (podendo-se passar até uma tabela inteira), mas não obtem-se um único retorno.
O que ocorre é uma chamada a um processamento em bloco passando valores, representada pelo perform (que na realidade é uma chamada ao form). O conteúdo do programa que vem abaixo do PERFORM só é executado se o bloco de processamento FORM permitir, ou seja, neste tipo de estrutura não se fica esperando um único retorno e sim um contínuo processamento.
A maior utilização do FORM / PERFORM dá-se ao fato que em um programa bem modularizado o tempo de manutenabilidade fica reduzido gerando assim uma otimização das tarefas.
Exemplo:
Criar os eventos e forms de processamento. Passar parâmetros para o FORM.
COMANDO WRITE:
CONCEITO:
Serve tanto para mover dados tanto para saída de dados em tela. Criar no END-OF-SELECTION a saída da tabela ZTPROF.
Separadores do WRITE -> Cabeçalho de saída. FORMAT COLOR. INTENSIFYED ON/OFF.
Criar e mostrar a saída de dados da tabela interna ZTPROF.
Exercício:
1 – Criar o evento end-of-selection, o FORM de saída, o cabeçalho da saída, a saída dos dados e fazer a formatação de cores.
TABELA SYST: CONCEITO:
Tabela interna do sistema SAP/R3 que exibe controles internos importantes para o processamento dos Programas ABAP.
A tabela Syst é representatividade de todo o sitema R/3 através de alguns parâmetros. Parâmetros estes que permitem ao profissonal ABAP fazer verificações no sistema.
Verificações englobam muitos detalhes, a tabela Syst é tão completa que nos permite fazer desde verificações simples como a obtenção da data corrente até checks mais complexos como a verificação de qual evento foi disparado pelo usuário em um determinado momento.
Uma visão completa dos campos da tabela Syst é importante para que o profissional ABAP fique alerta sobre quais os eventos que ele pode controlar dentro do sistema, abaixo seguem alguns exemplos:
Sy-Index: Retorna um número de passagem atribuído, como por exemplo dentro de um loop.
Sy-Tabix: Em tempo de execução retorna a linha atual utilizada em uma tabela interna.
Sy-Ttabc: Número da última linha lida em uma tabela interna. Sy-Linct: Número total de linhas de uma certa lista gerada.
Sy-Listi: Número da linha que estiver atualmente selecionada em uma lista. Sy-Lsind: Número da lista de ramificação , pode-se por exemplo checar quantas sub-listas foram executadas a partir de uma lista X.
Sy-Currow: Mostra a posição do cursor em uma linha. Sy-Lisel: Mostra a linha selecioanda.
Sy-Cucol: Posição do cursor em uma coluna.
Sy-Binpt: Retorna se um batch input está ou não ativo. Sy-Calld: Retorna se um modo de call está ou não ativo. Sy-Mandt: Número do mandante logado no sistema SAP. Sy-Opsys: Sistema operacional utilizado.
Sy-Ucomm: Mostra a ação “X” qualquer que o usuário deseja realizar, após um evento ter sido executado pelo usuário.
Sy-Waers: Tipo de moeda utilizado. Sy-Datum: Data do dia.
Sy-Uzeit: Hora
Sy-Uname: Usuário logado no SAP. Sy-Host: Nome do host (máquina).
Sy-Subrc: return code (resultado de comandos) Sy-tcode: Nome da transação.
SY-SUBRC = um dos mais importantes -> Retorna 0 (zero) se a instrução anterior foi executada com sucesso.
Número de retorno após uma instrução ABAP. Instrução com sucesso = 0.
Instrução com erro <> 0.
Sempre utilizado após SELECTS e diversos comandos de busca, inserção e deleção de dados.
COMMIT WORK/ROOLBACK WORK:
Commit Work é uma técnica utilizada para salvar dados em um BD, esta gravação é física, ou seja, os dados são “jogados” diretamente nas tabelas, para confirmar as operações efetuadas no insert, update, etc. Normalmente deixamos o SAP fazer este gerenciamento de gravação pois ele consiste todos os dados em todas as tabelas, replicando assim as alterações.
O Commit não é uma técnica muito utilizada pois a margem de acontecimentos de erros em sua execução é bastante alta.
Caso um processo de carga esteja sendo executado e aconteça um erro e o Commit ainda não tenha sido efetuado podemos desfazer as operações executadas até aquele momento com o comando ROLLBACK WORK.
Exemplo I:
Program ... Module User_Command Input.
... ... Case save_ok. When ‘BACK’. ... ... Message Axxxx. ROLLBACK WORK. When ‘SAVE’. ... ... COMMIT WORK. EndCase. EndModule. Exemplo II:
Ciclo de vida COMMIT x ROLLBACK
|---|---|
Lock – Enqueue / Dequeue
O programa SAP R/3 utiliza lock nas tabelas por motivo de consistência dados; em tempo de execução podem existir 2 ou mais pedidos de alteração quase ao mesmo tempo em um campo X.
O sistema para evitar alterações incorretas nos seus dados, se utiliza de um processo denominado “ LOGICAL LOCKS ” que consiste em criar uma fila de processamento com utilização exclusiva da table para cada transação que deseja manipular a mesma.
Exemplo:
Em um intervalo de tempo de 0,001 s. chegam duas solicitações para alteração, a transação de nº.: 01 “trava” a tabela para que esta seja somente manipulada por ela que chegou 1º. Após a liberação desta tabela pela transação de nº.: 01 a nº.: 02 irá começar a manipular a tabela, ficando esta neste momento exclusiva da própria transação.
Observa-se que o processo de travamento da table é efetuada por um objeto que é chamado exclusivamente para isto:
Início Fim
Commit Commit
- ENQUEUE_<Nome da Tabela>.
Para a liberação da mesma é chamado um outro objeto: - DEQUEUE_<Nome da Tabela>.
Outro detalhe a ser observado é que antes de se utilizar os objetos, os mesmos devem ser criados no ABAP Dictionary. A criação destes objetos poderá ser efetuada para a manipulação de 1 ou N tabelas, vale lembrar apenas que se houver manipulação em N tabelas deve antes existir um relacionamento entre elas.
LOOP – ENDLOOP:
Estrutura de repetição comumente usada nos programas ABAP.
Serve para percorrermos as tabelas internas, permitindo que registro a registro possam ser lidos e atualizados na header line fazendo com que esse possa ser manipulado.
A instrução de loop LOOP AT .. ENDLOOP permite processar múltiplas entradas de tabela interna. Cada vez que a instrução é executada no loop, o sistema coloca a próxima entrada da tabela na área de trabalho <wa> especificada no campo INTO.
O comando LOOP permite acessar as entradas da tabela interna através de índice e de chaves.
Ao acessar através de chaves, recomenda-se restringir o numero de entradas ou linhas a serem lidas com a clausula WHERE, exatamente como se faz com um comando SELECT.
Sintaxe básica:
LOOP itab where campo = variável.
. . .
ENDLOOP.
Exercício:
01 – Dar LOOP nas tabelas internas criadas nos exercícios passados e debugar.
02 – Dar LOOP com condições. (EX: Salário do professor maior que R$1000,00).
03 – Dar LOOP na saída de resultados e só imprimir se salário <> R$1000,00.
IF, ELSE, ENDIF:
Estrutura condicional usada para desviarmos o curso da programação TOP-DOWN. Sintaxe básica: IF condiçao1. Seqüência de comandos X . ELSE. Seqüência de comandos Y . ENDIF.
A seqüência de comandos X será executada caso a condição 1 seja verdadeira. Se a condição 1 for falsa somente a seqüência Y será executada.
Exercício:
01 – Criar um novo REPORT onde:
Tela de seleção com Código do aluno (obrigatório), nome do aluno e sexo do aluno (usar a tabela ZTALUNOS como referência).
O relatório deverá ter no máximo 80 colunas .
Mudar a descrição de tela dos parâmetros utilizados para que fiquem com a aparência do cabeçalho abaixo.
O programa deverá gravar em tabela interna todo o conteúdo da tela de seleção e apresentar como resultado de tela a seguinte listagem:
Cód. Do aluno Nome do aluno Sexo
Na tela de saída o programa deve verificar o sexo do aluno (se = M ou F) e preencher no campo de saída ‘Sexo’ o texto variável: ‘MASCULINO’ ou ‘FEMININO’.
Se o código do aluno for igual a 000 o programa imprimirá na tela de saída a constante: ‘TÉRMINO DA LISTAGEM’ com o fundo em AMARELO.
ATENÇÃO:
01 – Adicionalmente podemos incluir um TOP-OF-PAGE com os seguintes dados: ‘ACADEMIA ABAP 2006 – DATA DD/MM/AAAA – HORA: HH:MM:SS’
02 – os campos da tabela SYST contém valores referentes ao sistema, como hora, data, código de transação que está sendo executada, código de retorno de comandos (sy-subrc).
03 – Inserir na tabela interna ao menos 3 registros (1 via parameters 2 via MOVE/APPEND.
CASE:
Instrução condicional que permite diferenciação de caso. Exemplo:
CASE sy-ucomm. “ Verifica o valor da variável
WHEN ‘INC’. “ Executa se o usuário clicar no botão incluir
PERFORM incluir.
WHEN ‘CANC’ OR ‘VOLT’. “ Executa se clicar no botão cancelar SET SCREEN O.
WHEN OTHERS. “ Executa quando for escolhida outra opção
Instruções ENDCASE.
INSERT.
Adiciona novas linhas a uma tabela de dados.
Grava fisicamente registros em tabelas transparentes.
Se os dados da chave da tabela estiverem duplicados os registros na serão gravados -> SY-SUBRC = 4.
INSERT dbtable FROM itab.
Adiciona os dados de uma tabela interna em uma tabela de banco de dados.
INSERT dbtable.
Adiciona 1 registro na tabela de banco de dados.
IMPORTANTE: Confirmar com SY-SUBRC = 0 e dar COMMIT WORK.
Exercício:
01 – Utilizando o exercício anterior realizar a gravação dos dados da tabela interna e após a gravação exibir uma mensagem do tipo I (informação) dizendo se o registro corrente foi gravado ou não.
SORT.
O Comando SORT realiza uma organização da tabela interna conforme a ordem declarada em sua sintaxe.
Para ordenar uma tabela interna, deve-se usar a instrução SORT. As adições BY e ASCENDING ou DESCENDING permitem restringir a ordenação a campos específicos e determinar a seqüência e a hierarquia da ordenação.
Campos texto podem ser ordenados por idioma utilizando o suplemento AS TEXT.
DATA: itab_aluno TYPE TABLE OF ztaluno.
SELECT * FROM ztalunoi INTO TABLE itab_aluno. SORT itab_aluno BY nomeal ASCENDING
dtnasc DESCENDING. Sintaxe básica:
SORT itab BY campo1 campo2 campon.
SORT itab DESCENDING BY campo1 campo2 campon.
Exercício:
01 – utilizar o exercício anterior e exibir a saída do relatório organizando por nome do aluno e sexo -> ASCENDING e DESCENDING.
MODIFY.
Realiza alterações de gravação em um registro de uma tabela interna. Insere registros em tabelas de banco de dados, se o registro já existir um UPDATE é executado automaticamente nesse registro.
Sintaxe básica: MODIFY dbtable.
MODIFY dttable FROM itab.
MODIFY itab INDEX n TRANSPORTING c1 c2 cn. MODIFY itab transporting c1 c2 cn WHERE condição.
Exercício:
01 – Com o exercício anterior alterar todos os nomes dos alunos para a constante ‘JOSÉ DA SILVA’.
DELETE.
Deleta registros de uma tabela interna. Deleta registros de uma tabela do BD. Sintaxe básica:
DELETE FROM dbtable WHERE condição. DELETE itab WHERE condição.
DELETE ADJACENT DUPLICATES FROM itab.
CLEAR:
A instrução CLEAR é utilizada para restaurar o conteúdo de um objeto de dados ao seu valor inicial, de acordo com a sua categoria.
Considerando que as entradas da tabela interna são sempre de uma única categoria, é suficiente uma instrução CLEAR para eliminar toda a tabela ou os valores em sua header line.
