Como ativar uma API OData V4 standard no SAP
Mesma filosofia da V2, três diferenças que pegam
No post anterior eu mostrei como ativar uma API OData V2 standard no SAP . A V4 segue a mesma filosofia, mas tem três diferenças que pegam quem está acostumado com a V2:
a transação é outra (
/IWFND/V4_ADMIN);o transporte é não mais manual por alias de sistema;
na hora de testar tem um detalhe nas linhas do serviço.
Resolvidas essas três, o resto é quase igual. O escopo aqui continua sendo ativar e dar o "ping" para confirmar que a API está no ar — testar a fundo (entities, $filter, $expand) fica para o outro post.
Quer entender o protocolo, não só a ativação? As diferenças entre OData V2 e V4 vão muito além da transação — mudam URL, metadados, batch, navegações… Isso rende um post próprio: Diferenças entre OData V2 e OData V4 .
É de Public Cloud? Este passo a passo vale para On-Premise e S/4HANA Private Cloud. No S/4HANA Cloud Public Edition a exposição de serviços é via Communication Arrangements .
Passo 1: Achar a API no Business Accelerator Hub
Exatamente como na V2: entre no SAP Business Accelerator Hub, aba APIs, mas agora filtre por ODATA V4 e busque em inglês (serial number, por exemplo). Compare os cards e fique de olho no selo ACTIVE (fuja dos DEPRECATED).
No exemplo, vamos usar a Material Serial Number — o serviço técnico API_MATERIALSERIALNUMBER.
Business Accelerator Hub — filtro ODATA V4 e busca em inglês.
Conferir a release do seu ambiente também vale aqui — mesma lógica do post de V2.
Passo 2: Abrir a /IWFND/V4_ADMIN
Aqui já muda. Vá na transação /n/IWFND/V4_ADMIN — a tela SAP Gateway Service Administration. A primeira diferença conceitual: na V4 a unidade de trabalho não é o "serviço", é o Service Group. No painel da esquerda (Service Groups) você procura o grupo da sua API — no caso, API_MATERIALSERIALNUMBER.
/IWFND/V4_ADMIN — a unidade de trabalho na V4 é o Service Group.
Se o grupo já estiver na lista e com serviços disponíveis, ele já está publicado e você pode pular para o teste (Passo 5). Se não estiver, siga em frente.
Passo 3: Publicar o service group
Na barra de ferramentas, clique em Publish Service Groups, procure pelo nome da sua API e publique o grupo. É o equivalente ao "Inserir serviço" da V2 — só que agora você publica o grupo inteiro, não um serviço isolado.
Publish Service Groups — busca pelo nome da API e publicação do grupo.
Passo 4: Atribuir o transporte (aqui mora a maior diferença)
Com o grupo publicado, clique com o botão direito sobre ele e escolha Transport Publishing. Atribua uma request de customizing.
Transport Publishing — a publicação do grupo vai numa request de customizing.
O grande ganho da V4 sobre a V2:
Na V2, a atribuição do alias do sistema não era transportada — você refazia manualmente em cada ambiente (QA, PRD), e era clássico esquecer e jurar que "o transporte falhou".
Na V4, a publicação do grupo vai numa request de customizing. Ela viaja junto para o ambiente de destino. Menos pegadinha, menos retrabalho.
Passo 5: Testar a linha certa
Olhe a seção Available Services do grupo. Repare que sempre vão aparecer (pelo menos) duas linhas:
Linha 1 —
/IWBEP/COMMON(V4 Common Service): é o serviço técnico comum do framework V4. Não é essa que você testa.Linha 2 —
SRVD_A2X+ o nome da sua API (API_MATERIALSERIALNUMBER): essa é a sua API.
Available Services — teste a linha SRVD_A2X, não a /IWBEP/COMMON.
Selecione a linha do SRVD_A2X e clique em Service Test. Abre o Gateway Client com a URI já montada. Pode dar GET + Execute.
Service Test → Gateway Client com a URI /sap/opu/odata4/… e o 200.
Duas coisas para reparar aqui:
A URL é diferente: a V4 usa
/sap/opu/odata4/…(a V2 usava/sap/opu/odata/…), e o caminho inclui o bindingsrvd_a2x, o service group e a versão.Se voltar
status 200, missão cumprida: a API está ativa e pronta para uso.
O fluxo, num olhar
Fluxo de ativação OData V4 — do Hub ao status 200. O pontilhado é o atalho quando o grupo já está publicado.
E por que isso importa pra você?
Se você é funcional, vale o mesmo recado do post de V2: você não precisa esperar o dev para saber se um serviço standard já entrega aquele dado. Localize a API no Hub, confira na sua release e dê o "ping" para ver as entities que ela expõe. Chegar no desenvolvedor já sabendo se o standard cobre (ou não) a necessidade economiza retrabalho dos dois lados.
Se você é dev, ativar a API é só o começo — quase nenhum processo vive numa API só. Ao publicar o grupo da Material Serial Number, é provável que o cenário completo também peça uma de inventário físico, uma de warehouse… Mapeie as APIs "vizinhas" e publique todas de uma vez. E, na V4, lembre do transporte de customizing: é ele que leva a publicação para QA/PRD sem você refazer nada na mão.
No fim, é a mesma filosofia da V2, com os ajustes de service group e transporte de customizing. Quanto mais natural ficar esse fluxo, menos tempo você perde travado em "a API não funciona".
Perguntas frequentes
Qual a diferença entre /IWFND/MAINT_SERVICE e /IWFND/V4_ADMIN?
A /IWFND/MAINT_SERVICE ativa serviços OData V2, registrando serviço por serviço. A /IWFND/V4_ADMIN (SAP Gateway Service Administration) ativa serviços OData V4, e a unidade de trabalho é o Service Group — você publica o grupo inteiro, não um serviço isolado.
Por que aparecem duas linhas em Available Services?
Toda publicação V4 traz, no mínimo, duas linhas. A /IWBEP/COMMON é o V4 Common Service do framework — comum a todos os grupos e não é o que você testa. A linha SRVD_A2X + o nome da API é a sua API; é essa que você seleciona em Service Test.
A publicação V4 precisa ser refeita em QA e PRD como na V2?
Não. Essa é a maior vantagem da V4. A publicação do service group vai numa request de customizing via Transport Publishing, então viaja junto no transporte. Na V2, a atribuição do alias do sistema não era transportada e precisava ser refeita manualmente em cada ambiente.
Como diferencio a URL de um serviço V4 de um V2?
Pelo caminho. A V4 usa /sap/opu/odata4/…, com o binding srvd_a2x, o service group e a versão no path. A V2 usa /sap/opu/odata/…. Só de olhar a Request URI no Gateway Client você já sabe qual protocolo está chamando.
Conclusão
Ativar uma API OData V4 é a mesma ideia da V2 com três ajustes: a transação /IWFND/V4_ADMIN, a publicação por service group e o transporte de customizing que leva tudo para QA/PRD sem retrabalho. Some a isso o detalhe das linhas — teste sempre a SRVD_A2X, nunca a /IWBEP/COMMON — e o status 200 confirma a API no ar.
Com o serviço publicado, o próximo passo é o consumo de verdade. Veja também os guias relacionados abaixo.
Leituras relacionadas
Diferenças entre OData V2 e OData V4 (em breve)
Como testar uma API standard no SAP (em breve)
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.