Como ativar uma API OData V2 standard no SAP
Antes de consumir, é preciso ativar
Tem hora que você precisa saber exatamente o que uma API standard da SAP devolve. O funcional quer validar se um serviço já entrega aquele dado antes de abrir um GAP. O dev precisa consumir a API e, quase sempre, descobre que não é só uma — tem as "vizinhas" que entram junto no processo. E nos dois casos a primeira pergunta é a mesma: "essa API está ativa no meu ambiente?"
Ativar uma API OData V2 standard no SAP é simples e leva poucos minutos. O que faz perder uma tarde são os detalhes — release, nome técnico vs. externo, alias de sistema. Este guia mostra o caminho completo, do Business Accelerator Hub até o status 200 no Gateway Client. O foco aqui é só ativar e dar o "ping" de confirmação; testar a fundo (entities, $filter, $expand, navegações) fica para o post Como testar uma API standard no SAP .
É de Public Cloud? Este passo a passo vale para On-Premise e S/4HANA Private Cloud, onde a ativação passa por /IWFND/MAINT_SERVICE. No S/4HANA Cloud Public Edition esse fluxo não existe — lá a exposição de serviços é feita via Communication Arrangements / Communication Scenarios.
Pré-requisitos: acesso ao Business Accelerator Hub (gratuito) e autorização para a transação /IWFND/MAINT_SERVICE no seu sistema.
Passo 1: Achar a API no Business Accelerator Hub
Entre no SAP Business Accelerator Hub e vá na aba APIs. No topo estão os filtros por protocolo: All, SOAP, ODATA V2, ODATA V4, Delta Sharing, GraphQL, REST e Policy Template. Comece em All para ver tudo; se já sabe que quer OData V2, filtre direto em ODATA V2 e corte o ruído.
Aba APIs — filtros por protocolo. Comece em All ou vá direto em ODATA V2.
A parte que faz diferença: busque em inglês e descreva o processo o mais claro possível. O catálogo é todo em inglês, então sales organization traz muito mais resultado do que "organização de vendas". Digite na caixa Find e compare os cards.
Busca em inglês na caixa Find. Repare nos selos dos cards.
Olhe os selos de cada card: ACTIVE é o que você quer; DEPRECATED é serviço em fim de vida — fuja, salvo motivo específico. No exemplo, seguimos com a Sales Organization - Read. (Entender as chamadas e as entities é assunto do outro post; aqui só precisamos do nome técnico.)
Passo 2: Conferir a release
Antes de sair ativando, confirme que a API existe na sua release. Na página da API use o seletor Select Release, escolha a release do seu ambiente (no exemplo, 2025 FPS00) e veja se ela aparece e como está documentada ali.
Seletor Select Release — confirme a disponibilidade na sua versão.
Entre uma release e outra a SAP adiciona, muda ou aposenta entities e campos. A API que existe num FPS pode não existir (ou se comportar diferente) em outro. Conferir aqui evita procurar no sistema um serviço que ainda não veio na sua versão.
Passo 3: O serviço já não está ativo? (/IWFND/MAINT_SERVICE)
Vá na transação /n/IWFND/MAINT_SERVICE (Ativar e atualizar serviços) — o catálogo de serviços OData do ambiente. Clique em Filtro e procure pelo nome técnico. Como nem sempre você lembra o nome exato, use curingas com os pedaços que conhece, algo como *API*SALES*ORG*.
Filtro do catálogo com curingas pelos pedaços do nome.
Resultado do filtro — se o serviço já aparece, pule para o Passo 6.
Se o serviço já estiver na lista, ele está no ar: vá direto ao Passo 6 para testar. Se não aparecer nada, siga em frente.
Passo 4: Adicionar o serviço
Ainda no catálogo, clique em Inserir serviço. Na tela de seleção, deixe o Alias do sistema como LOCAL e filtre de novo pelo nome (*API*SALES*ORG*). O sistema lista o serviço de back-end — no exemplo, o API_SALESORGANIZATION_SRV. Marque-o e clique em Inserir serviços selecionados.
Alias do sistema LOCAL + filtro pelo nome do serviço de back-end.
Marque o serviço e clique em Inserir serviços selecionados.
Na tela de confirmação, dois pontos importam:
Nome técnico vs. nome externo. O SAP cria o serviço no catálogo com Z na frente — vira ZAPI_SALESORGANIZATION_SRV. Esse é o nome para achar o serviço no catálogo e o que entra na sua especificação funcional. Mas o Nome do serviço externo continua API_SALESORGANIZATION_SRV — e é esse que vai na URL de chamada. Guarde a diferença; ela confunde muita gente.
Pacote. Atribua onde o desenvolvimento vai morar. Para um teste rápido, $TMP (Objeto local) resolve. Para levar a QA/PRD, escolha um pacote transportável — normalmente um pacote "geral" de serviços/consumo do ambiente — para gerar a request de transporte. Deixe marcada a opção do nó SAP Gateway OData V2 (com "Definir cliente atual como cliente padrão"): é isso que cria e já ativa o nó ICF.
Confirmação — nome técnico Z, nome externo, pacote e criação do nó ICF.
O pulo do gato no transporte: o Alias do sistema não é transportado automaticamente. Ao levar o serviço para QA/PRD, o serviço vai junto, mas a atribuição do alias não. Se esquecer disso, a API "some" no ambiente de destino e você jura que o transporte falhou. Adicione o alias manualmente em cada ambiente.
Passo 5: Confirmar o nó ICF ativo
Volte à tela inicial da transação e filtre pelo nome técnico Z (ZAPI_SALESORGANIZATION_SRV). Selecione o serviço e olhe a seção Nós ICF embaixo. Com a bolinha verde no Status, o nó está ativo e você pode testar.
Seção Nós ICF — status verde = no ar.
Se não estiver verde, clique no lápis Nó ICF e escolha Ativar. Pronto.
Nó inativo? Lápis Nó ICF → Ativar.
Passo 6: Testar com o SAP Gateway Client
Com o serviço selecionado, clique em SAP Gateway Client (transação /IWFND/GW_CLIENT). A tela permite N tipos de chamada (GET, POST, PUT…), mas aqui só queremos o "ping". A Request URI já vem montada com o nome externo. Mantenha o ?$format=xml e o método GET e clique em Execute.
Request URI default + $format=xml + GET → Execute.
Se voltar status code 200, missão cumprida: a API está ativa e pronta. Você verá o documento do serviço com as collections (entity sets) expostas — no exemplo, A_SalesOrganization e A_SalesOrganizationText.
Retorno 200 com as collections do serviço.
Status 200 é o sinal verde. Ele confirma os três pilares de uma vez: serviço registrado, nó ICF ativo e roteamento Gateway funcionando. Explorar essas entities — $filter, $expand, navegações — é o tema do próximo post.
O fluxo, num olhar
Fluxo de ativação — do Hub ao status 200. O caminho pontilhado é o atalho quando o serviço já está ativo.
E por que isso importa pra você?
Se você é funcional, não precisa esperar o dev para saber se um serviço standard já entrega aquele dado. Você mesmo localiza a API no Hub, confirma a release e dá o "ping" para ver as entities expostas. Isso muda a conversa: em vez de abrir um GAP "no escuro", você chega no desenvolvedor já sabendo se o standard cobre a necessidade — e economiza retrabalho dos dois lados.
Se você é dev, ativar a API é só o começo. Quase nenhum processo vive numa API só. Ao ativar a Sales Organization - Read, o cenário completo provavelmente pede uma Product Master, uma de pricing, uma de business partner… Pegue o costume de mapear as APIs "vizinhas" do processo e ativar todas de uma vez — assim você não trava no meio do desenvolvimento esperando liberar serviço.
No fim, o procedimento é o mesmo para qualquer API standard OData V2 — muda só o nome. Quanto mais natural ficar esse fluxo, mais rápido você valida ideias e menos tempo perde travado em "a API não funciona". No próximo post entramos na parte boa: como testar uma API standard de verdade , explorando entities, filtros e navegações no Gateway Client.
Perguntas frequentes
Qual a diferença entre o nome técnico (Z) e o nome externo do serviço?
O nome técnico (com prefixo Z, ex.: ZAPI_SALESORGANIZATION_SRV) identifica o serviço no catálogo do seu ambiente e é o que entra na especificação funcional. O nome externo (ex.: API_SALESORGANIZATION_SRV) é o que aparece na URL de chamada do serviço. São coisas diferentes — confundir os dois é a causa mais comum de "a URL não funciona".
Por que a API "sumiu" depois do transporte para QA/PRD?
Quase sempre é o alias do sistema, que não é transportado automaticamente. O serviço chega ao ambiente de destino, mas sem a atribuição do alias ele não responde. A correção é adicionar o alias manualmente em cada ambiente (QA, PRD), depois do transporte do serviço.
Esse passo a passo serve para o S/4HANA Cloud Public Edition?
Não. O fluxo via /IWFND/MAINT_SERVICE vale para On-Premise e S/4HANA Private Cloud. No Public Edition, a exposição de serviços é feita por Communication Arrangements e Communication Scenarios, um processo diferente que merece post próprio.
Preciso ativar OData V2 e V4 da mesma forma?
O conceito é o mesmo — registrar o serviço e garantir o nó ativo — mas o protocolo difere. Este guia cobre o OData V2 via /IWFND/MAINT_SERVICE. Para OData V4, a publicação usa Service Binding e o repositório de grupos de serviços, com transações e telas próprias. Aqui está o tutorial de Como ativar uma API OData V4
Conclusão
Ativar uma API OData V2 standard é um caminho de seis passos, cada um com seu detalhe: achar a API no Hub, confirmar que ela existe na sua release, checar se já não está ativa, inserir o serviço com alias LOCAL e um pacote, garantir o nó ICF verde e fechar com o 200 no Gateway Client. Pule a release ou esqueça o alias no transporte, e o que era um procedimento de minutos vira horas de diagnóstico.
Guarde as duas pegadinhas: nome técnico ≠ nome externo e alias não viaja no transporte. Com o serviço no ar e o 200 na tela, o foco muda da ativação para o consumo — tema do guia complementar Como testar uma API standard no SAP .
Referências oficiais
Comentários 0
Ainda sem comentários
Seja o primeiro a comentar este artigo.
Entre na conversa
Faça login para deixar seu comentário neste artigo.