Como usar BAPI no RAP, BO Interface e APIs Standard no ABAP Cloud

Quem fez ABAP nos últimos vinte anos tem o reflexo: precisou criar ou mudar um documento? Chama a BAPI. BAPI_PR_CREATE, BAPI_PO_CHANGE, BAPI_GOODSMVT_CREATE... a gente sabe de cor.

Só que no ABAP Cloud (o tal do strict mode, ou idioma restringido) esse reflexo trava: você digita a BAPI, dá um check e o editor reclama. A maioria delas não é released para o mundo cloud, e acabou.

Então surge a pergunta que traz você até aqui: como usar BAPI no RAP? A resposta curta é que você não usa a BAPI clássica, você usa o sucessor moderno dela. A SAP não inventou "uma BAPI nova"; ela mudou o jeito de consumir o standard e deixou uma ordem de prioridade clara para você seguir

Cadê as BAPIs no mundo Clean Core?

No ABAP Cloud, a maioria das BAPIs clássicas simplesmente não é released e não compila em strict mode. A SAP não criou uma "BAPI nova": ela definiu uma ordem de prioridade para consumir o standard, começando pelo BO Interface. É essa ordem que responde, na prática, à pergunta "o que uso no lugar da BAPI?".

A lógica é só uma: comece pelo topo e só desça quando o de cima não existir para o seu caso. Bônus: quando alguém perguntar por que você escolheu tal caminho, você consegue justificar o que avaliou antes.

(E se você é do time funcional e não escreve ABAP: tem um recado pra você lá no fim — porque essa decisão começa na sua especificação, não no código.)

A pergunta que vem antes: dentro ou fora do SAP?

Antes de escolher o objeto, uma pergunta resolve metade da conversa: o código que vai consumir o SAP roda dentro do S/4 ou fora dele? Dentro, a ferramenta certa é o BO Interface, chamado por EML na mesma transação. Fora, o BO Interface não serve (ele não é exposto como serviço remoto) e o caminho é API. Sempre.

Dentro do SAP. Você está escrevendo ABAP Cloud que vive no próprio S/4: um app Fiori on-stack, uma action de RAP, um job, uma rotina automática. Pensa num app de gestão de rotas de transporte, ou no app de vendas que estamos tocando aqui. Nesses casos, o BO Interface é a ferramenta certa. Você chama ele por EML, dentro da mesma transação, com tipagem forte e as validações do framework te cobrindo.

Fora do SAP. Aqui quem consome é outro: um sistema legado puxando dados, uma aplicação CAP, um app rodando na BTP, uma integração passando pelo CPI, um parceiro lá fora. O BO Interface não te ajuda nesse cenário, simplesmente porque ele não é exposto como serviço remoto. Aliás, o BO Interface nada mais é que o centro da lógica da maioria das APIs Standard, já que boa parte delas é construída em cima dele. Para esse mundo, o caminho é API.

Resumindo sem enrolação: está dentro do SAP, pensa em BO Interface; está fora, é API. Os níveis 1, 2 e 3 que vêm a seguir assumem que você está on-stack. Se o consumo é externo, você já entra direto no mundo das APIs.

Casos de uso e o objeto certo

Onde achar tudo isso: SAP Business Accelerator

Praticamente toda dúvida de "isso existe? posso usar?" mora num lugar só: o SAP Business Accelerator Hub (hub.sap.com), o catálogo oficial da SAP para API, BO Interface, CDS View, Event, BAdI e Adapter. A regra é direta: se o objeto não aparece ali como released, ele não entra no seu código cloud.

SAP Business Accelerator Hub

Lá dentro, em Explore Categories, estão justamente os tipos que este post discute. Os números mudam a cada release, mas servem para dar a escala da coisa:

Macete de navegação: filtre pelo produto (S/4HANA Cloud Public ou Private Edition) e entre na aba Developer Extensibility. É ali que ficam os objetos liberados para você escrever ABAP Cloud.

Nível 1 — BO Interface: a primeira escolha

O que é

Um BO Interface (Business Object Interface) é, na real, um Business Object de RAP que a SAP liberou para você chamar do seu código. Em vez de uma função cheia de estruturas antigas, você conversa com ele por EML, o mesmo MODIFY ENTITIES / READ ENTITIES de qualquer BO seu.

O exemplo clássico é a requisição de compra: o I_PurchaseRequisitionTP é o BO Interface released que entra no lugar de BAPI_PR_CREATE / _CHANGE / _DELETE.

Como usar BO Interface? (Nível 1, a primeira escolha)

Para usar um BO Interface você o chama por EML (MODIFY ENTITIES / READ ENTITIES), exatamente como faria com um Business Object seu, e finaliza com COMMIT ENTITIES. Um BO Interface é um Business Object de RAP que a SAP liberou para consumo: ele é o sucessor direto da BAPI (ex.: I_PurchaseRequisitionTP no lugar de BAPI_PR_CREATE), com tipagem forte e as validações do framework no lugar das velhas estruturas.

O exemplo clássico é a requisição de compra: o I_PurchaseRequisitionTP é o BO Interface released que entra no lugar de BAPI_PR_CREATE / _CHANGE / _DELETE.

A lista cresce a cada release, então não decore: confira o successor atual antes de sair codando.

Como criar um documento via EML (código)

Veja como criar uma requisição de compra (cabeçalho + item) consumindo o BO Interface released. É o mesmo EML de qualquer BO de RAP:

" Criar uma requisição de compra pelo BO Interface released I_PurchaseRequisitionTP
MODIFY ENTITIES OF i_purchaserequisitiontp
  ENTITY PurchaseRequisition
    CREATE
      FIELDS ( PurchaseRequisitionType )
      WITH VALUE #( ( %cid = 'PR1'
                      PurchaseRequisitionType = 'NB' ) )
    " cria o item filho POR ASSOCIAÇÃO a partir do cabeçalho
    CREATE BY \_PurchaseReqnItem
      FIELDS ( PurchaseRequisitionItem Plant Material RequestedQuantity )
      WITH VALUE #( ( %cid_ref = 'PR1'
                      %target  = VALUE #(
                        ( %cid                    = 'ITEM1'
                          PurchaseRequisitionItem = '10'
                          Plant                   = '1010'
                          Material                = 'TG11'
                          RequestedQuantity       = '5' ) ) ) )
  MAPPED   DATA(ls_mapped)
  FAILED   DATA(ls_failed)
  REPORTED DATA(ls_reported).

" Só faz o commit se não houve falha
IF ls_failed IS INITIAL.
  COMMIT ENTITIES
    RESPONSE OF i_purchaserequisitiontp
    FAILED   DATA(ls_commit_failed)
    REPORTED DATA(ls_commit_reported).

  " late numbering: o número gerado volta em ls_mapped
  " DATA(lv_pr_number) = ls_mapped-purchaserequisition[ 1 ]-PurchaseRequisition.
ENDIF.

Os nomes de campo e o nome da associação (_PurchaseReqnItem) você confirma na ficha do objeto no api.sap.com, na seção de estrutura/Schema. Não chute: cada BO tem o seu.

E para apenas ler, o READ ENTITIES segue a mesma linha:

READ ENTITIES OF i_purchaserequisitiontp
  ENTITY PurchaseRequisition
    FIELDS ( PurchaseRequisition PurchaseRequisitionType )
    WITH VALUE #( ( PurchaseRequisition = '0010000042' ) )
  RESULT DATA(lt_pr).

Quando usar BO Interface

Vai de BO Interface quando:

• você está codando algo que roda dentro do próprio S/4 (app Fiori, action de RAP, job, automação) e precisa criar, alterar ou apagar um documento standard;

• está no ABAP Cloud e a BAPI que você usaria não é released;

• quer tipagem forte, side effects e validações do framework, em vez de ficar adivinhando o que cada estrutura da BAPI espera.

Só não esqueça do detalhe da seção anterior: BO Interface é coisa de quem está dentro do SAP. Se quem consome está fora, ele não serve, e aí caímos na API.

Quando usar

Vai de BO Interface quando:

• você está codando algo que roda dentro do próprio S/4 (app Fiori, action de RAP, job, automação) e precisa criar, alterar ou apagar um documento standard.

• está no ABAP Cloud e a BAPI que você usaria não é released;

• quer tipagem forte, side effects e validações do framework, em vez de ficar adivinhando o que cada estrutura da BAPI espera.

Só não esqueça do detalhe da seção anterior: BO Interface é coisa de quem está dentro do SAP. Se quem consome está fora, ele não serve, e aí caímos na API.

Como descobrir se existe um BO Interface

Tem dois caminhos. O primeiro é o hub.sap.com: produto → aba Developer Extensibility → categoria Business Object Interfaces → busca o objeto. A ficha já vem com ID, status de release e exemplos de código prontos.

O segundo é o Cloudification Repository Viewer (app no Launchpad): joga a BAPI/FM antiga e olha os campos API State e Successors. Se aparecer "Not to be Released" com um Behavior Definition no successor, achou o seu BO Interface.

E, se preferir ir direto pelo Eclipse, abra a BAPI, botão direito, Properties, e confira o API State ali mesmo.

Obs: repare que esse BO é marcado como extensível, ou seja, se precisa adicionar uma regra específica, podemos fazer isso extendendo a lógica, para o passo-a-passo veja os detalhes aqui em: Extendendo a lógica de um BO Interface

Como usar uma API standard? (Nível 2, APIs released)

Quando o cenário é leitura/consulta ou o consumo vem de fora do S/4, o caminho é uma API standard já released: você lê dados por uma CDS view released, consome uma API OData publicada no Hub, ou chama uma BAPI/Function Module released (C1). A pergunta-chave é sempre a mesma: isso é released? Você responde olhando o API State no ADT ou a ficha no api.sap.com.

Os objetos standard já liberados se dividem em:

• CDS views released, para ler dados de forma cloud-safe (em vez do SELECT direto em tabela standard, que o strict mode não deixa);

• APIs OData publicadas no Hub, para integração e consumo, inclusive de fora do S/4 (ex.: API_PURCHASEREQUISITION_2);

• BAPIs / Function Modules released (C1), porque algumas funções são liberadas para uso direto em ABAP Cloud. Dá para checar isso na propriedade do objeto no ADT.

Como ler dados standard on-stack (código)

Dentro do S/4, troque o SELECT em tabela standard por uma CDS view released. É cloud-safe e atravessa upgrade:

" Leitura cloud-safe via CDS view released (NÃO faça SELECT direto em tabela standard)
SELECT FROM i_purchaserequisition
  FIELDS PurchaseRequisition,
         PurchaseRequisitionType,
         CreationDate
  WHERE  CreationDate = @cl_abap_context_info=>get_system_date( )
  INTO TABLE @DATA(lt_prs).

Esse nível é o seu caminho quando o cenário é leitura/consulta (CDS/OData) ou quando existe uma função released que faz exatamente o que você precisa sem ser um BO transacional.

Como ler a página de uma API no Sap Business Accelerator

Toda API no Hub segue o mesmo layout. Sabendo bater o olho nessa página, você não precisa abrir PDF nenhum:

Caso queira aprender a testar e validar uma API confira também: Como testar API Standart

Na prática, o Schema View é onde você descobre nome de campo e navegação sem ficar chutando, e o Try Out deixa você testar o payload no navegador antes de escrever uma linha de código. (Consumir essa API de um sistema externo ou do CPI rende um post à parte — fica para a próxima.)

Como chamar o wrapper no código cloud (código)

Depois de gerar e liberar o wrapper, o consumo a partir do ABAP Cloud fica assim:

" Chamando a BAPI clássica POR MEIO do wrapper gerado pela ACO_PROXY
" (nunca chame a BAPI diretamente do código cloud)
DATA(lo_pr_proxy) = cl_pr_create_proxy_factory=>create( ).

lo_pr_proxy->bapi_pr_create(
  EXPORTING
    is_prheader = ls_header
    it_pritem   = lt_items
  IMPORTING
    ev_number   = DATA(lv_pr_number)
    et_return   = DATA(lt_return) ).

" Trate lt_return e dispare o COMMIT pelo próprio wrapper
IF NOT line_exists( lt_return[ type = 'E' ] ).
  lo_pr_proxy->bapi_transaction_commit( wait = abap_true ).
ENDIF.

Só encare o wrapper como dívida técnica: no dia em que sair um BO Interface ou uma API equivalente, troca.

Quer o passo a passo? Montar esse wrapper com a ACO_PROXY (pré-requisitos, as opções certas — Class-Based Exceptions, C1 Release, destination via construtor —, o caso de Function Module não-RFC e o código de consumo) rende um tutorial inteiro. Escrevi isso em detalhe aqui: Gerando um wrapper de BAPI com ACO_PROXY para o ABAP Cloud

Decisão rápida

Juntando tudo num fluxo só:

Lendo um BO Interface no Hub: o caso do Sales Order

Para fechar a parte do BO Interface, vale ver como um deles aparece no hub.sap.com. Peguei o I_SalesOrderTP (Sales Order), porque é o coração do nosso cenário de vendas.

A primeira coisa que eu olho é a ficha (General Information):

Tradução do quadro: dá para usar em Developer Extensibility (ABAP Cloud), mas não em Key User. Esse par de status é sempre o meu primeiro check em qualquer objeto do Hub.

Depois vem a estrutura. O BO é uma árvore: um nó raiz com operações próprias, e composições-filhas que só nascem através do pai.

Duas coisas que essa página já te ensina sem código nenhum: o cabeçalho você cria sozinho, mas todo nó-filho (item, partner, text...) só vem por associação a partir do pai. E, se for só leitura, a própria SAP recomenda não usar o BO — usa a CDS view I_SalesOrder, feita para isso e com performance melhor. O BO entra quando tem criação ou alteração no meio.

Funcional, isso aqui é com você também

Esse papo não é só de dev. Na real, as melhores decisões de Clean Core nascem antes do código: nascem na EF, na sua mão.

Quantas vezes a regra de negócio da especificação chega com um "utilizar a BAPI_XXX para criar o documento"? Fazia todo sentido no ECC. Só que hoje, no S/4HANA Cloud, isso pode chegar pro desenvolvedor: a BAPI não é released, não compila, e começa o vai-e-volta — "essa BAPI não dá", "então me arruma outra" — e o GAP atrasa.

A virada é simples e não exige que você saiba ABAP: em vez de cravar uma BAPI, aponte para o objeto released na especificação, dê uma busca lá você mesmo no hub, ache o objeto (ex.: o BO Interface I_SalesOrderTP), confirma que está released e referencia o ID na DF/EF.

Por que isso eleva o nível da especificação:

• O dev já começa apontado para um objeto cloud-ready, sem caça ao tesouro e sem "isso não compila".

• Clean Core entra na origem: menos nível C/D, menos dívida técnica, aprovação de arquitetura mais tranquila.

• A conversa fica mais precisa: você passa a falar em "BO Interface de Sales Order" em vez de "a BAPI de pedido", e isso aproxima funcional e técnico.

• Estimativa e prazo melhoram, porque some uma rodada inteira de retrabalho.

Não é virar programador. É aprender a navegar o api.sap.com: achar o objeto, ver se é released, copiar o ID. Esse pequeno passo na sua spec economiza dias do outro lado do balcão.

Pra fechar

No fim das contas, "BAPI nova" é só um jeito de falar. O que mudou foi o modelo de consumo: dentro do SAP, BO Interface; quando não tem BO, API released (CDS, OData, FM); e, só em último caso, o wrapper via ACO_PROXY, sempre liberado para cloud e sempre tratado como temporário. E o ponto de partida segue o mesmo de sempre, o hub.sap.com, onde você descobre se o objeto existe e em que estado de release ele está. Indo por essa linha, seu código atravessa upgrade sem susto e fica de bem com o Clean Core.

E vale para os dois lados do balcão: o dev que escolhe o objeto certo e o funcional que já aponta esse objeto na especificação estão, juntos, fazendo Clean Core de verdade — um antes do código, o outro dentro dele.

Referências

• SAP Business Accelerator Hub — https://hub.sap.com (APIs, BO Interfaces, CDS Views, Events, BAdIs)

• BO Interface Sales Order (I_SALESORDERTP) — api.sap.com → Developer Extensibility → Business Object Interfaces

• Tutorial: Develop an SAP Fiori App to Trigger Purchase Requisitions API — developers.sap.com

• Blog SAP: How to generate a wrapper for function modules (BAPIs) for missing released SAP APIs — community.sap.com

• Blog SAP: How to Save a Lot of Time With the ABAP Connector (Transaction ACO_PROXY) — community.sap.com