AMDP em ABAP do zero: como criar sua primeira procedure e usá-la no código

Seu primeiro contato com AMDP

Se você programa em ABAP e ouviu falar de AMDP, provavelmente veio junto uma sensação de complexidade: "SQLScript? procedure no banco? preciso saber HANA?". A boa notícia é que, do ponto de vista do ABAP, uma AMDP é só um método de classe — você define, implementa e chama exatamente como já faz hoje. O que muda é apenas o que vai dentro do método.

AMDP (ABAP Managed Database Procedures) permite escrever uma rotina que roda direto no SAP HANA, mas mantendo tudo dentro de uma classe ABAP — transportada, versionada e ativada como qualquer objeto. Você escreve a lógica em SQLScript (a linguagem de procedures do HANA), e o ABAP cuida de executá-la no banco quando alguém chama o método.

Este guia é a sua primeira apresentação prática: vamos montar uma classe AMDP do zero, entender cada linha, e ver como chamá-la e integrá-la no seu código ABAP — num relatório e dentro de uma classe de aplicação.

O que é AMDP em uma frase?

AMDP é uma forma de colocar lógica de banco — escrita em SQLScript — dentro de um método de classe ABAP, para que ela execute diretamente no SAP HANA. Em vez de trazer milhares de linhas para o servidor de aplicação e processá-las num LOOP, você empurra o trabalho para perto dos dados. Esse princípio tem nome: code pushdown.

O código mora no ABAP; a execução acontece no banco. Para quem chama o método, nada disso aparece — é uma chamada ABAP normal, com parâmetros de entrada e saída.

Como ABAP e HANA dividem o trabalho?

Pense em duas camadas. O servidor de aplicação ABAP é onde vivem suas regras de negócio, validações, mensagens e telas. O banco HANA é onde vivem os dados e onde joins, agregações e cálculos pesados rodam muito mais rápido. AMDP é a ponte que deixa você escrever um pedaço de lógica que executa lá embaixo, no banco.

"Só transicione para AMDP quando não conseguir cumprir os requisitos com Open SQL ou CDS. E evite loops dentro do SQLScript — eles destroem a performance."

A regra prática para um iniciante: comece sempre por Open SQL e CDS. Quando o problema for um processamento de dados que só o SQLScript resolve bem — aí entra a AMDP.

A anatomia de uma classe AMDP

Toda classe AMDP tem três partes que você precisa reconhecer. A primeira é a interface marker IF_AMDP_MARKER_HDB: ela não tem métodos, apenas sinaliza ao sistema que esta classe carrega métodos AMDP para HANA. A segunda são os tipos que descrevem a entrada e a saída. A terceira é o método em si, declarado de forma normal.

Veja a definição completa de uma classe simples que busca alunos por id. Leia com calma — cada bloco tem um papel:

CLASS zcl_amdp_student DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    " 1) A interface marker — obrigatória em toda classe AMDP
    INTERFACES if_amdp_marker_hdb.

    " 2) Tipos que descrevem a saída do método
    TYPES:
      BEGIN OF ty_student,
        id   TYPE zvb_stu-id,
        name TYPE zvb_stu-name,
      END OF ty_student,
      tt_student TYPE STANDARD TABLE OF ty_student WITH EMPTY KEY.

    " 3) O método — declarado como qualquer CLASS-METHODS
    CLASS-METHODS fetch_students
      IMPORTING
        VALUE(iv_id)  TYPE zvb_stu-id
      EXPORTING
        VALUE(et_stu) TYPE tt_student.
ENDCLASS.

O corpo do método: escrevendo o SQLScript

Aqui está o ponto onde uma AMDP se diferencia de um método ABAP normal. Em vez de comandos ABAP, o corpo do método é SQLScript — e você sinaliza isso na própria assinatura da implementação, com uma sequência de palavras-chave:

CLASS zcl_amdp_student IMPLEMENTATION.

  METHOD fetch_students
    BY DATABASE PROCEDURE   " este método é uma procedure de banco
    FOR HDB                 " para o banco de dados HANA
    LANGUAGE SQLSCRIPT      " escrito em SQLScript
    OPTIONS READ-ONLY       " apenas leitura — libera otimização
    USING zvb_stu.          " declara as tabelas/views acessadas

    et_stu =
      SELECT id,
             name
        FROM zvb_stu
       WHERE id = :iv_id;

  ENDMETHOD.

ENDCLASS.

Quatro detalhes merecem sua atenção como iniciante:

• BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT é o "cabeçalho" que transforma o método numa procedure HANA. Decore essa sequência.

• OPTIONS READ-ONLY avisa o HANA de que o método só lê dados — o que libera paralelismo e otimização. Use sempre que não houver escrita.

• USING zvb_stu lista todas as tabelas e views que o método acessa. Se esquecer uma, a ativação falha. É obrigatório.

• O :iv_id com dois-pontos é como o SQLScript referencia os parâmetros de entrada. Sem os dois-pontos, ele não enxerga o parâmetro.

Repare também que o resultado é atribuído ao parâmetro de saída (et_stu = SELECT ...). No SQLScript de uma AMDP, é assim que você "devolve" dados: atribuindo o resultado de um SELECT a um parâmetro tabular.

Como chamar a AMDP dentro do seu código ABAP?

Esta é a parte que mais surpreende quem está começando: não existe sintaxe especial para chamar uma AMDP. Você invoca o método como qualquer outro método estático de classe. O runtime ABAP é quem descobre que aquilo roda no banco e cuida da execução. Veja num relatório simples:

REPORT ztest_amdp_student.

PARAMETERS p_id TYPE zvb_stu-id.

START-OF-SELECTION.

  " Tipa a tabela de resultado usando o próprio tipo da classe AMDP
  DATA lt_stu TYPE zcl_amdp_student=>tt_student.

  " Chamada estática normal — nada de "CALL DATABASE PROCEDURE"
  zcl_amdp_student=>fetch_students(
    EXPORTING
      iv_id  = p_id
    IMPORTING
      et_stu = lt_stu
  ).

  cl_demo_output=>display_data( lt_stu ).

Do ponto de vista do programa, fetch_students é apenas um método que recebe um id e devolve uma tabela. O fato de a lógica rodar no HANA fica totalmente escondido. É essa transparência que torna AMDP fácil de adotar: você troca a implementação interna sem mudar quem chama.

Integrando a AMDP dentro de uma classe de aplicação

No mundo real você raramente chama a AMDP direto de um relatório. O padrão saudável é envolvê-la numa classe de aplicação, que mantém a regra de negócio em ABAP e usa a AMDP apenas como camada de acesso a dados. Assim você respeita a fronteira: SQLScript faz o trabalho de banco; o ABAP faz o resto.

CLASS zcl_student_service DEFINITION
  PUBLIC FINAL CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS get_active_student
      IMPORTING iv_id         TYPE zvb_stu-id
      RETURNING VALUE(rs_stu) TYPE zcl_amdp_student=>ty_student
      RAISING   cx_student_not_found.
ENDCLASS.

CLASS zcl_student_service IMPLEMENTATION.

  METHOD get_active_student.
    " 1) Acesso a dados: delega para a AMDP (roda no HANA)
    DATA lt_stu TYPE zcl_amdp_student=>tt_student.

    zcl_amdp_student=>fetch_students(
      EXPORTING iv_id  = iv_id
      IMPORTING et_stu = lt_stu ).

    " 2) Regra de negócio: validação fica em ABAP, não na AMDP
    IF lt_stu IS INITIAL.
      RAISE EXCEPTION TYPE cx_student_not_found.
    ENDIF.

    rs_stu = lt_stu[ 1 ].
  ENDMETHOD.

ENDCLASS.

Note a divisão clara: a AMDP só busca dados; a validação e a exceção vivem na classe ABAP. Essa separação é a melhor prática número um para quem está começando — não misture regra de negócio dentro do SQLScript.

Um exemplo um pouco mais real: join no banco

O valor de verdade da AMDP aparece quando há um join pesado ou agregação. Em vez de fazer um SELECT no cabeçalho, um LOOP e um SELECT nos itens por linha (o clássico anti-padrão que enche a rede), você deixa o HANA cruzar tudo de uma vez:

METHOD get_sales_for_order
  BY DATABASE PROCEDURE
  FOR HDB
  LANGUAGE SQLSCRIPT
  OPTIONS READ-ONLY
  USING vbak vbap.

  et_items =
    SELECT
      vbak.vbeln,
      vbap.posnr,
      vbap.matnr,
      vbap.netwr
      FROM vbak
      INNER JOIN vbap
        ON vbak.vbeln = vbap.vbeln
     WHERE vbak.vbeln = :iv_vbeln;

ENDMETHOD.

O join inteiro roda no HANA e só o resultado final volta para o ABAP. Esse é o tipo de cenário — alto volume, junção de tabelas, agregação — em que AMDP justifica sua complexidade.

O que você NÃO pode fazer dentro de uma AMDP

Como o corpo do método roda no banco, e não no servidor de aplicação, há uma fronteira que não dá para cruzar: dentro do SQLScript você não consegue chamar function modules, classes ABAP nem BAPIs. Nada de CALL FUNCTION ou NEW de classe ABAP ali dentro.

Isso é um recurso, não um limite frustrante: ele te força a separar o que é processamento de dados (vai para a AMDP) do que é regra de negócio (fica em ABAP). Se a lógica precisa de um function module ou de contexto da sessão ABAP, ela simplesmente não pertence à AMDP.

Quando vale a pena usar AMDP?

Para um iniciante, a tentação é usar AMDP em tudo — resista. Ela é uma ferramenta de nicho, para pontos específicos de performance e consultas complexas. Os cenários que realmente justificam:

• Joins complexos e agregações em alto volume de dados.

• Recursos específicos de HANA e SQLScript (funções analíticas, window functions).

• Substituir loops ABAP com vários acessos ao banco por uma única operação set-based.

E quando não usar: se Open SQL ou CDS já resolvem bem, fique com eles. São mais simples, mais legíveis e não te prendem ao HANA. Criar uma AMDP para uma consulta trivial é complexidade sem retorno.

E as table functions, scalar functions e virtual elements?

AMDP não para na procedure. Ela também pode ser exposta como table function (consumível em SELECT e CDS), como scalar function (devolve um valor único) ou aparecer ao lado de virtual elements. Cada formato tem seu trade-off de performance — mas isso já é o próximo passo, depois que a procedure fizer sentido na sua cabeça.

Perguntas frequentes

Preciso saber SQLScript para usar AMDP?

Para chamar uma AMDP existente, não — é uma chamada de método ABAP normal. Para escrever uma, você precisa de SQLScript básico, que é bem próximo do SQL padrão (SELECT, JOIN, GROUP BY). Comece por procedures de leitura simples e evolua a partir daí.

Por que minha classe AMDP não ativa?

Os erros mais comuns de iniciante: esquecer a interface IF_AMDP_MARKER_HDB, não usar VALUE(...) nos parâmetros, ou não listar uma tabela na cláusula USING. Confira esses três pontos primeiro — eles resolvem a maioria das falhas de ativação.

Posso fazer INSERT ou UPDATE dentro de uma AMDP?

Numa procedure, sim — basta não usar OPTIONS READ-ONLY. Mas, como iniciante, comece só com leitura: é mais seguro e cobre a maioria dos casos. Para escrita em cenários RAP, prefira a camada de comportamento (behavior) em vez de gravar direto pela AMDP.

AMDP funciona em qualquer banco de dados?

Não. A AMDP FOR HDB é específica do SAP HANA e usa SQLScript. Esse acoplamento é uma das razões para reservá-la a casos de ganho claro. Quando a portabilidade importa, fique em Open SQL e CDS, que são agnósticos de banco.

Qual a diferença entre AMDP procedure e table function?

A procedure é chamada como método ABAP e devolve dados por parâmetros — é um "motor" interno. A table function é consumida dentro de um SELECT ou CDS, como uma fonte de dados reutilizável. Para o primeiro contato, a procedure é o caminho mais natural.

Conclusão

AMDP parece intimidante de longe, mas de perto é só um método de classe ABAP com um corpo em SQLScript. Você implementa a interface marker, escreve a procedure, e chama do seu código como qualquer outro método. O resto é disciplina: deixe a regra de negócio em ABAP, concentre o SQLScript em classes de acesso a dados e use AMDP só onde o HANA realmente faz diferença.

Comece pequeno — uma procedure de leitura, chamada de um relatório. Quando isso ficar natural, envolva-a numa classe de serviço e, depois, explore table functions e os outros sabores. A primeira AMDP é o passo mais difícil; o resto é repetição.

Referências oficiais

• ABAP Managed Database Procedures (AMDP) — ABAP Keyword Documentation

• CDS Table Functions — SAP Help (ABAP Data Models)