É chamado de modelo virtual porque ele abstrai dados das tabelas de bases de dados. Dessa forma, tabelas existentes podem ser transformadas em modelos de dados uniformes quando necessário.

Além de descrever as semânticas de negócios das aplicações, o VDM do SAP S/4HANA é também um modelo executável que provê acesso aos dados correspondentes em tempo de execução. O VDM é implementado usando entidades Core Data Services (serviços de dados principais) especificamente classificados, que concordam com as regras do VDM. Essas regras do VDM incluem regras de nomenclatura fundamentais, regras para estruturar as entidades VDM, entre outras.

De um lado as regras fomentam a consistência dos modelos; por outro, eles permitem o desenvolvimento eficiente de aplicações e APIs que cobrem consumo analítico, processamento transacional, e cenários de consumo relacionados à procura. Além de prover os modelos de dados para aplicações, as VDM Views também são usadas para outras tarefas, como extração baseada em CDS.

O VDM não é direcionado apenas ao desenvolvimento de aplicações na SAP. Em vez disso, modelos SAP VDM lançados e os serviços SAP estruturados neles oferecem uma interface estável com um ciclo de vida bem definido. Como consumidor ou parceiro SAP, você pode usá-los para criar suas próprias aplicações e para melhorar aplicações SAP.

Core Data Services

Os Core Data Services (CDS) suportam a definição de modelos de dados semanticamente ricos. Esses modelos são administrados pelo dicionário de dados da plataforma ABAP e podem ser executados no sistema do banco de dados.

As CDS Views representam o tipo de entidade CDS mais importante. Elas contêm instruções de seleção em uma sintaxe que é muito próxima da SQL (Structured Query Language). CDS Views podem ser usadas, por exemplo, como fontes de dados em instruções de seleção ABAP. Os resultados obtidos ao consultar uma CDS View podem ser restritos ao adicionar modelos de controle de acesso à CDS View. Isso significa que a consulta apenas retornaria os dados que o usuário está autorizado a ver. Esses modelos de controle de acesso são definidos usando a CDS data control language (DCL/linguagem de controle de dados).

Ademais, CDS Views permitem modelar associações, o que representa relações diretas com outras entidades CDS. Ambas as anotações e associações são interpretadas pelos vários consumidores de modelos CDS. Em específico, a infraestrutura ABAP utiliza a informação correspondente para derivar funcionalidades adicionais e serviços dos modelos CDS. Por exemplo, a CDS View anotada corretamente pode ser executada pelo motor analítico. O motor analítico provê funcionalidades avançadas como agregações de isenção e manuseio de hierarquia, que não são modeladas pela instrução de seleção da própria CDS View.

Convenções de nomenclatura

O VDM é baseado em um conjunto de regras de nomenclatura comuns. Aplicar as seguintes regras garante uma nomenclatura consistente e auto explicativa:

Um nome é preciso e identifica exclusivamente um objeto. Evite nomes genéricos. Por exemplo, o identificador do documento de ordens de venda é nomeado SalesOrder (OrdenDeVendas), não apenas ID ou Order.

Um nome contém a semântica comercial de um objeto.

Os nomes serem únicos implica que objetos diferentes devem possuir nomes diferentes. Isso é especialmente importante para identificadores e códigos. Usar o mesmo nome para dois campos implica que suas listas de valores subalternos correspondem.

Nomes são compostos por termos em língua inglesa, em notação camelcase (sem espaços entre as palavras e exceto a primeira palavra, todas começam com letra maiúscula) com a primeira letra maiúscula. Travessões são usadas apenas em casos pré definidos e abreviações devem ser evitadas.

As regras de nomenclatura são aplicadas a todas as entidades CDS e suas partes – por exemplo nomes de campos, associações, parâmetros ou CDS Views.

A estrutura do Virtual Data Model

Dentro do VDM, entidades CDS cumpres objetivos diferentes. Elas são classificadas de acordo por meio de anotações VDM. Perceba que uma entidade CDS se torna uma entidade VDM se ela usar anotações VDM e aderir às diretrizes do VDM.

VDM Views são organizadas em uma estrutura hierárquica dividida em camadas. As camadas superiores selecionam e definem associações para elas mesmas ou para camadas superiores, mas não vice-versa. As VDM Views são designadas para camadas com uma anotação CDS especial (@VDM.viewType).

Existem dependências admissíveis entre as views como fontes de dados e tipos diferentes de views, e elas são acompanhadas por prefixos para os nomes das CDS Views. Views de consumo possuem o prefixo C_ e Views de APIs remotas possuem o prefixo A_. Existem também basic views (views básicas) e composite views (views compostas) de uma camada de interface que podem ser usadas para criar aplicações, essas views da camada de interface possuem o prefixo I_. Views básicas e compostas podem ser também views de reuso restrito, indicadas pelo prefixo R_.

Views básicas (basic views): 

O nível mais baixo da pilha de views do VDM é definido por basic views. Elas são as constituintes mais importantes do VDM. Elas estabelecem aquilo que chamamos de entity relationship model (modelo de relacionamento de entidades) das aplicações, de onde elas conseguem informações sobre estruturas de dados, dependências e metadados. O principal objetivo das basic views é servir como blocos de construção para quaisquer outras views não básicas do VDM. Por causa que as basic views expõem todos os dados, nenhuma outra view não básica precisa selecionar diretamente das bases de dados. Aliás, acessar as tabelas das bases de dados de views não básicas é proibido no VDM. Dessa forma, as basic views fornecem a abstração completa das tabelas das bases de dados para as camadas mais altas.

Views compostas (composite views):

Composite views (views compostas) compreendem funcionalidades adicionais além das basic views. Assim como as basic views, seu objetivo primário é servir como blocos de construção reutilizáveis para outras views. Contudo, elas já podem ser definidas de forma que suportem um domínio de consumo específico. Por exemplo, elas podem definir analytical cube views (views de cubo analítico), que consolidam fontes de dados para uso em várias consultas analíticas.

Views transacionais (transactional views):

Transactional views são um tipo especial de composite views. Transactional views definem o modelo de dados de um objeto de negócios e agem como âncora para definir seus aspectos transacionais relacionados a processamento.  Transacional views devem conter elementos que suportam a lógica de processamento transacional, como campos adicionais que ajudam a preservar as entradas de dados do usuário temporariamente. Dessa forma, transactional views são usadas apenas no contexto de processamento transacional – por exemplo, quando consumidas por outras transactional views ou por consumption views (views de consumo) que delegam a lógica de processamento transacional delas para as transactional views.

Views de consumo (consumption views):

Basic views normais suportam qualquer caso de uso. Isso significa que elas são definidas independente de um caso de uso específico. Em contraste, consumption views são deliberadamente ajustadas para um objetivo. Consumption views são visadas para serem usadas em um cenário de consumo específico. Por exemplo, uma delas pode prover exatamente os dados e os metadados (através de anotações) para um elemento de UI específico.

Views de reuso restrito (restricted reuse views):

Por padrão, basic e composite views definem uma camada de interface (nomeadas com o prefixo I_), que qualquer aplicação SAP pode utilizar. Após lançadas, elas também podem ser utilizadas por consumidores e parceiros SAP. Contudo, equipes de desenvolvimento às vezes definem basic e composite views que servem apenas para uso local em suas próprias aplicações. Em tais casos, uma restricted reuse view (nomeada com o prefixo R_) é definida. Exemplos de restricted reuse views são views habilitadas para processamento transacional, que expõe todas as funções e operações de um objeto de negócios, incluindo as internas.

Views de pesquisa corporativa (enterprise search views):

Pesquisa corporativa usa CDS Views especiais como modelos de pesquisa.

Views de API remota (remote API views):

Remote API views projetam as funcionalidades de um único objeto de negócios para consumo externo. Elas desacoplam o VDM regular interno, que pode evoluir com o tempo, dos sistemas de seus consumidores estabelecendo uma interface estável. baseados nas remote API views, são definidos serviços OData, que podem ser utilizados por aplicações externas. Os serviços OData correspondentes estão publicados no SAP API Business Hub (https://api.sap.com).

Cenários de consumo

Os cenários de consumo mais proeminentes suportados por entidades CDS são os seguintes:

• Analítica;
• Enterprise search (pesquisa corporativa);
• Aplicações com UI SAP Fiori;
• APIs remotas;

No caso de aplicações analíticas e aplicações com processamento transacional habilitado, use case-specific views (views de caso de uso específico) são definidas além das basic views e composite reuse views para adaptar o modelo de dados e funcionalidades para as necessidades individuais da aplicação:

1. Aplicações analíticas

Aplicações analíticas são baseadas em cube views e uma rede de views de dimensão associada, às quais as próprias aplicações podem associar textos e views de hierarquia. A aplicação analítica real é definida por uma view de consulta analítica, que projeta a funcionalidade prevista de sua cube view subalterna. Note que, diferente de outras CDS Views, as próprias views de consulta analítica não são executadas no banco de dados. Em vez disso, o motor analítico interpreta sua lógica e executa seleções diretamente das cube views e views de dimensão.

2. Aplicações com processamento transacional habilitado

O modelo de dados é contido por transactional views, que são relacionadas através de relações composicionais para formar todo um objeto de negócios (business object). Nele a lógica de seleção de dados real é definida pelos modelos de CDS Views. O modelo de comportamento especificando as operações Create, Read, Update, Delete (CRUD / criar, ler, atualizar, deletar) é definido em um behavior definition model (modelo de definição de comportamento) e implementado em classes ABAP. A consumption view projeta funcionalidades relevantes e argumenta o modelo de dados com anotações, que oferecem os metadados para renderizar a aplicação de UI estruturada na view. Views de interfaces associadas para enriquecer os modelos de dados quando necessário.

Nota do editor: o conteúdo deste post foi adaptado de uma seleção do livro SAP S/4HANA Architecture por Thomas Saueressig, Tobias Stein, Jochen Boeder, e Wolfram Kleis.