MATERIAL COMPLETO

DEBUG PARA
FUNCIONAIS

CARLOS EDUARDO DE SOUZA

ferramentas e linguagens diferentes, como C, C++, VB6, Java, PL/SQL, SQL;

para clientes.

PABLO CURTI
Pablo iniciou sua carreira em 2007 na Ancora Business Management como

Virgolino de Oliveira fazendo a avaliação, análise de requisitos e

Atuou no grupo Tereos como consultor SAP SD integrando com a equipe

SAP Tereos na França, e hoje atua como consultor SAP SD responsável pelo
AMS de vários clientes.

MARCOS VINICIUS
MOREIRA LOPES
Peruzzo Supermercados, logo passou ao cargo de key user SD e foi
contratado pela ITS Group. Desde 2013 trabalha como consultor SD, LES e
NFe.

Atualmente é consultor SAP SD responsável por fazer implantações, pré

ÍNDICE
CONHECENDO O DEBUG

COMANDOS DE EXECUÇÃO DENTRO DO DEBUG

BREAKPOINT

COMO ENTENDER O CÓDIGO?

TRANSAÇÃO X PROGRAMA EXECUTÁVEL

COMO SABER QUAL PROGRAMA ESTOU EXECUTANDO?

O QUE É UMA BAPI?

MAPEANDO UMA BAPI

CONHECENDO
O DEBUG
É comum programas de computador terem defeitos que levam a

comportamentos indesejados ou valores incorretos. Em computação estes

erros são comumente chamados de “bugs”. O ato de investigar e corrigir

bugs em um programa é chamado de “debugging”. Para fazer isso utilizamos

um programa especial chamado “debugger”. Um debugger permite que o

desenvolvedor visualize o código sendo executado em tempo real e todos os

valores gerados durante a execução.

Para facilitar, daqui para frente vamos chamar este programa de DEBUG.

O DEBUG pode ser acessado de duas formas:

A) Digitando /h no campo de transações e então

executando qualquer ação na tela – isso vai
abrir o DEBUG e parar na próxima linha
executável da ação realizada na tela;

B) Colocando um ponto de parada em alguma

linha executável do programa que você vai
executar. Quando a execução chegar naquela
linha, o DEBUG será aberto.

O DEBUG será inicializado em uma nova janela dentro do SAP. Caso não haja

uma nova janela disponível (por exemplo, já existem 6 abertas nesta sessão),

será aberto o DEBUG antigo.

A versão antiga serve para o mesmo propósito, porém possui uma interface

muito limitada e difícil de utilizar. Caso isso tenha acontecido, o DEBUG novo

pode ser aberto fechando uma das janelas abertas e depois indo no menu:

Debugger » Mudança para o ABAP debugger novo.

No DEBUG existem diversas abas com diferentes telas. Dependendo da

configuração do sistema e da versão, a ordem ou o layout das abas pode

mudar. Vamos investigar as principais telas:

1O código sendo
executado
Exibe o contexto do código
sendo executado no
momento. A seta indica qual
a próxima linha (comando) a
ser executada.

2 Variáveis
Aqui é possível acompanhar
em tempo real o valor das
variáveis do programa. Em
um programa de
computador, uma variável
representa uma posição de
memória em que podemos
armazenar informações
temporariamente.

3 Pilha

A pilha representa o histórico

de chamadas dentro de um
fluxo de execução (mais
informações na versão
paga... penso que a pilha é
bem importante pra análises,
principalmente porque é
possível navegar nela).

4 Visão de
Tabelas
aqui é possível visualizar o
conteúdo das tabelas
internas (mais informações
sobre tabelas internas na
versão paga?)

5 Visão de
breakpoints
Permite visualizar todos os breakpoints colocados,
independente se forem de sessão ou não, se forem
em comandos específicos, se estão ativos etc.
 COMANDOS DE
EXECUÇÃO DENTRO
DO DEBUG
Para executar o programa via debug, existem 4 ações permitidas com

utilidades diferentes. São elas:

• F5 (etapa individual) – executa passo a passo todas as linhas de código,

incluindo de todas as chamadas de contexto dentro ou fora do programa

atual;

• F6 (executar) – executa passo a passo todas as linhas de código, mas “pula”

(executa em segundo plano) todas as chamadas de contexto dentro ou fora

do programa atual;

• F7 (retornar) – executa em segundo plano o contexto atual e volta para o

ponto da chamada anterior;

• F8 (avançar) – executa o programa em segundo plano até encontrar um

ponto de parada. Se não houver nenhum ponto, executa até o final

BREAKPOINT
O breakpoint ou ponto de parada é uma

funcionalidade que permite parar a execução do

programa num ponto definido por você. Sempre que um

breakpoint for alcançado, o debug será aberto (se

ainda não estiver) para que você possa continuar a

execução passo a passo a partir daquele ponto.

Existem diversas formas diferentes de colocar um

breakpoint num programa. Pode ser explícito via código

ABAP, selecionando a linha em que você quer o BP, num

comando específico, numa mensagem específica,

entre outros.

Para colocar um breakpoint em um programa, abra o

código dele na SE38 e vá até a linha desejada.

É só clicar na coluna bege do lado esquerdo do número

da linha. Se já estiver no DEBUG, você pode colocar

novos breaks da mesma forma diretamente na visão do

código.

BPs colocados via DEBUG ficam ativos apenas durante

a execução atual; no final da execução eles serão

eliminados. Chamamos isso de BP de depurador. Se

quiser que o BP fique ativo mesmo depois da execução,

é necessário clicar em Salvar dentro do DEBUG –

chamamos estes de BPs de sessão.

BPs colocados via SE38 são sempre de sessão.

COMO ENTENDER
O CÓDIGO?
Quando você olhar o código, pode achar que

isso vai atrapalhar mais do que ajudar...

principalmente se for a primeira vez. Porém,

existem alguns pontos que podem facilitar seu

entendimento.

Primeiramente, o código pode ser dividido entre

duas partes principais: uma para definições

(quais variáveis o programa vai usar?) e outra

executável (o que vai ser processado de fato).

Essas partes podem estar intercaladas entre si.

Para a parte de definições, é interessante notar os tipos. Tipo é um atributo

do dado que informa como o desenvolvedor pretende usar aquele dado. A

informação em questão é um número? É um texto? Uma data? Em ABAP

normalmente todas as variáveis possuem tipos.

Além disso, existe um dicionário de dados que define dados globalmente no

SAP e pode ser acessado pela transação SE11. Lá estão as definições e tipos

de todas as tabelas, visões de atualização da SPRO, entre muitas outras

coisas. Um desenvolvedor pode utilizar qualquer informação da SE11 em seu

programa (exemplo: definir uma variável com as mesmas características da

tabela VBAK).

Para a parte executável, observe os seguintes pontos:

• Na parte executável, todos os comandos ABAP estão em azul. Um comando

ABAP é uma ordem para que o programa realize alguma ação predefinida

como comparar dois valores, chamar uma transação, obter dados do banco

de dados, exibir uma mensagem para o usuário etc.

• Quase tudo que não estiver azul num código executável é uma variável.

Variável é uma posição de memória que serve para guardar uma

informação. Quando você visualiza um ALV, todas aquelas informações

estão em variáveis.
 TRANSAÇÃO
X
PROGRAMA
EXECUTÁVEL
Quando você digita algo (válido) na barra de transações, algum programa

será executado.

A transação serve como um atalho para a execução de programas.

Dessa forma, um programa pode ter várias transações diferentes (ex: VA01,

VA02, VA03...), mas cada transação pode executar apenas um programa.

COMO SABER QUAL

PROGRAMA ESTOU
EXECUTANDO?
Em algumas situações pode ser útil saber qual é o

programa que você está executando em uma dada

transação. Para fazer isso, basta ir ao Menu sistema »

Status.

No quadro Dados Repository, você terá a informação de

qual transação e qual programa está

BAPI
executando (entre outras)

O QUE É
UMA BAPI?
BAPIs (Business Application Programming Interface) são módulos de função

especiais que funcionam como interfaces para que programas e aplicações

externas tenham acesso a processos de negócio e dados dentro do sistema SAP.

De forma geral BAPIs são usadas para processar informações da mesma forma

que uma transação faria, porém sem ação do usuário.

Abaixo vamos ver como obter dados de uma ordem de venda e depois criar uma

outra ordem de venda utilizando BAPIs.

MAPEANDO
UMA BAPI
Para acessar a interface das BAPIs (e de qualquer outro módulo de função),

é necessário executar a transação SE37. Após digitar o nome da BAPI clique

em executar para acessar a interface de execução. Neste ponto é possível

preencher os parâmetros manualmente e verificar o resultado.

BAPISDORDER_GETDETAILEDLIST
Primeiramente vamos utilizar uma BAPI simples que retorna os dados de uma

ordem de venda: BAPISDORDER_GETDETAILEDLIST.

No parâmetro I_BAPI_VIEW, sinalize as informações que deseja obter. Por

exemplo, abaixo estamos buscando o cabeçalho, o item e os parceiros:

Ao executar, serão

exibidos os

resultados:

Detalhe do resultado dos parceiros:

Observe que são as mesmas informações da VA03:

BAPI_SALESORDER_CREATEFROMDAT2
Agora vamos ver como criar uma ordem de venda a partir de uma BAPI. Para

isso vamos utilizar a BAPI BAPI_SALESORDER_CREATEFROMDAT2, que é

análoga à transação VA01.

Chamamos de mapeamento o processo de verificar tudo que é necessário e

preencher os campos da BAPI para que a execução seja bem sucedida.

Preenchemos os dados do cabeçalho (ORDER_HEADER_IN) com informações

similares às que usamos na VA01:

Para algumas BAPIs existe também uma estrutura com sufixo “X”. Ela indica

quais campos serão de fato considerados no momento da execução:

Em seguida informamos os itens na tabela ORDER_ITENS_IN (e para cada

campo preenchido aqui, também é necessário marcar com um X os campos

correspondentes na ORDER_ITENS_INX):

Após a execução, se tudo der certo, a BAPI vai retornar o número da ordem

de venda criada:
 BREAKPOINT
EXTERNO
Além das formas já abordadas, é possível também utilizar breakpoints

externos. Este recurso permite interromper a execução e abrir o debug

quando a execução não foi iniciada pela sessão do usuário que vai

debugar. Exemplo: você precisa debugar a ação que um usuário fará em

outro lugar, ou a origem do processamento está em outro servidor/fora do

SAP.

Particularidades:

• Breakpoints externos são válidos por apenas duas horas

• Você deve informar qual usuário fará o processamento e este usuário

deve ser de diálogo

• O debug será aberto apenas na sessão em que o breakpoint foi criado

(não faça logoff!)

BREAKPOINTS
ESPECÍFICOS
Para agilizar o processo de investigação, temos diversas formas de acionar

o DEBUG baseado em alguma informação que já temos. Vimos

anteriormente como colocar breakpoints em uma determinada linha de

um programa. Vamos ver agora como acionar o debug sem saber

exatamente qual linha de código queremos investigar.

Primeiramente acione o DEBUG digitando /h no campo de transações e

depois executando a ação desejada. Já dentro do DEBUG, aperte F9 ou

navegue para o menu Ponto de parada » Criar ponto de parada. Uma nova

janela será aberta com algumas opções para breakpoint. Estas são as

mais utilizadas:

• Comandos ABAP: faz o DEBUG parar na próxima vez que for executado o

comando inserido aqui. Comandos ABAP comuns são IF, SELECT, CALL

FUNCTION, LOOP, MESSAGE;

• Método: aciona o DEBUG na próxima vez que o método digitado for

executado. Métodos são trechos de código que pertencem a uma classe.

De forma bem simplista, uma classe seria como uma definição de dados.

Métodos são chamados pelo comando CALL METHOD;

• Módulo de função: um trecho de código que serve para algum propósito

específico e independe de qualquer programa. Por exemplo, as BAPIs que

vimos anteriormente. São chamados pelo comando CALL FUNCTION;

• Form: um trecho de código pertencente a um programa. Para utilizar esta

opção, é necessário também informar o programa a que o form pertence.

Forms são chamados pelo comando PERFORM;

• Mensagem: aciona o DEBUG quando uma mensagem específica for

disparada. Isso é extremamente útil para casos em que seu cenário termina

com mensagem de erro e você não consegue entender o motivo.

Mensagens também são disparadas com o comando MESSAGE.

BADI
O QUE É
UMA BADI?
BAdI é a sigla de Business Add-In. São interfaces providenciadas pela SAP em

pontos estratégicos das transações e podem ser implementadas e utilizadas

para alterar o funcionamento standard. Por exemplo, podemos realizar

validações ou alterar valores em tempo de execução de forma transparente

para o usuário.

BAdIs podem (ou não) ser implementadas várias vezes e não há perda com

upgrades ou aplicação de notas.

BAdIs são acessadas pela SE18 (definições) e SE19 (implementações).

Como encontrar uma BAdI?

Existem diversas formas. Vamos listar algumas possíveis via ABAP.

Se você quer apenas pesquisar, a melhor forma é via SE84. Verifique antes qual o

pacote da transação (isso pode ser feito pela SE93 – ex: as transações VA*

utilizam o pacote “VA”). Na SE84, navegue para Ampliações » Business Add-Ins »

Definições, digite o pacote e clique em executar. O sistema exibirá uma lista de

todas as BAdIs disponíveis neste pacote.

Se preferir e quiser saber qual a BAdI e o método chamado em determinado

momento da execução de uma transação, existem duas formas principais

(lembrando que você vai ter que acionar o debug via /H antes de executar a

ação desejada na tela):

• GET BADI: no debug, adicione um breakpoint no comando GET BADI. Ele é

executado para

as chamadas de BAdI durante a execução da transação;

• CL_EXITHANDLER: você também pode criar um break para a classe

CL_EXITHANDLER, método GET_CLASS_NAME_BY_INTERFACE. Alternativamente,

você acessar a transação de classes, SE24, entrar a classe CL_EXITHANDLER e

colocar um breakpoint no método GET_CLASS_NAME_BY_INTERFACE. Este

método é acionado todas as vezes em que uma BAdI é chamada.

OUTROS
MACETES
Como encontrar a transação de uma

view de atualização/SM30?

Imagine o cenário: pelo debug você

identificou no código que falta preencher

uma tabela de parâmetros criada para

este cenário. Você viu o nome da tabela,

mas como verificar em qual transação

você a preenche?

Existe uma tabela que armazena transações deste tipo: TSTCP.

Pela SE16N, acesse a tabela TSTCP e digite o nome da tabela Z entre aspas no

campo Parâmetro (PARAM) – exemplo: *ZSD001*.

Claro, você sempre pode dar manutenção na tabela via SM30, mas quase

nunca o usuário vai ter acesso a ela. Para facilitar o entendimento do usuário,

é sempre bom saber a transação.

Como procurar alguma palavra específica em todos os programas?

Às vezes precisamos saber quais programas utilizam determinada tabela,

determinada chave de STVARV ou algum outro texto/nome que você

conhece.

Para isso podemos utilizar o report standard RS_ABAP_SOURCE_SCAN. Nele é

possível fazer essa busca (entre outras).

Ex: preencha o campo “Cadeia procurada” com o nome de tabela, selecione

o pacote (geralmente vamos procurar coisas desenvolvidas, então vai ser

algo como Z*) e clique em executar.

Será exibida uma lista das ocorrências, como um CTRL+F.

Observe que Enhancements não entram nessa busca. Portanto, dependendo

da forma em que o desenvolvimento foi feito, é possível que sua busca esteja

fora da área de pesquisa.

Como debugar uma janela pop-up?

Imagine um cenário em que você se deparou com uma janela pop-up te

avisando de algum problema na transação, e você quer verificar via debug o

que aconteceu. Como vimos, digitar /h na barra de transações vai ligar o

debug e parar na próxima instrução, o que é basicamente o que você

precisa. Mas um pop-up não tem barra de transações...

Nesse caso podemos utilizar um arquivo texto com o seguinte conteúdo:

[FUNCTION]

Command=/H

Tittle=Debugger

Type=SystemCommand

Basta arrastar esse arquivo para a janela que você quer e o debug será

ligado.

Como um ABAP gostaria de receber uma especificação funcional?

De forma geral, como um ABAP vai fazer desenvolvimentos para praticamente

todos os módulos que existem, a chance é que ele tenha pouco (ou nenhum)

conhecimento sobre o processo em que o funcional está especificando.

Portanto, além de uma explicação breve sobre o cenário e a necessidade do

ajuste, ajuda muito saber de onde a informação vem: de qual tabela, qual

campo, a relação das informações (dependências) etc. A regra pode ser

explicada em alto nível (sem código), pois cada programa é escrito de uma

forma diferente e o ABAP vai adaptar a regra a qualquer circunstância.

Algumas pessoas vão na transação e pegam a informação técnica do campo

que querem mapear. Isso funciona em muitos casos, mas também pode

atrapalhar mais do que ajudar: dependendo da forma com que o programa foi

desenvolvido, o campo técnico pode ser apenas uma variável. Como vimos

anteriormente, variáveis só existem em tempo de execução e não é possível

buscar informações como buscamos do banco de dados.

Se você vai informar quais campos devem ser obtidos e quais tabelas, é sempre

importante verificar a validade das informações via SE16N: “esse campo sempre

vai estar preenchido?”, “realmente vai acontecer de tabela1-campo1 =

tabela2-campo2?”; “fazer a busca por este campo vai ter uma performance

aceitável?”.

Receber informação de qual BAdI utilizar para fazer uma validação, ou qual BAPI

utilizar para executar um processo é sempre bem-vindo.

Um cenário já pronto para que o ABAP possa reproduzir, debugar e entender

exatamente o que está acontecendo é extremamente importante. Caso seja

um novo desenvolvimento, tentar mostrar como deve ficar o resultado final.

 rocket_hub_
marcos_rockethub
pablovcurti