ABAP Cloud

A SAP descreve o ABAP Cloud como uma metodologia de desenvolvimento formada por partes que já existiam na plataforma ABAP, combinadas sob um único conjunto de regras:

• ABAP CDS para modelos de dados e queries analíticas.
• O ABAP RESTful Application Programming Model (RAP) para business objects transacionais e serviços.
• ABAP for Cloud Development, uma versão restrita da linguagem que permite apenas um subconjunto dos comandos ABAP; as telas dynpro clássicas, por exemplo, não fazem parte dela.
• APIs e pontos de extensão liberados pela SAP como o único caminho permitido para acessar código e dados da SAP.
• ABAP Development Tools no Eclipse como IDE, com as ABAP development tools para Visual Studio Code como opção adicional.

Sobre essa base, o modelo oferece serviços de reúso, como intervalos de numeração, application jobs e um repositório de UI para apps SAPUI5 e SAP Fiori elements. O ABAP Cloud é, portanto, um conjunto de regras para usar o ABAP moderno, e não uma nova linguagem nem um runtime separado.

O SAP BTP ABAP environment é um serviço de plataforma para desenvolvimento ABAP side-by-side e costuma ser chamado pelo nome interno do projeto na SAP, Steampunk. No SAP S/4HANA, o mesmo modelo roda dentro do ERP, o que o glossário ABAP da SAP chama de embedded Steampunk. Na Private Edition e no on-premise, cada objeto de desenvolvimento tem uma versão de linguagem, de modo que uma equipe pode construir objetos novos com ABAP Cloud enquanto o código mais antigo continua clássico.

O ABAP Cloud é a única opção de ABAP nos produtos de nuvem pública e a opção recomendada, ao lado do ABAP clássico, em todos os demais.

O ABAP Cloud transforma as regras de clean core em verificações executadas enquanto o código é escrito:

1. Todo objeto de desenvolvimento tem uma versão de linguagem ABAP. Objetos em ABAP for Cloud Development são verificados pela verificação de sintaxe e em tempo de execução.
2. A verificação de sintaxe aceita apenas objetos SAP liberados para desenvolvimento em nuvem sob o contrato de liberação C1, além de pontos de extensão liberados sob C0.
3. A SAP verifica seus próprios objetos liberados em relação ao contrato de liberação, de modo que não se esperam mudanças incompatíveis em um upgrade.
4. Na Private Edition e no on-premise, quando falta uma API liberada necessária, a orientação da SAP permite um wrapper escrito em ABAP clássico, liberado pelo cliente com o contrato C1 e governado com verificações do ABAP Test Cockpit.

Na Alder Manufacturing, um app customizado de aprovação para o cadastro de fornecedores construído dessa forma lê os dados de fornecedor por meio de CDS views liberadas, e não de tabelas SAP. O ABAP Cloud faz da estabilidade em upgrades uma propriedade do compilador, e não uma promessa de code review.

• Upgrades previsíveis. Código que compila sob o ABAP Cloud depende apenas de objetos liberados, o que reduz o trabalho de regressão a cada mudança de release.
• Um modelo para todas as implantações. As mesmas competências e padrões valem no SAP BTP ABAP environment, na Public Edition e na Private Edition ou no on-premise.
• Competências ABAP existentes. As equipes mantêm o ABAP, os transportes e a gestão de ciclo de vida conhecida, em vez de trocar de linguagem.
• Proximidade dos dados. O código ABAP Cloud on-stack roda junto aos dados e às transações do SAP S/4HANA, com uma consistência transacional que uma extensão remota não consegue oferecer.
• Caminho integrado para o SAP Fiori. Os serviços RAP alimentam diretamente apps SAP Fiori elements.

Para o ABAP customizado que precisa sobreviver a mudanças de release, o ABAP Cloud é o modelo de desenvolvimento em torno do qual as ferramentas, as verificações e a documentação da SAP foram construídas.

• Limitado às APIs liberadas. Onde a SAP não liberou um objeto, o código ABAP Cloud não pode usá-lo. Na Public Edition a lacuna permanece até a SAP liberar uma API; nos demais casos, ela é contornada com wrappers que exigem um responsável.
• Padrões legados ficam de fora. Telas dynpro clássicas e relatórios com saída no SAP GUI não fazem parte do modelo, por isso o código existente raramente é portado sem redesenho.
• Curva de aprendizado. CDS, behavior definitions do RAP e ferramentas baseadas no Eclipse são novidade para muitos desenvolvedores ABAP clássicos.
• Não é um processo de governança. O ABAP Cloud garante como o código depende da SAP; não decide o que construir, quem é o responsável nem como isso se conecta a um processo de negócio.

O ABAP Cloud protege a dependência técnica; escopo, responsabilidade e aderência ao processo continuam sendo decisões separadas.

1. Tratar o ABAP Cloud como um produto a licenciar. Ele é um modelo de desenvolvimento; os produtos são o SAP BTP ABAP environment e o SAP S/4HANA.
2. Misturar versões de linguagem sem um plano. Na Private Edition, decida por software component quais objetos devem ser ABAP Cloud e imponha isso com o ABAP Test Cockpit.
3. Usar wrappers por padrão. Um wrapper C1 é uma ponte para uma API ausente; procure primeiro uma API liberada.
4. Escolher o lugar errado. Use ABAP Cloud on-stack quando a lógica precisa de consistência transacional com os dados do SAP S/4HANA; use o SAP BTP ABAP environment ou outros runtimes quando a extensão precisa de um ciclo de vida próprio.

O critério de decisão é a dependência: se a lógica precisa alterar dados SAP na mesma unidade de trabalho, o ABAP Cloud on-stack costuma ser o lugar certo.