Files

Bruno OS 254cf6f6fc docs: create SAP/EXPORT_IMPORT_ABAP_table

2026-08-12 12:10:42 +00:00

17 KiB

Raw Blame History

title, description, published, date, tags, editor, dateCreated

title	description	published	date	tags	editor	dateCreated
EXPORT IMPORT em ABAP	Teoria, exemplos e persistência em banco com TO/FROM DATABASE	true	2026-08-12T12:10:37.961Z		markdown	2026-08-12T12:10:37.961Z

EXPORT e IMPORT em ABAP

Teoria, exemplos e persistência em banco com `TO/FROM DATABASE`

1. Visão geral

Em ABAP, as instruções EXPORT e IMPORT permitem salvar e recuperar um conjunto de objetos ABAP como um data cluster.

Um data cluster é uma representação serializada de variáveis, estruturas ou tabelas internas. O SAP grava os dados em um formato técnico e, no momento do IMPORT, reconstrói os objetos ABAP originais.

Exemplo conceitual:

Tabela interna ABAP
        |
        | EXPORT
        v
Dados serializados (data cluster)
        |
        | IMPORT
        v
Tabela interna ABAP novamente

O mesmo mecanismo pode utilizar diferentes meios de armazenamento:

Meio	Sintaxe	Uso principal
Memória ABAP	`TO/FROM MEMORY`	Compartilhar dados entre programas na mesma sessão interna
Banco de dados	`TO/FROM DATABASE`	Persistir dados em uma tabela de export/import, como `INDX`
Buffer compartilhado	`TO/FROM SHARED BUFFER`	Compartilhar dados pelo buffer do servidor de aplicação
Buffer binário	`TO/FROM DATA BUFFER`	Serializar dados em uma variável `XSTRING`
Arquivo	`TO/FROM DATASET`	Variante antiga para arquivos; normalmente prefere-se `OPEN DATASET`

Este documento concentra-se em TO/FROM DATABASE, especialmente no uso da tabela INDX.

2. O que significa `TO/FROM DATABASE`

Quando se usa:

EXPORT ... TO DATABASE indx(z1) ID 'CHAVE_001'.

o ABAP não grava as colunas da estrutura diretamente como colunas de negócio. Ele serializa as variáveis e grava o resultado em uma tabela de export/import.

A leitura é feita assim:

IMPORT ... FROM DATABASE indx(z1) ID 'CHAVE_001'.

O sistema localiza o cluster usando a tabela, a área e o identificador. Depois, desserializa o conteúdo e preenche as variáveis informadas no IMPORT.

2.1 Estrutura da sintaxe

EXPORT objeto_1 = variavel_1
       objeto_2 = variavel_2
       TO DATABASE tabela_export_import(area)
       ID identificador.

IMPORT objeto_1 = variavel_1
       objeto_2 = variavel_2
       FROM DATABASE tabela_export_import(area)
       ID identificador.

Os elementos principais são:

Elemento	Descrição
`tabela_export_import`	Tabela de banco compatível com armazenamento de clusters, normalmente `INDX` ou uma tabela `Z` apropriada
`area`	Área de dois caracteres, também conhecida como `RELID`; funciona como uma categoria de armazenamento
`ID`	Chave lógica do cluster; identifica o conjunto de dados salvo
`objeto_1`	Nome lógico usado dentro do cluster
`variavel_1`	Variável ABAP cujo conteúdo será gravado ou preenchido

O nome lógico e a variável podem ter nomes diferentes:

EXPORT dados_materiais = lt_mara
       TO DATABASE indx(z1)
       ID 'MARA_001'.

Na leitura:

IMPORT dados_materiais = lt_mara
       FROM DATABASE indx(z1)
       ID 'MARA_001'.

3. A tabela `INDX`

INDX é uma tabela técnica utilizada pelo SAP para armazenar dados exportados/importados. Ela não possui, normalmente, colunas de negócio como MATNR, WERKS ou MENGE.

O conteúdo do cluster é armazenado de forma serializada em campos técnicos. Dependendo da versão do SAP e do banco de dados, podem aparecer campos como:

MANDT: cliente SAP;
RELID: área do cluster;
SRTFD, SRTF2 e outros campos técnicos de chave;
CLUSTR e/ou CLUSTD: conteúdo serializado do cluster.

Por isso, um SELECT direto na INDX não devolve a tabela interna original em formato legível:

SELECT * FROM indx INTO TABLE @DATA(lt_indx).

Esse SELECT retorna os registros técnicos e o conteúdo serializado. Para reconstruir os objetos, deve-se usar IMPORT.

Não se deve tentar interpretar ou alterar manualmente os campos serializados do cluster por SQL. A leitura deve ser feita com IMPORT, usando a mesma tabela, área e chave utilizadas no EXPORT.

4. Exemplo completo: exportar uma tabela interna para `INDX`

O exemplo abaixo seleciona materiais, grava a tabela interna em INDX e depois a recupera.

4.1 Programa de gravação

REPORT z_export_mara_indx.

DATA lt_mara TYPE STANDARD TABLE OF mara.

SELECT *
  FROM mara
  INTO TABLE @lt_mara
  UP TO 100 ROWS.

IF sy-subrc <> 0.
  MESSAGE 'Nenhum material encontrado' TYPE 'I'.
  RETURN.
ENDIF.

EXPORT dados_materiais = lt_mara
       TO DATABASE indx(z1)
       ID 'MARA_001'.

IF sy-subrc = 0.
  COMMIT WORK AND WAIT.
  MESSAGE 'Cluster gravado com sucesso' TYPE 'S'.
ELSE.
  ROLLBACK WORK.
  MESSAGE 'Erro ao gravar o cluster' TYPE 'E'.
ENDIF.

4.2 Programa de leitura

REPORT z_import_mara_indx.

DATA lt_mara TYPE STANDARD TABLE OF mara.

IMPORT dados_materiais = lt_mara
       FROM DATABASE indx(z1)
       ID 'MARA_001'.

IF sy-subrc <> 0.
  MESSAGE 'Cluster não encontrado ou inválido' TYPE 'I'.
  RETURN.
ENDIF.

LOOP AT lt_mara INTO DATA(ls_mara).
  WRITE: / ls_mara-matnr,
           ls_mara-mtart,
           ls_mara-mbrsh.
ENDLOOP.

4.3 O que acontece nesse fluxo

lt_mara é preenchida com dados da tabela MARA.
EXPORT serializa a tabela interna.
O cluster é identificado pela combinação da tabela, área Z1 e ID MARA_001.
O banco recebe o registro técnico na INDX.
COMMIT WORK confirma a alteração da unidade lógica de trabalho.
O segundo programa executa IMPORT usando a mesma identificação.
O conteúdo é reconstruído em lt_mara.

5. Exportar várias variáveis no mesmo cluster

É possível armazenar uma tabela interna, uma estrutura e variáveis simples no mesmo cluster.

DATA: lt_mara  TYPE STANDARD TABLE OF mara,
      lv_datum TYPE sydatum,
      lv_user  TYPE syuname,
      lv_total TYPE i.

lv_datum = sy-datum.
lv_user  = sy-uname.
lv_total = lines( lt_mara ).

EXPORT dados_materiais = lt_mara
       data_execucao   = lv_datum
       usuario         = lv_user
       quantidade      = lv_total
       TO DATABASE indx(z1)
       ID 'MARA_001'.

COMMIT WORK AND WAIT.

A recuperação precisa solicitar os mesmos nomes lógicos:

IMPORT dados_materiais = lt_mara
       data_execucao   = lv_datum
       usuario         = lv_user
       quantidade      = lv_total
       FROM DATABASE indx(z1)
       ID 'MARA_001'.

Se o programa importar somente alguns objetos, os demais não serão preenchidos. Por exemplo:

IMPORT dados_materiais = lt_mara
       FROM DATABASE indx(z1)
       ID 'MARA_001'.

Nesse caso, apenas lt_mara será recuperada.

6. Como escolher a área e o ID

A área e o ID formam parte da identificação do cluster.

EXPORT dados = lt_data
       TO DATABASE indx(z1)
       ID 'PEDIDO_000001'.

Uma estratégia simples é:

Campo	Exemplo	Finalidade
Área	`Z1`	Separar a finalidade ou aplicação
ID	`PEDIDO_000001`	Identificar o registro lógico

Exemplos de IDs:

ID 'ZRELATORIO_20260811'.
ID 'PEDIDO_000001'.
ID lv_id.

Boas práticas:

usar uma área reservada para o desenvolvimento, como Z1 ou Z2;
usar um prefixo da aplicação, como ZFI_, ZMM_ ou ZPP_;
garantir que o ID seja único para o conjunto de dados;
documentar o formato do ID;
não reutilizar o mesmo ID para estruturas incompatíveis;
considerar o cliente SAP (MANDT) quando o desenho da aplicação depender de dados separados por cliente.

Se o mesmo ID for exportado novamente, o conteúdo anterior será substituído na mesma identificação lógica.

7. Verificar se o cluster existe

A forma mais simples é testar sy-subrc após o IMPORT:

IMPORT dados = lt_data
       FROM DATABASE indx(z1)
       ID 'PEDIDO_000001'.

CASE sy-subrc.
  WHEN 0.
    WRITE: / 'Cluster importado com sucesso'.
  WHEN OTHERS.
    WRITE: / 'Cluster não encontrado ou não compatível'.
ENDCASE.

Em código de produção, também é recomendável:

limpar as variáveis antes do IMPORT;
validar se a tabela interna foi preenchida;
tratar a ausência do cluster;
garantir compatibilidade entre a estrutura usada no EXPORT e no IMPORT.

Exemplo:

CLEAR lt_data.

IMPORT dados = lt_data
       FROM DATABASE indx(z1)
       ID lv_id.

IF sy-subrc <> 0 OR lt_data IS INITIAL.
  "Tratar cluster ausente ou sem dados
  RETURN.
ENDIF.

8. Excluir dados gravados

Para remover um cluster específico:

DELETE FROM DATABASE indx(z1)
       ID 'MARA_001'.

IF sy-subrc = 0.
  COMMIT WORK AND WAIT.
ENDIF.

A exclusão deve utilizar a mesma tabela, área e identificação do EXPORT.

Não se deve usar um DELETE SQL genérico na INDX sem conhecer exatamente a chave técnica e as regras da aplicação. O comando ABAP específico é mais seguro para excluir o cluster lógico.

9. Consultar o conteúdo lógico com `IMPORT DIRECTORY`

Quando não se conhece quais objetos foram armazenados, pode-se consultar o diretório do cluster.

DATA lt_directory TYPE STANDARD TABLE OF cdir.

IMPORT DIRECTORY INTO lt_directory
       FROM DATABASE indx(z1)
       ID 'MARA_001'.

LOOP AT lt_directory INTO DATA(ls_directory).
  WRITE: / ls_directory-name.
ENDLOOP.

O diretório informa os objetos armazenados, mas não substitui o IMPORT dos valores. Para recuperar os dados, é necessário conhecer os nomes e os tipos esperados.

10. Compatibilidade entre `EXPORT` e `IMPORT`

O programa que importa precisa conhecer os tipos dos dados exportados.

Exemplo correto:

TYPES tt_data TYPE STANDARD TABLE OF mara WITH EMPTY KEY.

DATA lt_data TYPE tt_data.

IMPORT dados = lt_data
       FROM DATABASE indx(z1)
       ID 'MARA_001'.

Cuidados importantes:

não alterar a estrutura sem planejar compatibilidade;
evitar importar um cluster antigo para uma estrutura completamente diferente;
versionar o conteúdo quando a estrutura puder mudar;
usar um campo de versão dentro do cluster.

Exemplo com versão:

DATA: lv_versao TYPE i VALUE 1,
      lt_data   TYPE STANDARD TABLE OF mara.

EXPORT versao = lv_versao
       dados   = lt_data
       TO DATABASE indx(z1)
       ID 'MARA_001'.

Na leitura:

DATA: lv_versao TYPE i,
      lt_data   TYPE STANDARD TABLE OF mara.

IMPORT versao = lv_versao
       dados   = lt_data
       FROM DATABASE indx(z1)
       ID 'MARA_001'.

IF sy-subrc = 0 AND lv_versao = 1.
  "Processar versão conhecida
ELSE.
  "Tratar versão incompatível
ENDIF.

11. `COMMIT WORK` e unidade lógica de trabalho

O EXPORT TO DATABASE participa da unidade lógica de trabalho do programa. Em um fluxo que precisa garantir a persistência, confirme a alteração:

EXPORT dados = lt_data
       TO DATABASE indx(z1)
       ID lv_id.

IF sy-subrc = 0.
  COMMIT WORK AND WAIT.
ELSE.
  ROLLBACK WORK.
ENDIF.

Em uma aplicação real, o momento do COMMIT WORK deve respeitar o controle transacional do processo. Evite executar COMMIT WORK dentro de uma classe ou função que não seja responsável pela transação inteira, pois isso pode confirmar outras alterações pendentes.

12. Controle de concorrência

Dois processos podem tentar gravar o mesmo ID ao mesmo tempo. Para evitar sobrescrita ou inconsistência:

defina IDs realmente únicos;
use bloqueios lógicos quando houver atualização concorrente;
não permita que dois processos reutilizem o mesmo ID sem coordenação;
grave também usuário, data e versão quando for necessário rastreamento.

O cluster não substitui uma tabela de negócio com chave, histórico, índices e controle de atualização.

13. Tabela `INDX` não é uma tabela de negócio

A INDX deve ser tratada como armazenamento técnico de objetos serializados. Ela não é adequada para:

consultas SQL por campos internos do objeto;
joins com tabelas de negócio;
relatórios analíticos;
filtros por campos como material, centro ou fornecedor;
atualização parcial de uma coluna;
integração externa que espera dados relacionais.

Se for necessário consultar MATNR, WERKS ou outro campo diretamente no banco, o melhor desenho é uma tabela transparente com colunas próprias.

14. Diferença entre `INDX` e uma tabela Cluster do DDIC

Os termos são parecidos, mas representam situações diferentes:

`EXPORT TO DATABASE INDX(...)`

Grava um data cluster ABAP serializado em uma tabela de export/import, como INDX.

Tabela Cluster do Dicionário ABAP

É um tipo antigo de tabela DDIC em que várias tabelas lógicas podiam ser armazenadas de forma agrupada em uma tabela física.

Portanto, usar EXPORT TO DATABASE não significa exportar diretamente uma tabela de negócio cluster. Significa armazenar um conjunto de variáveis ABAP serializadas.

15. Quando usar e quando não usar

Pode fazer sentido usar quando:

é necessário guardar temporariamente um conjunto de dados ABAP;
um processo posterior, controlado pela mesma aplicação, fará o IMPORT;
os dados não precisam ser consultados por SQL;
a estrutura dos dados é conhecida pelo programa consumidor;
há necessidade de preservar uma tabela interna entre etapas de processamento.

Deve ser evitado quando:

os dados são mestres ou transacionais;
outros sistemas precisam consumir os dados;
é necessário consultar ou filtrar os campos no banco;
é necessário fazer join ou criar relatórios;
a estrutura muda frequentemente;
o volume é grande e precisa de controle de retenção;
uma tabela transparente ou uma solução de persistência orientada a objetos atende melhor.

Para novos desenvolvimentos, normalmente são preferíveis tabelas transparentes Z, classes de persistência e formatos de integração como JSON, XML ou APIs.

16. Exemplo de classe utilitária

Um uso mais organizado é encapsular o acesso em uma classe.

CLASS zcl_cluster_storage DEFINITION
  PUBLIC FINAL CREATE PUBLIC.

  PUBLIC SECTION.
    CLASS-METHODS save
      IMPORTING
        iv_id   TYPE char30
        it_data TYPE STANDARD TABLE.

    CLASS-METHODS load
      IMPORTING
        iv_id TYPE char30
      EXPORTING
        et_data TYPE STANDARD TABLE.
ENDCLASS.

O exemplo acima é apenas ilustrativo: em ABAP, para garantir tipagem forte, normalmente deve-se definir um tipo de tabela específico, em vez de usar STANDARD TABLE genérico.

Uma implementação tipada seria mais segura:

CLASS zcl_mara_cluster DEFINITION
  PUBLIC FINAL CREATE PUBLIC.

  PUBLIC SECTION.
    TYPES tt_mara TYPE STANDARD TABLE OF mara WITH EMPTY KEY.

    CLASS-METHODS save
      IMPORTING
        iv_id   TYPE char30
        it_mara TYPE tt_mara.

    CLASS-METHODS load
      IMPORTING
        iv_id   TYPE char30
      RETURNING
        VALUE(rt_mara) TYPE tt_mara.
ENDCLASS.

Implementação:

CLASS zcl_mara_cluster IMPLEMENTATION.

  METHOD save.
    EXPORT dados = it_mara
           TO DATABASE indx(z1)
           ID iv_id.

    IF sy-subrc <> 0.
      RAISE EXCEPTION TYPE cx_sy_import_mismatch_error.
    ENDIF.
  ENDMETHOD.

  METHOD load.
    IMPORT dados = rt_mara
           FROM DATABASE indx(z1)
           ID iv_id.
  ENDMETHOD.

ENDCLASS.

Em um desenvolvimento real, é melhor definir exceções próprias e tratar explicitamente ausência, incompatibilidade e falha de persistência.

17. Checklist de implementação

Antes de usar EXPORT TO DATABASE, verifique:

A tabela utilizada é compatível com export/import?
A área possui dois caracteres e está documentada?
O ID é único e possui uma regra clara?
O mesmo nome lógico será usado no IMPORT?
Os tipos do EXPORT e do IMPORT são compatíveis?
O processo controla sy-subrc?
O COMMIT WORK está no ponto correto da transação?
Existe tratamento para dados antigos ou estrutura versionada?
Há controle contra concorrência e sobrescrita?
A solução realmente precisa de cluster ou uma tabela transparente seria melhor?
Existe rotina de limpeza para evitar acúmulo de registros?

18. Resumo final

O padrão básico é:

EXPORT dados = lt_data
       TO DATABASE indx(z1)
       ID 'CHAVE_001'.

COMMIT WORK AND WAIT.

Depois:

IMPORT dados = lt_data
       FROM DATABASE indx(z1)
       ID 'CHAVE_001'.

Para excluir:

DELETE FROM DATABASE indx(z1)
       ID 'CHAVE_001'.

COMMIT WORK AND WAIT.

A principal ideia é: EXPORT TO DATABASE persiste um cluster serializado, e IMPORT FROM DATABASE reconstrói os objetos ABAP. A INDX é um armazenamento técnico; ela não deve ser tratada como uma tabela relacional de negócio.

17 KiB Raw Blame History