SAP Cloud Application Programming Model (CAP)

Uma aplicação CAP parte de declarações e acrescenta código apenas onde os padrões do framework não bastam:

1. Modelo de domínio: entidades, tipos e associações são escritos em arquivos CDS, por exemplo fornecedores e janelas de entrega para um app de logística da Alder Manufacturing.
2. Serviços: as definições de serviço expõem projeções dessas entidades, moldadas para uma UI ou uma API.
3. Runtime: o runtime Node.js ou o CAP Java SDK disponibiliza os serviços e trata as operações padrão de forma genérica: leitura, gravação, paginação, ordenação e draft do SAP Fiori.
4. Lógica customizada: event handlers em JavaScript, TypeScript ou Java, registrados para as fases before, on e after de uma requisição, acrescentam validações, cálculos e chamadas a outros sistemas.
5. Persistência: o mesmo modelo roda em SQLite ou H2 durante o desenvolvimento e em SAP HANA Cloud ou PostgreSQL em produção.
6. Implantação: a aplicação é implantada no SAP BTP, no runtime Cloud Foundry ou Kyma.

Apps SAP Fiori elements consomem serviços CAP por meio de anotações de UI escritas nos mesmos arquivos CDS. Uma aplicação CAP é, portanto, sobretudo modelo, com o código concentrado onde a lógica de negócio é específica.

Não. Ambos vêm da ideia de Core Data Services da SAP, ambos usam uma sintaxe declarativa semelhante e ambos carregam anotações, mas são implementações separadas:

• ABAP CDS faz parte da plataforma ABAP. Suas views são objetos de repositório ativados como views de banco de dados dentro de um sistema ABAP e transportados com transportes ABAP.
• CAP CDS é a linguagem de modelagem do CAP. Seu compilador transforma os modelos em uma representação baseada em JSON chamada Core Schema Notation (CSN), a partir da qual o CAP gera artefatos de banco de dados e metadados de serviço.

As anotações mostram a diferença na prática. No CAP, as anotações de UI usam diretamente os nomes de termos OData, como UI.LineItem; no ABAP CDS, notações no nível de elemento como @UI.lineItem são traduzidas para esses termos quando o serviço é exposto. Um modelo não pode ser levado de um para o outro sem alterações. CAP CDS e ABAP CDS compartilham um nome e uma filosofia, não um runtime.

Escolha o CAP quando:

• a aplicação pertence ao lado do SAP S/4HANA, e não dentro dele, como extensão side-by-side no SAP BTP;
• a aplicação tem seus próprios dados ou combina dados de vários sistemas, SAP e não SAP;
• a equipe trabalha com JavaScript, TypeScript ou Java em vez de ABAP;
• a aplicação precisa atender vários clientes como oferta SaaS multitenant, que o CAP suporta com isolamento de tenants e seus serviços MTX.

Prefira o RAP quando a lógica precisa rodar na mesma transação que os dados do SAP S/4HANA, quando a extensão altera um business object padrão ou quando a equipe e o modelo de operação são baseados em ABAP.

Muitos landscapes usam os dois: RAP para a lógica próxima do core, CAP para as aplicações ao redor dele. A pergunta decisiva para o CAP é onde os dados e a transação devem ficar.

Uma aplicação CAP não roda dentro do SAP S/4HANA, então acessa os dados SAP por meio de APIs:

1. A definição de API de um serviço OData do SAP S/4HANA, por exemplo do SAP Business Accelerator Hub, é importada no projeto CAP com cds import, que lê arquivos OData EDMX, OpenAPI e AsyncAPI.
2. Durante o desenvolvimento, o CAP pode simular (mock) o serviço importado localmente, de modo que as equipes podem trabalhar antes de a conexão existir.
3. Em produção, as chamadas passam pela conectividade do SAP BTP: destinations para o sistema de destino e, para sistemas on-premise, o Cloud Connector.
4. Eventos do SAP S/4HANA podem acionar lógica CAP de forma assíncrona onde o cenário os suporta, normalmente por meio de um serviço de event broker da SAP.

A API liberada, e não a tabela do banco de dados, é o contrato entre o CAP e o SAP S/4HANA. Isso mantém a extensão desacoplada do core, que é o propósito da abordagem side-by-side que o CAP segue.

Os pontos fortes do CAP são velocidade e consistência. Os handlers genéricos eliminam código repetitivo, o desenvolvimento local funciona sem conexão com a nuvem graças aos mocks e ao SQLite, o suporte a SAP Fiori e SAP HANA vem embutido, e o multitenancy faz parte do framework em vez de ser um projeto à parte.

Os limites vêm de rodar fora do sistema de registro:

• Sem acesso direto aos internos do SAP S/4HANA. Tudo passa por APIs liberadas; APIs ausentes viram bloqueios ou exigem um complemento do lado ABAP.
• Sem transação compartilhada. Uma atualização no CAP e um lançamento no SAP S/4HANA são transações separadas; o tratamento de falhas precisa ser projetado explicitamente.
• Mais coisas para operar. Uma aplicação CAP acrescenta ao landscape um runtime SAP BTP, um banco de dados e conectividade, com seu próprio monitoramento, upgrades e custos.
• Framework opinativo. Trabalhar contra as convenções do CAP custa mais do que segui-las.

O CAP é a escolha mais forte para aplicações ao lado do core; ele não substitui a lógica que precisa ficar dentro dele.