Participei do DSAG AK Dev Zukunftstag em janeiro de 2025 em Hockenheim. De manhã, o foco foi CAP vs. RAP. O posicionamento fez parecer que há uma competição entre CAP e RAP. Que há um vencedor e um perdedor. Que é preciso escolher um em detrimento do outro. Isso é simplesmente errado. Ambos existem em paralelo. Sua utilização é definida pelos clientes e suas necessidades específicas são definidas pelos cenários de solução. O que, por sua vez, significa que ambos raramente competem em termos de clientes.

Cenários onde o CAP se destaca

• Soluções não centradas em SAP. Isso ocorre quando talvez nem mesmo um sistema SAP esteja envolvido.

• Ampla gama de usuários. Se a solução for destinada a um grande número de usuários (centenas ou até milhões), você deseja que essa carga seja gerenciada por uma solução nativa em nuvem com boa escalabilidade.

• Cenário externo com um número significativo de usuários anônimos que precisam acessar dados de sistemas internos. Você pode querer ter um componente entre usuários anônimos e seu sistema SAP interno. Ou até mesmo colocar os dados no CAP sem conceder acesso ao seu sistema interno.

• Alto número de mensagens de dados em processos, por exemplo, um cenário não baseado em usuário e o destino dessas mensagens não é um sistema S/4HANA.

• Acesso principalmente a desenvolvedores JavaScript/TypeScript/Java, mas não a desenvolvedores ABAP. Se, no entanto, o cenário estiver listado na lista de excelência do RAP, talvez seja necessário considerar a qualificação dos desenvolvedores para desenvolvedores ABAP.

• Cultura nativa em nuvem. Quando todos os aplicativos são aplicativos nativos em nuvem que rodam, por exemplo, Kubernetes e equipes têm fácil acesso a essas informações.

• Soluções “dispare e esqueça”. Soluções simples com baixo orçamento e vida útil curta. Mas também, somente se não fizer parte da lista de excelência do RAP – especificamente as habilidades dos desenvolvedores.

• Cenários para desenvolvedores JS/TS e Java e onde CAP com CDS e OData com Fiori é melhor do que uma pilha de tecnologia alternativa (por exemplo, Spring, Angular).

Resumindo: Caso você precise de um aplicativo para centenas de milhares de usuários que talvez nem acessem dados SAP, a melhor opção é CAP. No entanto, a seguinte pergunta pode precisar de uma resposta: por que CAP e não alguma tecnologia não SAP?

Cenários nos quais RAP se destaca

• Cenários baseados em S/4HANA.

• Cenário centrado em SAP onde o acesso a um sistema S/4HANA é necessário.

• A maioria dos desenvolvedores disponíveis para a solução são desenvolvedores ABAP.

• A maioria dos usuários nomeados está migrando para a solução.

• Uma versão relativamente recente do S/4HANA está disponível (2023), S/4HANA Public Cloud ou BTP, ambiente ABAP. Permite o uso de aplicativos RAP ou extensões escritos lado a lado ou em pilha. Se você estiver usando uma versão mais antiga: atualize!

• Dados relevantes para o negócio são trocados via APIs em um cenário de integração com os sistemas SAP envolvidos.

• Soluções SAP típicas: arquitetura relativamente monolítica, aplicativos de longa duração que precisam ser mantidos por vários anos.

Resumindo: para qualquer tarefa que você normalmente usaria ABAP, o RAP é a melhor opção.

Onde ambos se destacam?

Muitos diriam: extensibilidade lado a lado. Embora ambos possam ser usados ​​para extensibilidade lado a lado, você terá que analisar as duas listas do Excel. E então a decisão sobre CAP e RAP torna-se novamente mutuamente exclusiva. Lado a lado significa: centrado em S/4HANA, centrado em SAP. Isso é RAP. Se uma ampla gama de usuários usar a extensão: CAP. Se você tiver apenas desenvolvedores não ABAP disponíveis: CAP. E se seus desenvolvedores forem desenvolvedores ABAP, o que é provável dado o cenário de extensão, então é RAP. Não existe uma verdadeira diferença entre CAP e RAP. Um pouco exagerado, você poderia dizer: eles são conjuntos disjuntos.

A sobreposição imaginária

Considerando os pontos ideais para usar CAP ou RAP, por que há tanto barulho em torno deste tópico? Bem, primeiro, este é um tópico para desenvolvedores. As pessoas vão fazer barulho em torno dele. Aprender uma tecnologia leva tempo. Uma quantidade significativa de tempo de vida é investida. Os desenvolvedores querem obter algo em troca de seu investimento em aprendizado e se tornarem defensores de uma tecnologia. O resultado disso pode parecer uma sobreposição constante entre CAP e RAP.

A sobreposição de extensibilidade

Por que há essa sobreposição percebida em relação à extensibilidade? CAP e RAP são comercializados pela SAP para atender a um caso de uso sobreposto (extensibilidade).

Essa sobreposição é o ponto ideal para justificar a existência de diferentes stakeholders. Um deles, é claro, é a SAP. A sobreposição é justificada pela estratégia corporativa de núcleo limpo. Uma extensão lado a lado é um aplicativo desenvolvido para rodar em BTP. O CAP é recomendado ao desenvolver um aplicativo em BTP. Esses dois pontos se fundem em: usar CAP para extensibilidade. No entanto, o CAP é uma opção para extensibilidade lado a lado. A outra é o RAP (sim, o RAP inclui aqui tudo o que é necessário para rodá-lo em ambientes Steampunk/BTP e ABAP). O fato de o CAP ser uma opção e o fato de o cliente precisar escolher o que é melhor para ele é frequentemente ignorado. O fato de haver mais a ser adicionado à decisão (veja a lista de “destaques em”) não é muito bem comunicado pela SAP. Parceiros e freelancers que apostam em BTP e CAP como sua pilha tecnológica também estão mais do que felizes em afirmar que o CAP é uma boa opção para uma extensão, referindo-se à SAP. E por que a SAP deveria fazer algo contra isso? Contanto que os clientes continuem com a SAP e paguem, está tudo bem. Em cenários de extensão, você deve sempre se perguntar sobre o posicionamento do CAP. Um sistema S/4HANA será estendido? Então, já existem desenvolvedores ABAP disponíveis?

Outro motivo responsável pela confusão entre CAP e RAP é o marketing da SAP. A SAP não está realmente promovendo o CAP fora do (pequeno) ecossistema SAP. Isso elimina boa parte da lista de “excelências” do CAP. Resultando na extensibilidade recebendo a atenção principal (também conhecida como: “fruto fácil de colher”). RAP e CAP agora estão posicionados para atender ao mesmo propósito: extensibilidade. O marketing está mirando nos clientes SAP para vender BTP para núcleo limpo. Uma situação típica de ganho mútuo: a SAP vende BTP e qualquer cliente que esteja optando por um núcleo limpo pode ser facilmente tentado a comprar RISE ou Nuvem Pública. Perdi a conta de quantas vezes as pessoas se surpreendem ao saber que é possível usar ABAP Cloud on-stack. O marketing da SAP se concentra nos clientes SAP existentes, e isso está causando um problema sério: exatamente esses têm desenvolvedores ABAP disponíveis, e raramente desenvolvedores CAP. Um dos principais motivos para a diferença entre CAP e RAP é o foco excessivo da mensagem em um cenário que compartilha o mesmo público-alvo: clientes SAP e desenvolvedores SAP.

Vamos adicionar mais um problema: falta de habilidades. Não há desenvolvedores CAP suficientes no mercado (Alô, SAP: faça algo, tipo: 5 anos atrás!). Desenvolvedores ABAP de alta qualificação para se tornarem desenvolvedores CAP? As empresas têm um uso melhor do raro conjunto de habilidades ABAP. O que traz de volta um problema antigo: as empresas precisam treinar pessoas para serem desenvolvedores CAP. Mas por que optar por CAP quando ABAP é, para uma empresa, a melhor habilidade? Lembre-se: extensibilidade: existe um sistema S/4HANA em uso. É melhor ter desenvolvedores ABAP nesse caso (novamente: veja as listas de “destaques em”).

Por que isso não é compreendido? Mesma resposta de antes: marketing. Ter sessões de aprendizado, tutoriais e vídeos mostrando como é fácil escrever um aplicativo CAP e conectá-lo a um serviço OData é simplesmente fantástico. Para a SAP, é interessante demonstrar em seus eventos que é fácil iniciar um aplicativo CAP. Mas isso não tem nada a ver com as situações reais dos clientes. Aqui, a lista de “excelentes em” é importante. O que ajuda saber que um aplicativo CAP simples pode ser criado em poucos minutos? Como colocá-lo em produção? Como executá-lo pronto para a empresa (escala, segurança, rastreamento, transportes, monitoramento, …)? Embora isso ainda possa ser aceitável, o marketing decidiu ir atrás do ecossistema SAP para isso. Em vez de mostrar isso para desenvolvedores não SAP e trazer novas pessoas para o universo SAP e qualificá-las, eles se concentram nos desenvolvedores SAP. O menor denominador comum para esses é: migrar um sistema SAP para o S/4HANA e aplicar um núcleo limpo e extensibilidade lado a lado. Resultado: o CAP é posicionado artificialmente na mesma área em que o RAP se destaca. Se você acha que o impulso para adotar o CAP não está alinhado com o ponto ideal do CAP (novamente: a lista de “excelentes em” é importante): espere até ter o Suporte SAP ou alguns serviços de transformação do S/4HANA adicionados ao seu calendário.

Conclusão

Tudo isso cria uma competição artificial onde normalmente deveria haver uma coexistência amigável. Às listas de “destaques em”, vários outros pontos precisam ser adicionados. Mas estes são mais um efeito colateral e devem ser incluídos automaticamente no processo de seleção. Mesmo quando uma solução é avaliada e uma pilha de tecnologias é selecionada: lembre-se de que é preciso mantê-la. Certifique-se de que, para soluções de longo prazo, haja pessoas suficientes disponíveis com as habilidades necessárias no futuro. Caso você compre uma solução em pacote: verifique se a tecnologia usada pelo parceiro atende às suas necessidades. SaaS: extensões via API. O que for usado para fornecer essa API: não importa. O parceiro está totalmente focado em uma tecnologia? Verifique se você, como cliente, não está sendo explorado e deve pagar pelas lições aprendidas do parceiro. Para clientes, parceiros e freelancers: recomendo criar suas próprias listas de “destaques em”. Comunique-as e, se um projeto do cliente for categorizado em uma delas, não o force a mudar de categoria. Se for CAP, é CAP. Não force um projeto RAP a ser um projeto CAP e vice-versa. O que pode ser feito para garantir que as pessoas percebam que não há concorrência? Uma abordagem pode ser focar, do lado do CAP, em projetos onde o CAP possa mostrar o que é possível. Usar o CAP para trazer pessoas do mundo de desenvolvedores não SAP para o mundo SAP. Menos foco no ecossistema SAP. Menos foco na extensibilidade do S/4HANA e mais soluções nativas em nuvem. Mais foco no CAP para soluções complementares. Para o RAP, significa: mostrar mais sobre como estender o SAP: nuvem pública, on-stack, on-premise, com BTP. Treinamentos para aprimorar as habilidades de desenvolvedores ABAP. Também: RAP para soluções complementares.

Acho que a única interseção entre CAP e RAP pode ser: complementos.