ABAP CDS Views

Uma ABAP CDS view é código-fonte que o sistema ABAP transforma em uma view de banco de dados:

1. Um desenvolvedor cria uma definição de dados no ABAP Development Tools e escreve uma instrução DEFINE VIEW ENTITY: fontes de dados, campos selecionados, cálculos, joins e associações a outras entidades CDS.
2. Anotações acrescentam metadados: rótulos, semântica como campos de moeda ou unidade, papéis analíticos, indicações de UI e configurações de exposição OData.
3. Na ativação, o sistema cria a entidade CDS e a view correspondente no banco de dados, de modo que a lógica é executada onde os dados estão.
4. Os consumidores leem a view: ABAP SQL em programas, serviços OData construídos com RAP, queries analíticas e APIs liberadas.
5. Se existir um CDS access control para a view, suas condições são aplicadas a toda leitura da view.

As associações são uma diferença-chave em relação às views de banco de dados clássicas: declaram um relacionamento uma única vez, e o join só é montado quando um consumidor percorre o caminho da associação. Uma ABAP CDS view é, portanto, um modelo de dados semântico reutilizável, e não apenas um SELECT armazenado.

A documentação da SAP cita ativação mais rápida, sintaxe mais simples e verificações mais rígidas entre os motivos para usar view entities. As views DDIC-based existentes continuam funcionando, e o ABAP Development Tools oferece um assistente de migração, documentado on-premise a partir do SAP S/4HANA 2023 FPS00. O RAP em strict mode também espera view entities como fontes de dados. Para qualquer novo desenvolvimento, as view entities são a variante de ABAP CDS views a usar.

O SAP S/4HANA entrega milhares de CDS views organizadas como o virtual data model (VDM). As basic interface views expõem entidades de negócio próximas das tabelas, as composite interface views as combinam e as consumption views atendem a um app ou query específico. O prefixo do nome indica a camada: I_ para interface views, como I_SalesOrder, e C_ para consumption views.

O que importa para os clientes é o status de liberação de uma view:

• Liberada para extensibilidade key user (contrato C1): utilizável em ferramentas de key user como o app Custom CDS Views.
• Liberada para desenvolvimento cloud (contrato C1): utilizável por desenvolvedores em ABAP Cloud, inclusive na extensibilidade de desenvolvedor.
• Não liberada: visível no sistema, mas sem contrato de estabilidade; a SAP pode alterá-la em qualquer upgrade.

Um key user da Alder Manufacturing que precisa dos pedidos de compra em aberto por fornecedor, por exemplo, constrói uma CDS view customizada sobre views de compras liberadas, em vez de ler tabelas. No virtual data model, o status de liberação decide se é seguro construir sobre uma ABAP CDS view.

Uma CDS view fornece dados e metadados; outros objetos a transformam em um app:

1. Caminho atual (RAP): CDS view entities formam um business object, uma behavior definition acrescenta operações, projection views o ajustam, e uma service definition mais um service binding o expõem como OData V2 ou V4.
2. SAP Fiori elements lê as anotações de UI desse serviço e renderiza um list report ou object page.
3. Apps analíticos consomem CDS analytical queries, definidas como transient view entities nas releases recentes e com a anotação obsoleta @Analytics.query nas mais antigas.

Sistemas mais antigos usam caminhos anteriores: a anotação @OData.publish do ABAP Programming Model for SAP Fiori, ou um projeto SAP Gateway que usa a CDS view como referenced data source; verifique quais deles a sua release ainda suporta. Em todos os caminhos, a ABAP CDS view define o que os dados são; o comportamento transacional vem do RAP ou, no modelo predecessor, do BOPF.

Os pontos fortes são substanciais. Um único modelo atende igualmente OData, analytics e ABAP SQL; os cálculos rodam no banco de dados; as anotações carregam uma semântica que todo consumidor entende; e o controle de acesso é declarado junto aos dados.

Os limites decorrem do que uma view é:

• Somente modelo de leitura. Uma CDS view não cria, altera nem valida dados. Transações precisam de um RAP business object por cima.
• SQL declarativo, não lógica procedural. Algoritmos complexos vão para CDS table functions implementadas em AMDP, ou para ABAP.
• O desempenho depende do empilhamento. Views construídas sobre views sobre views podem gerar SQL pesado; associações usadas sem cuidado multiplicam os joins.
• Vinculadas à release. Os recursos de sintaxe chegam release a release; uma view escrita para o SAP BTP ABAP environment pode não ativar em uma release on-premise mais antiga.

As ABAP CDS views são o lugar certo para a semântica dos dados, não para lógica de processo ou de transação.

1. Criar novas views DDIC-based. Elas são obsoletas; comece com view entities.
2. Construir sobre views SAP não liberadas. Funciona até que um upgrade altere a view. Verifique antes o contrato de liberação.
3. Esquecer o controle de acesso. Sem um CDS access control, qualquer pessoa autorizada a ler a view vê todos os seus dados. Adicione um access control e mantenha também as autorizações de inicialização do app.
4. Escrever anotações de UI na definição de dados. Metadata extensions mantêm o modelo legível e permitem que os metadados de UI mudem no seu próprio ritmo.
5. Confundir ABAP CDS com CAP CDS. Mesma ideia e sintaxe semelhante, runtime diferente: um modelo CAP não ativa em um sistema ABAP.

A maioria dos problemas com ABAP CDS views vem de decisões de ciclo de vida, não do SQL.