A SAP anunciou, durante seu importante evento de outono, o TechEd 2024, a introdução do ambiente SAP Build Code ABAP. Este anúncio destaca a integração do ABAP ao SAP Build, posicionando-o como o centro integrado para desenvolvedores SAP criarem soluções modernas, tanto para cenários em nuvem quanto on-premise. 

Anteriormente, o SAP Build oferecia suporte apenas a soluções não baseadas em ABAP, com ferramentas e recursos como o CAP (Cloud Application Programming), o BAS (Business Application Studio) e a Automação de Processos (Process Automation), mas sem incluir funcionalidades relacionadas ao ABAP. A adição do ABAP ao portfólio do SAP Build representa uma expansão significativa, permitindo que os desenvolvedores utilizem ABAP dentro desse ambiente integrado.

Mas o que é esse recurso ABAP totalmente integrado? 

Agora é possível desenvolver aplicações ABAP RAP diretamente no navegador? O editor ABAP, junto com os assistentes, ferramentas e frameworks, está acessível para os desenvolvedores dentro do BAS (Business Application Studio)? Observando os anúncios e a apresentação compartilhada, pode-se ter a impressão de que o ABAP está totalmente integrado ao SAP Build. 

Há a Unified SAP Build Lobby, que oferece acesso direto não apenas ao CAP, Fiori e à versão do BAS voltada para MDK (ou, nos termos da SAP: Full-Stack Application, SAP Fiori Application e Mobile Application), mas agora também ao ABAP Cloud Full-Stack Application.

Olhando mais de perto, um pouco da magia se perde.

A integração do ABAP ao SAP Build se resume a: desenvolvedores ABAP utilizando as ABAP Development Tools for Eclipse (ADT para Eclipse, ou simplesmente ADT). Isso significa que se trata de uma aplicação desktop: o Eclipse – também uma aplicação desktop – com os plugins do ADT. 

Essa é a ferramenta preferida para desenvolvedores ABAP na criação de soluções para S/4HANA desde… praticamente sempre.

O que é o SAP Build Code ABAP environments agora? 

É o ADT para Eclipse, com um tile bem apresentado no Unified SAP Build Lobby. Acredito que esse tile seja o que torna o ADT “totalmente integrado” ao SAP Build. Nesse caso, a integração se resume a um link que aponta para o Eclipse. 

Isso faz com que a integração do SAP Build com ABAP seja o link mais supervalorizado da história do mundo SAP? Não me lembro de outro exemplo em que chamar uma aplicação desktop tenha sido tão discutido. Então, acho que sim. 

O que torna essa “integração” interessante do ponto de vista dos desenvolvedores e clientes são os recursos de IA (Inteligência Artificial) adicionados ao ADT. 

De cabeça, consigo pensar em tantos outros…

Desenvolvimento ABAP impulsionado por IA

Deixe a IA gerar testes unitários para mim. Deixe a IA explicar o código para mim. Deixe a IA auxiliar o desenvolvedor a navegar por assistentes. Esses recursos podem economizar um tempo valioso e contribuir para que os aplicativos resultantes não apenas sejam entregues mais rapidamente, mas também com uma qualidade ligeiramente superior.

Agora, isso é somente SAP Build? Parece que não, já que os recursos de IA para ADT estão no ABAP AI SDK com tecnologia ISLM e Joule. Acho que a questão que determina como obter acesso ao ABAP AI SDK é: o que é mais importante: clientes do SAP Build ou clientes que usam IA para desenvolvimento ABAP? Como usá-lo parece não fazer parte do TechEd. Isso é algo para o primeiro trimestre de 2025. Vamos esperar como o SAP Build ABAP ADT fortemente integrado funcionará quando os desenvolvedores tiverem que abrir um desktop Citrix e iniciar o ADT a partir daí.

Desenvolvimento de fusão

O termo equipes de fusão ou desenvolvimento de fusão chamou minha atenção. A SAP está se lembrando de que o software não é escrito apenas por uma única pessoa — desenvolvedor full-stack ou cidadão — mas sim por equipes. Espero que a SAP entenda que uma equipe de fusão não é composta apenas por desenvolvedores.

O slide que encontrei não me dá muita esperança de que a SAP veja as equipes de fusão como um grupo diverso. Não diverso no sentido de habilidades técnicas. Diversificado nas várias habilidades necessárias para entregar aplicativos de negócios: técnico, funcional, processos, negócios. O que espero é que a SAP preencha o termo equipes de fusão dentro do Build com a cola que permite que as equipes trabalhem de forma eficiente. As primeiras coisas que me vêm à mente que a SAP deve incluir:

• Comece pelo processo de negócios: mostre onde as melhorias podem agregar valor. O que talvez esteja faltando e reúna a entrada dos usuários finais.

• Inclua usuários de negócios para fornecer entrada, dados, casos de teste e outras informações relacionadas ao processo de negócios que ajudem a entender o problema a ser resolvido.

• Modelagem de dados no Build e permita usar a mesma definição de modelo (CDS) para CAP e RAP. Isso não é possível no momento, mas por que um cliente deve ser punido pela falta de padronização de CDS entre modelos de programação?

• Geração de teste automatizada com envolvimento rigoroso do usuário final.

• Reúna feedback diretamente do aplicativo para melhorar outros sabores. Seja um aplicativo móvel, aplicativo da web ou a versão da API do serviço subjacente.

• Habilitar solução transparente ao habilitar a coleta de rastros e outras medidas de forma transparente por meio de todos os componentes envolvidos.

• Tornar o desenvolvimento multiaplicativo: móvel, web, analítico. Tudo integrado em um só lugar.

Isso está no topo da coleção atual disponível de ferramentas de desenvolvedor para SAP Build. A ideia deve ser permitir que as equipes criem soluções.

Deixe o mundo saber.