OData

O OData descreve os dados de negócio como entity sets que os clientes endereçam por URLs, com verbos HTTP padrão para cada operação:

• GET lê um entity set ou uma única entidade, por exemplo os pedidos de compra da Cedar Office Supply.
• POST, PATCH/PUT e DELETE criam, alteram e removem entidades.
• System query options como $filter, $select, $expand, $orderby, $top e $skip permitem que o cliente peça ao servidor para filtrar, ordenar e paginar os dados.
• `$metadata` retorna o modelo de dados do serviço: entity types, propriedades, chaves, associações e anotações.
• `$batch` agrupa várias requisições em uma única chamada HTTP.

Como o modelo e as operações são padronizados, um cliente genérico como o OData model do SAPUI5 pode vincular controles a qualquer serviço compatível sem código de requisição customizado. O OData é, portanto, um contrato sobre como os dados são expostos, e não uma peça de lógica de negócio.

Depois que o SAP Fiori Launchpad resolveu um tile e iniciou o app, o acesso aos dados segue o mesmo caminho em todo app SAPUI5 ou SAP Fiori elements:

1. O app inicia. O app descriptor indica o serviço OData que o app usa como fonte de dados.
2. O app chama o serviço. O OData model do SAPUI5 envia requisições, muitas vezes agrupadas em um $batch, para a URL do serviço. No SAP S/4HANA, o SAP Gateway verifica se o usuário pode iniciar o serviço (objeto de autorização S_SERVICE) e roteia a requisição.
3. A lógica de negócio é executada. A implementação do serviço — CDS views, comportamento RAP ou código baseado em SEGW — aplica validações e autorizações de dados.
4. O registro é lido ou gravado. A resposta retorna os dados, ou a alteração é gravada no documento de negócio, o que pode disparar processamentos subsequentes, como um workflow.

Uma etapa com falha aparece de forma diferente: uma autorização de início ausente aparece na SU53, enquanto um erro do lado do serviço aparece na /IWFND/ERROR_LOG ou na /IWBEP/ERROR_LOG on-premise. Toda tela SAP Fiori orientada a dados é, por baixo, uma sequência de requisições OData.

As duas versões coexistem nos landscapes SAP, e a versão define quais ferramentas e modelos se aplicam:

O RAP pode expor o mesmo business object como OData V2 ou V4, e alguns recursos mais novos do SAP Fiori elements só são avaliados com OData V4, enquanto muitos apps entregues continuam rodando em V2. Escolher uma versão de OData é uma decisão sobre ferramentas e suporte nos apps, e não apenas sobre recursos do protocolo.

A SAP oferece várias formas de criar um serviço OData, conforme a plataforma e a idade da base de código:

• RAP (ABAP RESTful Application Programming Model): uma service definition seleciona entidades CDS, e um service binding as publica como OData V2 ou V4, com a categoria UI (carrega anotações de UI para o SAP Fiori elements) ou Web API (sem metadados específicos de UI).
• Projetos SEGW: o SAP Gateway Service Builder modela entidades e gera classes de runtime para ABAP escrito à mão; comum em apps customizados mais antigos.
• CDS com `@OData.publish: true`: gera um serviço OData V2 a partir de uma CDS view; ainda documentado para on-premise e Private Edition, enquanto os service bindings RAP são a abordagem mais nova.
• CAP no SAP BTP: service definitions em CDS disponibilizadas como OData, com V4 como padrão e V2 disponível por meio de um adaptador.

O protocolo trafegado é o mesmo; o modelo de programação por trás dele determina como lógica, drafts e extensões são tratados. O ideal é iniciar um novo serviço OData no modelo de programação que a plataforma de destino recomenda atualmente.

• On-premise e Private Edition: os administradores registram e ativam serviços OData no SAP Gateway, atribuem system aliases e mantêm nós ICF. O conjunto completo de transações e logs do Gateway está disponível.
• Public Edition: a SAP opera os serviços por trás dos apps SAP Fiori entregues. O acesso às ferramentas de administração e monitoramento é controlado, e não aberto como on-premise; consumidores externos chamam APIs liberadas por meio de communication arrangements, e serviços customizados vêm da extensibilidade de desenvolvedor ou key user.
• SAP BTP: os apps chamam serviços OData no SAP BTP diretamente ou alcançam serviços on-premise por meio de destinations e do SAP Cloud Connector.

O protocolo OData se comporta da mesma forma em todos os lugares; o que muda é quem ativa o serviço e como um chamador o alcança.

1. Tratar um serviço de UI como API de integração. Um serviço construído para um app SAP Fiori pode mudar junto com o app. Integrações devem usar APIs liberadas ou serviços projetados como Web APIs.
2. Over-fetching. Listas sem $select ou com $expand profundo trafegam muito mais dados do que a tela mostra; verifique as requisições nas ferramentas de desenvolvedor do navegador.
3. Ignorar o `$batch` na depuração. O navegador mostra uma única chamada batch; a operação com falha está dentro do corpo da resposta.
4. Misturar versões no desenho de um app. V2 e V4 usam modelos SAPUI5 e stacks do SAP Fiori elements diferentes, então os componentes raramente passam de um para o outro sem alterações.
5. Culpar a UI por lacunas de autorização. Uma lista vazia pode ser um filtro de autorização de dados no serviço, e não um bug de front-end.

A maioria dos problemas de OData em projetos SAP Fiori são problemas de desenho ou de autorização que só aparecem como erros de protocolo.