ABAP RESTful Application Programming Model (RAP)

Uma aplicação RAP é montada em camadas, cada uma um objeto de repositório separado:

1. Modelo de dados: CDS view entities sobre tabelas do banco de dados. Uma root entity e suas child entities, ligadas por composições, formam o business object, por exemplo uma requisição de compra com seus itens.
2. Behavior definition (BDEF): declara o que o business object pode fazer: create, update, delete, actions, validations, determinations, bloqueio, controle de concorrência e draft.
3. Behavior pool: uma classe ABAP que implementa as partes customizadas que a behavior definition declara, como uma validação que rejeita requisições acima de um limite.
4. Camada de projeção: projection views e uma projection behavior definition que expõem apenas o que um determinado serviço precisa.
5. Service definition: lista as entidades que um serviço expõe.
6. Service binding: escolhe o protocolo (OData V2, OData V4 ou InA) e a categoria, UI ou Web API, e publica o serviço. Uma pré-visualização mostra o resultado como um app SAP Fiori elements.

Cada camada tem uma única função, e é assim que o RAP mantém modelo de dados, comportamento e exposição separados em um único business object ABAP.

O tipo de implementação na behavior definition decide quem escreve o código transacional:

• Managed: o framework RAP trata as operações padrão de create, update e delete, o buffer transacional e a gravação nas tabelas persistentes. Os desenvolvedores acrescentam apenas a lógica de negócio: validations, determinations e actions.
• Unmanaged: os desenvolvedores implementam eles mesmos todas as operações e a sequência de gravação, normalmente chamando código de aplicação existente que já trata a persistência.

Existe uma terceira variante para código mais antigo: business objects construídos com o modelo predecessor ABAP Programming Model for SAP Fiori (BOPF) podem ser migrados para RAP business objects baseados em BOPF. A SAP observa que estes não são RAP business objects nativos e não são habilitados para ABAP Cloud.

Critério de decisão: escolha managed quando o business object é dono das suas tabelas, como em uma nova aplicação customizada na Alder Manufacturing; escolha unmanaged quando uma lógica legada comprovada precisa ser reutilizada em vez de reescrita. O RAP managed reduz código; o RAP unmanaged protege investimentos existentes.

O RAP cresceu release a release, então a disponibilidade depende do recurso, e não apenas do modelo:

O SAP S/4HANA Cloud Public Edition recebe os recursos no ritmo da nuvem, e a Private Edition acompanha a release on-premise em que roda. O SAP ERP (ECC) não inclui o RAP: as releases da ABAP Platform que o trazem, a partir da 7.53, são entregues apenas com o SAP S/4HANA. As feature tables da RAP BDL da SAP listam a release de cada elemento da linguagem, e verificá-las para a release de destino é o primeiro passo de qualquer desenho RAP.

O ABAP Cloud é o modelo de desenvolvimento da SAP para ABAP pronto para a nuvem e estável em upgrades: apenas APIs liberadas, uma versão de linguagem restrita e ferramentas baseadas em Eclipse. O RAP é o modelo de programação que o ABAP Cloud usa para aplicações e serviços transacionais.

• No SAP BTP ABAP environment e na extensibilidade de desenvolvedor do SAP S/4HANA Cloud Public Edition, o RAP é a forma de construir apps e APIs transacionais.
• Na Private Edition e on-premise, o RAP pode ser usado com as regras do ABAP Cloud, disponíveis a partir do SAP S/4HANA 2022 (ABAP 7.57), ou em ABAP clássico. A escolha decide quais objetos SAP o código pode usar.
• O strict mode em uma behavior definition impõe as boas práticas atuais, como usar CDS view entities como fontes de dados.

O RAP, portanto, não está preso ao SAP BTP: o mesmo modelo roda dentro do SAP S/4HANA. O ABAP Cloud acrescenta as regras; o RAP fornece a estrutura.

Os pontos fortes do RAP são reais. Um único modelo vai do banco de dados à UI do SAP Fiori elements; bloqueio, controle de concorrência e draft vêm do framework, e não de código escrito à mão; os serviços permanecem estáveis em upgrades quando construídos sobre APIs liberadas; e o mesmo business object pode atender uma UI e uma API.

Seus limites decorrem de onde ele roda:

• Somente ABAP. O RAP exige conhecimento de ABAP, o ABAP Development Tools e um sistema ABAP; equipes sem isso enfrentam uma curva de aprendizado real.
• Um único sistema. Um RAP business object é transacional dentro de um único sistema ABAP. Processos que abrangem vários sistemas precisam de integração ou eventos por cima.
• Vinculado à release. Um recurso documentado para a nuvem pode chegar ao on-premise apenas em uma release posterior.
• Flexibilidade de UI por meio de anotações. Os apps gerados com SAP Fiori elements são tão flexíveis quanto os floorplans e seus pontos de extensão.

O RAP é a opção mais forte quando a lógica e os dados pertencem ao sistema ABAP; ele não foi projetado para orquestração entre sistemas.

1. Expor a camada base diretamente. Sem uma camada de projeção, toda mudança no serviço afeta o business object central.
2. Escolher unmanaged por hábito. Unmanaged faz sentido quando a lógica legada é reutilizada; para tabelas novas, managed poupa a maior parte do código.
3. Vincular um app SAP Fiori a um serviço Web API. Bindings Web API não carregam metadados de UI, então o app mostra tabelas vazias ou layouts padrão. Use um binding UI.
4. Construir sobre CDS views DDIC-based. Elas são obsoletas, e o strict mode espera view entities.
5. Ignorar as feature tables. Código copiado de um tutorial de nuvem pode não ativar em uma release on-premise mais antiga.

A maioria dos problemas com RAP são decisões de camadas e de release tomadas cedo demais, e não erros de codificação.