Service Binding (RAP)

Um service binding é o último passo na cadeia RAP que vai do modelo de dados ao serviço consumível:

1. CDS view entities e uma behavior definition formam o business object.
2. Projection views moldam o que um serviço precisa.
3. Uma service definition lista as entidades que o serviço expõe.
4. O service binding decide como esse escopo é exposto: qual protocolo, qual tipo de consumo e qual versão.

Seus parâmetros são o nome do serviço, idêntico ao nome do binding; o tipo de binding; a versão do serviço; e o status de publicação. Como protocolo e escopo são objetos separados, vários bindings podem ficar sobre uma mesma service definition: a Alder Manufacturing poderia expor o mesmo escopo de requisição de compra uma vez como serviço de UI OData V4 para seu app SAP Fiori e outra vez como Web API OData V4 para um portal de fornecedores da Cedar Office Supply. O service binding é, portanto, onde um serviço RAP se torna um endpoint concreto e endereçável.

A documentação atual da SAP lista quatro protocolos e duas categorias de consumo:

A categoria importa tanto quanto o protocolo. Os serviços de UI carregam em seus metadados anotações de UI, value helps, side effects e feature control, e oferecem a pré-visualização SAP Fiori elements. As Web APIs não contêm informações específicas de UI, destinam-se a consumidores desconhecidos e podem ser estendidas. A SAP recomenda OData V4 sempre que possível para serviços transacionais e observa que o suporte completo do SAP Fiori elements em OData V4 só é garantido para cenários habilitados para draft. Verifique quais tipos de binding a sua release oferece na documentação RAP correspondente. Critério de decisão: faça o binding como UI quando um app SAP Fiori consome o serviço, e como Web API em todos os outros casos.

• Publicação: o binding precisa estar ativo, e o botão Publish no editor de service binding executa as listas de tarefas que habilitam o endpoint. A SAP enfatiza que a publicação habilita o serviço apenas no sistema atual; ela não torna o serviço acessível a partir de outros sistemas.
• Após o transporte (on-premise e Private Edition): a SAP documenta que o service binding só habilita o serviço localmente no sistema de desenvolvimento; nos sistemas de qualidade e produção, o serviço é ativado com as ferramentas do Gateway, os serviços OData V4 como grupos de serviços na /IWFND/V4_ADMIN e os serviços OData V2 na /IWFND/MAINT_SERVICE.
• ABAP environment (SAP BTP e extensibilidade de desenvolvedor da Public Edition): uma Web API chega a chamadores externos pelo inbound service gerado pelo binding, adicionado a um communication scenario publicado, e depois por um communication arrangement que um administrador cria.
• Versionamento: adicionar outra service definition a um binding existente cria a próxima versão do serviço, de modo que as alterações chegam a novos consumidores sem quebrar os existentes.

Um service binding publicado é um endpoint local; a exposição a outros sistemas é uma etapa de configuração separada.

1. Vincular um app SAP Fiori a uma Web API. O app carrega, mas mostra tabelas vazias ou layouts padrão, porque os metadados de Web API não contêm anotações de UI. Crie um binding UI.
2. Escolher OData V4 para um app transacional sem draft. O suporte do SAP Fiori elements em V4 só é completo com draft; habilite o draft ou planeje as lacunas.
3. Alterar um serviço liberado no próprio lugar. Os consumidores quebram silenciosamente. Adicione uma versão do serviço em vez disso.
4. Supor que Publish significa acessível. Um chamador remoto ainda precisa da configuração de comunicação, e os usuários on-premise precisam de autorizações para o serviço.
5. Depurar a UI primeiro. Quando uma pré-visualização falha, verifique se o binding está ativo e publicado antes de mexer nas anotações.

A maioria dos problemas com service bindings vem da escolha da categoria errada ou de uma etapa de publicação pulada, e não do business object por trás.